> 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.
Try counters rely on userspace controlling them. You need to have the crossystem utility (part of vboot) available in userspace and all hooked up correctly so that coreboot and crossystem read and write the same NVRAM (I think this sort of works by default with x86 CMOS, on Arm not so much). Then you can run stuff like "crossystem fw_try_next=B fw_try_count=1", it should boot RW_B once and boot RW_A again on the next boot (assuming your hang happens after verstage, of course). (If you set fw_try_count=0, it will just keep booting the current slot forever. Note that there's no way to automatically fall to recovery mode (RO) with this, that only happens when explicitly triggered by code.) However, vboot isn't really trying to solve this kind of problem and I don't think we should try to bend it to be something else. I agree that it would be better to implement this separately, and that separate FMAP sections would be a cleaner implementation. (It would be nice if we could eventually retire CONFIG_CBFS_PREFIX then, the whole fallback/... thing in all our images is just confusing to most people.) > 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. Are we abandoning the idea to verify individual files instead (once someone has time to implement it) then? I'd still think that would be a nicer solution to get more flexible verification. _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
