> these days imagining running linux in 4MB makes me sniggers.
FWIW - OpenWRT / LEDE has support for a lot of wifi routers with 4MB flash that even have a webserver and lua and some other goodies - at the moment kernel 4.9 but 4.14 is coming and here device tree will even save some space.
Well you need 32mb RAM - it runs with some hacking on 16MB ram - with execute in place probably with less...
Yeah XIP is the only way to go for small config these days. There's some nice QSPI controllers that helps there, however, it's still such a waste.
What's forgotten about is the impact on readability in the kernel...
Last week I was discussing with a colleague a patch needed for our SoC in the 8250 serial driver. In the IRQ handler, we needed to do an extra test...
And my problem was that this test would be running on a bazillion machines if upstreamed, for about 0.000000001% chance of ever be executed, bar for our own low volume, industrial SoC. We'd add cycles to a critical code path for zero reason, and without conditional compile, nobody would know by reading the code.
So, after mulling over it, we decided to get it upstream anyway at some point. The conclusion was that we didn't make these rules, we're just following them.
Thing is, a lot of that stuff is happening; you have that vendor specific property that is tested, change a flag somewhere, and code all over use that flag for testing of features that have 0% chance of happening on that arch/machine. In the meantime, all that becomes code bloat, with codepath that are actually 'exceptions' bloating the code in a way you can't even 'see' them by reading the code.
> And my problem was that this test would be running on a bazillion machines if upstreamed, for about 0.000000001% chance of ever be executed, bar for our own low volume, industrial SoC. We'd add cycles to a critical code path for zero reason, and without conditional compile, nobody would know by reading the code.
That's a good reason why C++ is generally superior to C in embedded development: with C++, you can get at the same time compiler checks for the validity of your whole code to prevent bitrot (unlike macros), and ensure that the actual implementations will only have the actual code that is relevant to them - e.g. set your flags as constexpr variables in your device's struct, and have the tests run under `if constexpr` conditions. Devices without the flag set won't have the check compiled in, and others will. But oh well :)
One example where XIP would be really useful is MT7688KN [1], which is a variant of MT7688 WiFi router SoC, already well supported by Linux/OpenWRT, plus 8MB of RAM on the same package.
Since no external RAM is required this makes for some very compact WiFi repeaters [2,3]. But all of them ship with VxWorks. I've tried to tinker with OpenWrt on this chip, but with 2-3MB free RAM after kernel boots (and that's before wifi modules are loaded), it doesn't look too good. With XIP, on the other hand, MT7688KN can potentially become a useful OpenWRT platform.
XIP was a thing with PCMCIA 2.1 25 years ago, but then it became more and more of a niche solution. I like to blame the ascent of Linux/x86 for that, at least in part.
FWIW - OpenWRT / LEDE has support for a lot of wifi routers with 4MB flash that even have a webserver and lua and some other goodies - at the moment kernel 4.9 but 4.14 is coming and here device tree will even save some space.
Well you need 32mb RAM - it runs with some hacking on 16MB ram - with execute in place probably with less...
1: https://downloads.lede-project.org/snapshots/targets/ar71xx/...