How the ARM32 Linux kernel decompresses
people.kernel.org
people.kernel.org
They're doing all of this on systems frequently running off of 16 or 32GB flash devices. The difference in cost between manufacturing a 16MB flash device and a 512MB flash device these days must be minuscule.
When I made consumer electronics our production team would swap parts based on cost. 1c on a million units is $10,000. They only had to save a few cents a year each to easily pay for themselves.
The rest was margin for the business.
Saving cents on a $80 BOM (bill of materials) may not sound like much but it really does add up when you're doing volume manufacturing.
Once, the production team swapped a component as part of a running change and it took a programmer nearly a month to write the new driver.
I think we still came out ahead in the end but there was some worry along the way as it wasn't clear how long it was going to take.
And at that size, compression more than doubles what you can pack alongside the kernel.
Plus there are things like [e]MMC's "boot" area, where a special storage area is simpler to read using a simpler special protocol. That area has a limited size.
Edited to add: A lot of performance loss for large, complex systems is death-by-a-thousand-cuts -- 20ms here and there can make a real, user-perceivable difference.
When optimizing boot time of an embedded system something like 100 ms is a significant saving once you've picked all the low hanging fruit in the user space init side. In the end, every millisecond counts as it all adds up when there are hundred or so places where they may end up being spent needlesly. An embedded product, especially automotive, might have rather strict boot time requirements.
The time it takes for a bootloader to load a kernel image can be a decent part of the boot time. The bootloader most likely won't be running the SDHCI controller in any of the faster modes that require implementing bus training, calibration, and tuning algorithms of varying complexity.
Incidentally, aarch64 kernels do not include a decompressor -- if you want to compress the kernel image then it is the job of the bootloader to uncompress it. Different primary market, different time, different constraints, opportunity to choose differently, different outcome...
2Gbit is the highest commercially available package (with very few suppliers, so it carries extra risk).
There are also quite a few lines of MCUs without built-in flash memory and those typically boot from external NOR flash.
> So SBC… Which means playing with U-Boot. In the past it meant random fork of it. [...] you have bootloader(s) built. The next step is taking microsd card, finding out which offsets to use. Then put bootloader(s) at proper places so CPU can read them and boot. Usually it also means that you have to use MBR style formatting [...]
The reason? A EEPROM chip is too expensive, an astronomical cost of $3! The author was half-joking, but only serious - $3 is really expensive for most single-board computers.
> The solution is SPI flash chip. But it is very expensive - 3 (three) EUR for 512Mb (64MB) chip (if bought 1000 of them). Far too much for 99.99% of SBC probably. Probably 64/128Mb will be enough even. And they are cheaper (128Mb is 1.7 EUR). Still too expensive…
[0] https://marcin.juszkiewicz.com.pl/2020/01/29/the-most-expens...
Note that this is ARM32, which is more or less a legacy platform, raising the concern of whether compression is relevant anymore is irrelevant since it's legacy already. As the article says,
> ARM __traditionally__ uses compressed kernels. This is intended as a comprehensive rundown of how the Linux kernel self-decompresses on ARM 32-bit __legacy systems__.
I wonder if the Google Home next to me is aarch64. The "new" router that is sending my packets to this site is MIPS on an even more ancient software stack.