Hi
As more and more x86 platforms are moving to C_ENVIRONMENT_BOOTBLOCK
and therefore don't use a romcc compiled bootblock anymore a certain
question arises. With the romcc bootblock there was a normal/fallback
mechanism.
It works the following way:
It uses RTC cmos to select between the normal and the fallback
bootpaths. So depending on that bit the bootblock selected either
normal/romstage or fallback/romstage which also load postcar stage,
ramstage and payloads with the same prefix from there. There is also a
reboot counter which makes sure that it actually gets to the point it
can load the payload and depending on CONFIG_SKIP_MAX_REBOOT_CNT_CLEAR
it resets that the counter.
This mechanism is not very robust and is more intended to be used to be
able to test things without needing a hardware programmer to flash
images in the case something goes wrong. I use it for instance to test
changes on laptops which take a long time to disassemble.
Currently C_ENVIRONMENT_BOOTBLOCK lacks such generic mechanism on x86
platforms. On the first sight it looks like VBOOT with verstage running
after the bootblock, might be able to achieve a similar boot
scheme. VBOOT seems to lack documentation and while not that hard to get
working, it looks like it is not falling back when there is problem on a
RW_A/B boot path (I called die die(); somewhere in the ramstage to
test). Also the tools around vboot (crossystem) are quite chromeos
specific, requiring Chromeos specific ACPI code exposing the VBNV
variables and also a Linux kernel exposing those ACPI methods via
sysfs.
My understanding of VBOOT might be incorrect or incomplete, so it would
be great if someone more knowledgeable could fill in here.
There's a trycount that I think defaults to 10. After 10 failing tries it should switch slots. There's also a 'set good firmware' notion which signals to the firmware one was able to boot. This is picked up on the next reboot and the information is passed through vboot non volatile storage. I can dig up specific pointers in the code, but you may not have tried enough times to see things switch.
That said, if you want to implement fallback stuff, it should be fairly straight forward to do -- and not rely on vboot.
So at the moment it looks like VBOOT does not fit the bill to be able to
quickly test things while having a fallback mechanism.
Now being able to run GCC compiled code in the bootblock does have the
advantage of allowing much more flexibility over romcc compiled code.
So it is possible to simply reimplement the same behavior with different
prefixes for bootpaths but it would also be possible to do something
similar to what vboot does, namely using separate FMAP regions for boot
paths. This would require a simple cbfs_locator. Upstream flashrom
master now supports using FMAP as a layout so it would be rather easy to
use.
Using FMAP requires a little bit more work (generating a proper default
FMAP, populate the CBFS FMAP regions, implementing a cbfs_locator) but
does allow for nice features like locking the fallback CBFS region to
make sure the fallback can't be erased by accident.
Any thought or suggestions?
FWIW, it's my opinion I think we'll need to start splitting cbfs into smaller ones. This isn't specific to this situation, but splitting slots into multiple cbfses (rw-a-1, rw-a-2, etc) allows one to chain/group resources as they are used along with more flexibility for signing/verification methods. What you wrote above seems sane, but I think you'll run into build limitations that don't allow one to target fmap regions for different assets. It's a lot of Make w/ some special casing currently which is because people didn't want another tool at the time -- however, once you need more cbfs regions of different granularity I think having better tooling around targeting final destination for assets is required.
Kind regards
Arthur Heymans
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org