LWN: Comments on "Kernel tinification"

Linux recommended / compatible RTOS

tinti — Mon, 15 Sep 2014 17:22:47 +0000

You may try Nuttx. I don't know how much compatible it is.

http://www.nuttx.org/

Kernel tinification

oldtomas — Tue, 09 Sep 2014 09:06:37 +0000

How history repeats itself.

I haven't the reference ready, but I think it was in CACM's "Inside Risks" column, late in the last century: some computer at a port (of the naval kind) crashed repeatedly. It took some time to realize that the crashes came at a bi-weekly schedule. From there it was relatiely easy to correlate the crashes with the (regular) arrival of one military ship: its radar machinery confused the electronics of said computer.

Linux recommended / compatible RTOS

pizza — Wed, 03 Sep 2014 11:31:44 +0000

> These processors usually have under 512k flash and 64k ram.

Indeed, 512/64 is actually a pretty high-end part.

> Recommended opensource Linux compatible RTOS?
> Compatible: Event queue, Asynchronous message queue, mailbox intercommunication.

In short, such a thing does not exist, at least not if you're looking to be API-compatible with Linux. Or even behaivorally-compatible.

Come to think of it, eCOS may be the closest, but by the time you enable all the nice APIs and features the RAM/Flash requirements are such that you may as well be running uClinux.

nuttx is pretty full-featured too at this point, and RTX has been freed by ARM and is actually bundled with CMSIS these days. Personally, I'm particularly fond of FreeRTOS, but it's fairly bare bones in comparison to the others.

Linux recommended / compatible RTOS

tdwebste — Wed, 03 Sep 2014 02:57:46 +0000

I was hoping the discussion was NOT going to revolve around whether Linux can be shoe horned into cortex m0, m4 ARM processors.

cortex m0 processors are in extremely price sensitive markets, which makes external flash very undesirable. These processors usually have under 512k flash and 64k ram.
cortex m4 processors maybe able to run Linux. But there is many reasons not to. The main being the m4 and m0 are often performing similar applications. Applications that often need to be compiled without unused file system and networking support to reduced flash and ram requirements.

Currently running the same OS on cortex m0 and m4 ARM processors makes the most since.

It is increasingly common for a cortex-m0/4 to be connected by pcb/usb/serial bus to a more powerful ARM processor running Linux. The imx6 is a example combining ARM Cortex-A9 and Cortex-M4 cores.

Back to my original question.
Recommended opensource Linux compatible RTOS?
Compatible: Event queue, Asynchronous message queue, mailbox intercommunication.

Linux recommended / compatible RTOS

pizza — Wed, 03 Sep 2014 00:47:54 +0000

> I am going to assume the simple statement is true.
> "Linux can not run in the confined flash and ram of cortex-M0 and cortex-M4 ARM processors."

It depends entirely on how much RAM and flash those parts have.

Many of these Cortex-M processors support the use of external RAM and flash. Those that do are generally capable of running uClinux; in particular there's mainline support for at least some of the EFM32 parts.

Linux recommended / compatible RTOS

tdwebste — Tue, 02 Sep 2014 23:32:49 +0000

I am going to assume the simple statement is true.
"Linux can not run in the confined flash and ram of cortex-M0 and cortex-M4 ARM processors."

These processors are used in many IOT devices. Examples include nordic, stmicro cortex-M0 MCU with programmable ble radio, Toshiba cortex-M4 MCU with accelerometer, programmable ble radios, lcd controller.

What is the recommended opensource Linux compatible RTOS?
With compatible: Event queue, Asynchronous message queue, mailbox intercommunication.

Kernel tinification

Fowl — Sun, 31 Aug 2014 10:37:10 +0000

Welcome to the future!

Kernel tinification

Wol — Sun, 31 Aug 2014 09:49:51 +0000

We had our induction hob fitted as part of our new kitchen some six years ago, and how's *this* for an obscure bug!!!

We repeatedly had the same issue as you, soft crashes requiring a hard reset to fix. So we called in the engineer under warranty to fix it.

He looked outside, and said "Are you under a flight path?". We are, about three or four miles from City Airport, almost right under the normal approach. So the engineer said, "it's a well known problem, the flight avionics interfere with the controller. You'll need a new controller." He replaced it and it's been fine ever since ...

Cheers,
Wol

LTO

nix — Fri, 29 Aug 2014 21:07:10 +0000

Not only do they do that -- they even do things like #include files that declare structure types with the same name but different members depending on #defines that vary per translation unit.

There's no *way* you can handle that in the same TU.

Kernel tinification

phuewe — Fri, 29 Aug 2014 13:50:21 +0000

How was the minimum kernel size shown in the diagram measured?

Also a real reference hardware would be a good thing, especially to get started.

LTO

jezuch — Fri, 29 Aug 2014 10:37:06 +0000

> i wonder if -whole-program can be used in final link stage.

Normally, no - because in the final link stage all you (normally) have are the already compiled and optimized object files. You need the source code in some form [also] available, and that's *exactly* what gcc's LTO does. There's not much more to it.

And, it's a lot less buggy than a few years ago.

LTO

yoshi314 — Thu, 28 Aug 2014 09:01:18 +0000

i wonder if -whole-program can be used in final link stage.

Kernel tinification

dlang — Sun, 24 Aug 2014 04:10:09 +0000

wireless access points have MB of flash and not that much memory (depending on the model, 16MB flash and 128MB ram is not uncommon), these are also cheap.

Such devices do have a need to read usb attached disks created on larger systems.

This isn't as tiny as what some people are aiming for, but trying to keep systems of this size running comfortably would go a fair ways towards the really tiny systems (especially since different people would want to be doing very different things with their APs, so they would be cutting out different parts of the kernel)

Kernel tinification

etienne — Fri, 22 Aug 2014 15:51:31 +0000

> Even with a tinified linux, there will always be room for such light RTOS at the low end (tiny micro-controllers).

There is a lot more software these days.
The other day, in my kitchen, the new "Induction Ceramic hob" crashed with non-responsive soft On/Off - I had to apply a complete and external power Off/On cycle...

LTO

anselm — Fri, 22 Aug 2014 10:54:04 +0000

I'm not overly familiar with the Linux kernel source, but it seems to me that individual translation units (source files) might use »static« declarations at top level to keep identifiers local to that translation unit, which is a popular programming technique in C.

Simply concatenating everything to make one huge translation unit would presumably fail if a name is declared that way in two different source files.

LTO

epa — Fri, 22 Aug 2014 09:28:38 +0000

Instead of (possibly buggy) link-time optimization, could you not concatenate all the source files into one enormous translation unit and compile that with optimization? If nothing else, it would be a great stress test for gcc. Perhaps even with today's large memory sizes (128 gigabytes, say) it is still not practical.

Kernel tinification

micka — Fri, 22 Aug 2014 08:07:33 +0000

> we have to make it possible to build smaller kernels — perhaps as much as an order of magnitude smaller.

This packs a bit of precision. A binary ordre of magnitude ?

Kernel tinification

yaap — Thu, 21 Aug 2014 14:55:35 +0000

"forcing them to go to a proprietary real-time operating system instead"

There are several free RTOS, like FreeRTOS or eCos so no need to dramatize by saying "proprietary" there ;) Even with a tinified linux, there will always be room for such light RTOS at the low end (tiny micro-controllers).