3 ms·

I've worked on firmware for a few SoC's that my company has designed or purchased and we use embedded linux on some. I think his observation about how Linux doe

I've worked on firmware for a few SoC's that my company has designed or purchased and we use embedded linux on some. I think his observation about how Linux doesn't abstract the hardware accurately is totally right. The system isn't that complicated, but implementing everything within the world of Linux has been painful imo, so for future implementations we're evaluating RTOS's. The main reason people use Linux on these custom SoCs because of driver availability of key components (ethernet phys and persistent storage), large library of tools, and probably $ (who wants to pay for QNX). Those are good reasons, but if you have to write a large volume of code, it doesn't really feel like it's providing too much. It definitely felt like we were just using a hammer and seeing everything as a nail. Those are my 2 cents.

elcritch 5y ago
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. 1: https://www.linuxfoundation.org/blog/the-power-of-zephyr-rtos/ https://www.linuxfoundation.org/blog/the-power-of-zephyr-rto... 2: https://docs.zephyrproject.org/latest/guides/dts/index.html https://docs.zephyrproject.org/latest/guides/dts/index.html
- ironman1478 5y ago
  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!
  - elcritch 5y ago
    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!

elcritch 5y ago

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. 1: https://www.linuxfoundation.org/blog/the-power-of-zephyr-rtos/ https://www.linuxfoundation.org/blog/the-power-of-zephyr-rto... 2: https://docs.zephyrproject.org/latest/guides/dts/index.html https://docs.zephyrproject.org/latest/guides/dts/index.html

ironman1478 5y ago
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!
- elcritch 5y ago
  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!