On Tue, Jan 22, 2019 at 6:45 AM Arthur Heymans <art...@aheymans.xyz> wrote:
> 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-le...@coreboot.org >
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
