Hi Julius,
On 6.04.2023 02:26, Julius Werner wrote:
Yeah, we moved the point where the recovery reason gets cleared to the payload a while ago, because otherwise it got lost when the platform decides to do extra reboots. For example, some Intel SoCs do CSE sync in ramstage, and sometimes when they do that they need to do an extra reboot. When we used to clear the recovery reason in verstage, that extra reboot after that point meant we weren't in recovery mode anymore when we finally reached the payload.
Exactly, the reboots are the main problem when having recovery clear in verstage.
I don't mind renaming vb2_clear_recovery() to vb2api_clear_recovery() and making it available in the public API. Then you can either add code somewhere to the end of coreboot to call it (but with a Kconfig that excludes ChromeOS) or link your payload to vboot and call it from there (which might be useful if your payload also has situations where it may need to do an extra reboot). Happy to review a patch to vboot if you want to send one.
In general though, I think you really need payload or OS integration if you want to have a useful recovery mode. Recovery mode usually means something is actually broken that needs to be fixed (e.g. RW partition corrupted from a bad update), and coreboot alone can't fix it. So we can clear the recovery condition wherever it works best, but you still need to implement the part that will actually fix the system somewhere.
Payload and OS integration is one thing. What I still didn't figure out is how to tell vboot to check if RW partition is valid? Imagine the platform is in recovery mode and I have flashed the RW with correctly signed image. vboot will not attempt to boot from RW, because of the recovery reason being non-zero. Thus the only way I see is to clear the recovery reason. How it is solved on ChromeOS systems after updating with correct RW firmware? Is there any flag (in vboot shared data/workbuf) to tell vboot to attempt RW check despite recovery?
Best regards,