This issue with needing more flexibility on SoC's makes me wonder if its part of why the Linux Foundation has put a lot of work and resources into Zephyr RTOS [1]. Its gaining a lot of popularity and incorporates some of nice elements of linux like device tree syntax (DTS) files [2]. I could readily imagine using Linux & Zephyr on a SoC, and using shared DTS to describe the SoC architecture.
Actually, come to think of it extending DTS syntax to describe the pointer swizzling the OP video mentions. Then both OO'es could derive correct physical address handling.
So, it's funny. It's not uncommon to run RTOSs and Linux on the same CPU, where the rtos coordinates tasks between the components that have real time requirements and the Linux side does stuff like stream data from a buffer that the rtos writes to. We had this architecture on some systems and the amount of cludging to get this all working was annoying to say the least. We specifically had issues are figuring out how to partition the memory regions for each OS and it wasn't trivial to validate.
I wasn't around when the decisions at my employer when the decisions made around OS options, but this would've been a viable one if it was mature enough at that time. Thanks for the info!
Sounds way too familiar! What’s amazing (to me) is that there’s even a VSCode plugin for DTS files that checks the memory offsets and gives you nice error messages like “flash partition 1 overlap partition 2 at 0x3e000, …”. It’s a bit like magic after doing it manually.
P.S. huh looks like Linux and Zephyr _are_ doing this via RPMsg subsystem as well. Wow, much nicer than the last time I looked into it!
Actually, come to think of it extending DTS syntax to describe the pointer swizzling the OP video mentions. Then both OO'es could derive correct physical address handling.
1: https://www.linuxfoundation.org/blog/the-power-of-zephyr-rto... 2: https://docs.zephyrproject.org/latest/guides/dts/index.html