Images of U#

Tue, 17 Jul 2018 16:27:37 +0000

Last week I outlined a plan that uses kexec to reboot into a new image without access to U-Boot or having to flash it. Because I don't think an upgrade path that required popping the top off every device and attaching a serial console cable is much of a path.

Getting kexec to work turned out to involve a little more work than I think I was hoping for, mostly because I want to be able to boot the same uImage from kexec as will be flashed and booted from u-boot, and the kexec userland utility on MIPS doesn't support uImage format.

• On ARM it does, but on ARM it only understands a uImage with a zImage inside it.

• On ARM64 it does, and the payload is "typically an Image, Image.gz or Image.lzma file". Note that an Image.gz is not the same as a zImage (the latter is, if I understand correctly, self-decompressing)

• On PPC, according to the internet "the uImage usually contains the compressed "final" kernel and not a tiny wrapper which relocates itself und uncomprosses the final kernel to its final position. Instead we uncompress the gzip image and put it the its final position.". Glad that's clear

• On SH it works like ARM

• On the other nine architectures that kexec supports, there is nothing in there for uImages. Though to be fair, probably they don't use U-boot.

Conclusion: someone somewhere needs to get a grip, though I'm open to the possibility that it's me.

On MIPS, a uImage file contains a raw binary file - this is not the same thing as an Image - which has optionally been compressed by gzip or by lzma (though, note, not by xz in its lzma compatibility mode, which generates streaming files that u-boot can't load). Which is basically another way of saying "none of the above, and there isn't a lot of code in kexec you can reuse either".

Getting the payload out of the uImage is fairly painless: we just had to add an offset . But then we have to decompress it. The existing lzma decompression code in kexec works only on files, so we can't reuse it here because the data is in memory already. So we have to write a whole new bunch of code to decompress LZMA in RAM.

Some day I will submit this upstream, but I think it could stand some considerable cleanup first. For the moment I've added it as a patch to our kexectools derivation.

Next week: actually implement the kexec reboot/upgrade dance. Then maybe move my archive disk onto the new box, so we can start work on the broadband router.