[coreboot] [PATCH]Disable failover in K8 based boards

Patrick Georgi patrick at georgi-clan.de
Wed Aug 12 23:23:00 CEST 2009

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

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.


More information about the coreboot mailing list