Myles Watson schrieb:
If Koenig doesn't support fallback and normal yet, maybe that should come first.
fallback/normal was a fine solution for pre-CBFS images. I'm not convinced it still is.
A safe update method is the main use case for fallback/normal I've heard about so far. With CBFS, updating an image is harder than before. pre-CBFS, you could simply dd(1) the old and the new image in some ways and get a new image with a new normal image and an old fallback image. With CBFS, you don't have such a clean alignment of the data inside the image, so you'll have to extract the pieces and add them to the other image.
I propose this approach instead: - You can configure the build to create a new ROM image, or append to an existing one - You can configure the build to add the newly created code as "fallback" or "normal" - You can configure the build to rename pre-existing "normal" CBFS files to "fallback" - There's a switch somewhere in the code that runs "fallback" if it exists and the previous boot didn't succeed, and runs "normal" otherwise. - The bootblock is usually not touched on update (which also means that we have to move more code from there to CBFS to make any update process more useful)
That way, the build process builds only one variant of the code. When you update, the existing variant is renamed (so it can act as fallback if the new code breaks).
The other thing fallback/normal is used for is CMOS-aware code with recovery if CMOS is invalid. But it's flawed as it is: When the "normal image" bit is set correctly, and everything else is wrong, normal is run, and probably hangs (it did for me). What _should_ happen (in my opinion) is that we use the CMOS checksum, and have the same code use a static field (somewhere in ROM) as a backup if the CMOS values can't be trusted.
That could work by extending the cmos.layout file with defaults that are written to some static C array, which is linked in. get_option (I think that's what the CMOS access code is called) switches between CMOS and this table based on the CMOS checksum. This is more stable than the current approach and gets rid of a second binary (probably with different behaviour beyond the config values!), too.
What other use cases for fallback/normal are there that must be accounted for?
In general removing features is easier than adding them. Will this make it easier to add it later?
The change can be reverted with little effort: set CONFIG_HAVE_FAILOVER_BOOT to 1, add failover to the Config-abuild.lb again, and it works as it does now. I didn't remove the #ifs for FAILOVER etc. to easily figure out what parts of the code are "early setup" and what's later code, so we can reuse it, should we want to.
Patrick