rtos: abstraction: partition RTOS logic into separate directories

[lgirdwood]

In preparation for further RTOS abstraction, move the xtos and zephyr specific headers to new top level rtos directories to enable:

1. Partitioning of code by RTOS type e.g. xtos, Zephyr.
2. Partitioning of RTOS and non RTOS logic and APIs

This PR reuses the existing zephyr top level directory and creates a new xtos top level directory to store RTOS specific files, logic and wrappers. Other RTOSes like FreeRTOS or CMSIS support would be added in the same way.

This PR makes no runtime functional change, but changes some RTOS specific headers to be included with a new directory. i.e.

#include <sof/spinlock.h>

now becomes

#include <rtos/spinlock.h>

As this now maps to the correct RTOS and is no longer using the sof prefix which is for common code.

This PR also adds a high level Kconfig for developers (disabled by default) so that they can easily switch to fully native Zephyr headers for development testing.

Signed-off-by: Liam Girdwood liam.r.girdwood@linux.intel.com

[lyakh]

hm, is this needed even if CONFIG_ZEPHYR_NATIVE_DRIVERS is used? If not, maybe make it conditional on this, if yes - maybe keep the headers, that Zephyr builds still need at their current locations and only move them over one by one as we stop using them in Zephyr?

[lgirdwood]

yep, that the plan and why it's a TODO. Its still WIP atm.

[andyross]

This all makes sense to me. Unfortunately it looks likely to collide badly with some terrible (but thematically similar) hackery I've been doing to get SOF to build against the native_posix architecture for an internal fuzzing requirement. There the glitch is "xtensa assumptions in headers" and not "xthal/zephyr assumptions", but the theme is similar.

[lgirdwood]

This all makes sense to me. Unfortunately it looks likely to collide badly with some terrible (but thematically similar) hackery I've been doing to get SOF to build against the native_posix architecture for an internal fuzzing requirement. There the glitch is "xtensa assumptions in headers" and not "xthal/zephyr assumptions", but the theme is similar.

Ah, we are thinking the same hackery then. Intention is to put all common (i.e. non RTOS logic) in include <sof/blah.h> and all the RTOS features in include <rtos/blah.h> as contamination between xtos and zephyr is super easy to do and difficult to unpick atm.

Fwiw, pls see my lrg/topic/plugin branch - I have generic FW running in POSIX environment as an ALSA plugin. i.e. the generic FW exposes a POSIX message queue for IPC which can be fuzzed. This also allows reverse fuzzing of the clients too as we have a message queue for each direction.

[lgirdwood]

Target core power on on ALD nocodec, seems unrelated. Lets try again.

[    24794289.223097] (       13670.936523) c0 ipc                  src/ipc/ipc3/handler.c:1605 INFO ipc: new cmd 0x40070000
[    24794310.004346] (          20.781250) c0 ipc                  src/ipc/ipc3/handler.c:716  INFO ipc: pm core mask 0x9 -> enable
[    24814476.253545] (       20166.250000) c0 idc                           src/idc/idc.c:113  ERROR idc_wait_in_blocking_mode() error: timeout, target_core 3
[    24814498.180627] (          21.927082) c0 idc                ......./intel/cavs/idc.c:160  ERROR idc_send_msg(), power up core 3 failed, reason 0x0
[    24814519.274376] (          21.093750) c0 ipc                  src/ipc/ipc3/handler.c:723  ERROR Failed to enable core 3
[    24815109.274353] (         590.000000) c0 ipc                  src/ipc/ipc3/handler.c:1605 INFO ipc: new cmd 0x60010000
[    24815138.232685] (          28.958332) c0 ipc                  src/ipc/ipc3/handler.c:207  ERROR ipc: comp 41 not found
[    26621389.150494] (     1806250.875000) c0 ll-schedule        ./schedule/ll_schedule.c:186  INFO task 0x9e19ec18 agent-work  avg 110, max 127

[lgirdwood]

SOFCI TEST

[lgirdwood]

License server issues on retired platforms. No need to rebuild.