4 ms·

There's plenty of use cases for Linux on microcontrollers that will be impossible if nommu is removed. The only reason we don't see more Linux on MCUs is the la

There's plenty of use cases for Linux on microcontrollers that will be impossible if nommu is removed. The only reason we don't see more Linux on MCUs is the lack of RAM. RP2350 are very close! Running Linux makes it much easier to develop than a plain RTOS.

snvzz 1y ago
A "plain RTOS" is the better idea most of the time.
- topspin 1y ago
  That may change. There are some very powerful MCUs appearing, with astonishing features, including hardware virtualization (hypervisors on an MCU,) multicore superscalar, heterogeneous CPU cores with high performance context switching, "AI" co-processors with high throughput buses, and other exotic features. At some point, it might start making sense to level up the OS to (nommu) Linux on these devices. When the applications get complex enough, people find themselves wanting a full blown network stack, full featured storage/file systems that are aligned with non-embedded systems, regular shells, POSIX userland, etc. All of the architectures I have in mind are 32 bit and "nommu"[1]: Cortex-R52/F, Infineon TriCore, Renesas RH850, NXP Power e200. Then you have RISC-V MCU Cambrian Explosion underway. I qualify all this with mays and mights: it hasn't happened yet. I'm just careful not to discount the possibly of a <50 mAh RP Pico 3 booting uLinux, running python and serving web pages being a big hit. [1] They all have various "partition" schemes to isolate banks of RAM for security, reliability, etc., but real MMUs are not offered.
  - snvzz 1y ago
    Generally, MCU people want predictable behavior and small TCB. Linux is too unorthogonal for them.
  - leoedin 1y ago
    I've spent quite a lot of the last year setting up an embedded Linux device for mass deployment - so I've seen a lot of its downsides first hand. When you have a fleet of embedded devices you want pre-compiled disk images, repeatable builds, read only filesystems, immutable state (apart from small and well controlled partitions), easy atomic updates, relatively small updates (often devices are at the other end of a very slow cell connection) and a very clear picture of what is running on every device in your fleet. Linux can do all that, but it's not the paradigm that most distros take. Pretty much the entire Linux world is built around mutable systems which update in place. So you're left to manage it yourself. If you want to do it yourself, you end up in the hacky fragile world of Yocto. Compared to that, using an RTOS or application framework like Zephyr is fairly easy - at the expense of app development time, you just need to worry about getting a fairly small compiled binary onto your device. I do agree that there's some really powerful parts available which would benefit from the shared drivers and consistent syscalls a standardised operating system offers. But building and maintaining a Linux system for any part isn't a simple undertaking either - and so the complexity of that needs to be considered in total development time.
    - deleted 1y ago
      [deleted]
Brian_K_White 1y ago
Linux, or any other full OS is simply a waste of that hardware. It makes no sense at all. It's a 5 gallon pail of compute which is all used up in OS overhead so you can do a cup of work. If the job were that small that it fits in the remainder, then you could and should have just used 1 cent hardware instead of 1 dollar hardware.
- speed_spread 1y ago
  Many Adafruit boards come with micropython which could also be seen as a waste of resources. Yet for low volume semi pro applications, the ease of development warrants the overhead. Linux has solid network, WiFi, Bluetooth stacks and a rich box of tools that might be very nice to tap into without requiring something as big as an RPi.
  - duskwuff 1y ago
    > Many Adafruit boards come with micropython which could also be seen as a waste of resources. Yet for low volume semi pro applications, the ease of development warrants the overhead. As a reality check: MicroPython can run in 16 KB of RAM; a typical development board has 192 KB. µCLinux requires at least 4 - 8 MB of RAM just to boot up, and recommends 32 MB for a "serious product" [1]. > Linux has solid network, WiFi, Bluetooth stacks and a rich box of tools that might be very nice to tap into without requiring something as big as an RPi. I would absolutely not count on any of those tools being available and functional in a µCLinux environment. [1]: https://www.emcraft.com/imxrt1050-evk-board/what-is-minimal-footprint https://www.emcraft.com/imxrt1050-evk-board/what-is-minimal-...
    - actionfromafar 1y ago
      I used Ethernet, USB and some serial thingy (I2C? can't remember) without issue.
    - speed_spread 1y ago
      > µCLinux [...] recommends 32 MB for a "serious product" My point exactly. There's currently a hole between ten-cent MCUs requiring RTOS and 5$+ RPi that can run Linux. Taking out nommu from the kernel would make any 64MB "super-MCU" a non-starter.
duskwuff 1y ago
> Running Linux makes it much easier to develop than a plain RTOS. I'm not convinced that's true. All of the microcontroller tooling I've seen has been built around RTOS development; I've never seen anything comparable for µCLinux.
RossBencina 1y ago
> Running Linux makes it much easier to develop than a plain RTOS. What's missing? What would it take to make a plain RTOS that's as easy to develop on/for/with as Linux?
leoedin 1y ago
Setting up and maintaining a custom Linux build for any hardware is pretty complicated. There's just so much complexity hidden under config options. The landscape of Linux for embedded computers is a huge mess of unmaintained forks and hacky patch files. That's all worth it to have an application processor that can run your Python/Java app. It's probably worth it to have a consistent operating system across multiple devices. Would you have many of those benefits if you were using Linux on a micro though? I can't imagine much 3rd party software would work reliably given the tiny amount of RAM. You'd basically just be using it as a task scheduler and wrapper over drivers. You could get most of the benefits by using an RTOS with a memory allocator.
pjc50 1y ago
There's no evidence that significant numbers of people are actually doing that, though.

snvzz 1y ago

A "plain RTOS" is the better idea most of the time.

topspin 1y ago
That may change. There are some very powerful MCUs appearing, with astonishing features, including hardware virtualization (hypervisors on an MCU,) multicore superscalar, heterogeneous CPU cores with high performance context switching, "AI" co-processors with high throughput buses, and other exotic features. At some point, it might start making sense to level up the OS to (nommu) Linux on these devices. When the applications get complex enough, people find themselves wanting a full blown network stack, full featured storage/file systems that are aligned with non-embedded systems, regular shells, POSIX userland, etc. All of the architectures I have in mind are 32 bit and "nommu"[1]: Cortex-R52/F, Infineon TriCore, Renesas RH850, NXP Power e200. Then you have RISC-V MCU Cambrian Explosion underway. I qualify all this with mays and mights: it hasn't happened yet. I'm just careful not to discount the possibly of a <50 mAh RP Pico 3 booting uLinux, running python and serving web pages being a big hit. [1] They all have various "partition" schemes to isolate banks of RAM for security, reliability, etc., but real MMUs are not offered.
- snvzz 1y ago
  Generally, MCU people want predictable behavior and small TCB. Linux is too unorthogonal for them.
- leoedin 1y ago
  I've spent quite a lot of the last year setting up an embedded Linux device for mass deployment - so I've seen a lot of its downsides first hand. When you have a fleet of embedded devices you want pre-compiled disk images, repeatable builds, read only filesystems, immutable state (apart from small and well controlled partitions), easy atomic updates, relatively small updates (often devices are at the other end of a very slow cell connection) and a very clear picture of what is running on every device in your fleet. Linux can do all that, but it's not the paradigm that most distros take. Pretty much the entire Linux world is built around mutable systems which update in place. So you're left to manage it yourself. If you want to do it yourself, you end up in the hacky fragile world of Yocto. Compared to that, using an RTOS or application framework like Zephyr is fairly easy - at the expense of app development time, you just need to worry about getting a fairly small compiled binary onto your device. I do agree that there's some really powerful parts available which would benefit from the shared drivers and consistent syscalls a standardised operating system offers. But building and maintaining a Linux system for any part isn't a simple undertaking either - and so the complexity of that needs to be considered in total development time.
  - deleted 1y ago
    [deleted]

Brian_K_White 1y ago

Linux, or any other full OS is simply a waste of that hardware. It makes no sense at all. It's a 5 gallon pail of compute which is all used up in OS overhead so you can do a cup of work. If the job were that small that it fits in the remainder, then you could and should have just used 1 cent hardware instead of 1 dollar hardware.

speed_spread 1y ago
Many Adafruit boards come with micropython which could also be seen as a waste of resources. Yet for low volume semi pro applications, the ease of development warrants the overhead. Linux has solid network, WiFi, Bluetooth stacks and a rich box of tools that might be very nice to tap into without requiring something as big as an RPi.
- duskwuff 1y ago
  > Many Adafruit boards come with micropython which could also be seen as a waste of resources. Yet for low volume semi pro applications, the ease of development warrants the overhead. As a reality check: MicroPython can run in 16 KB of RAM; a typical development board has 192 KB. µCLinux requires at least 4 - 8 MB of RAM just to boot up, and recommends 32 MB for a "serious product" [1]. > Linux has solid network, WiFi, Bluetooth stacks and a rich box of tools that might be very nice to tap into without requiring something as big as an RPi. I would absolutely not count on any of those tools being available and functional in a µCLinux environment. [1]: https://www.emcraft.com/imxrt1050-evk-board/what-is-minimal-footprint https://www.emcraft.com/imxrt1050-evk-board/what-is-minimal-...
  - actionfromafar 1y ago
    I used Ethernet, USB and some serial thingy (I2C? can't remember) without issue.
  - speed_spread 1y ago
    > µCLinux [...] recommends 32 MB for a "serious product" My point exactly. There's currently a hole between ten-cent MCUs requiring RTOS and 5$+ RPi that can run Linux. Taking out nommu from the kernel would make any 64MB "super-MCU" a non-starter.

duskwuff 1y ago

> Running Linux makes it much easier to develop than a plain RTOS. I'm not convinced that's true. All of the microcontroller tooling I've seen has been built around RTOS development; I've never seen anything comparable for µCLinux.

RossBencina 1y ago

> Running Linux makes it much easier to develop than a plain RTOS. What's missing? What would it take to make a plain RTOS that's as easy to develop on/for/with as Linux?

leoedin 1y ago

Setting up and maintaining a custom Linux build for any hardware is pretty complicated. There's just so much complexity hidden under config options. The landscape of Linux for embedded computers is a huge mess of unmaintained forks and hacky patch files. That's all worth it to have an application processor that can run your Python/Java app. It's probably worth it to have a consistent operating system across multiple devices. Would you have many of those benefits if you were using Linux on a micro though? I can't imagine much 3rd party software would work reliably given the tiny amount of RAM. You'd basically just be using it as a task scheduler and wrapper over drivers. You could get most of the benefits by using an RTOS with a memory allocator.

pjc50 1y ago

There's no evidence that significant numbers of people are actually doing that, though.