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.
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?
Kind regards
Arthur Heymans