diff options
author | Julius Werner <jwerner@chromium.org> | 2020-03-02 15:54:43 -0800 |
---|---|---|
committer | Julius Werner <jwerner@chromium.org> | 2020-05-09 00:21:59 +0000 |
commit | 29fbfcc472462e317e5dcf659523689f28bbfd98 (patch) | |
tree | 1034d9383bbdfdf8de648071213c18f019f861ce /src/mainboard/amd/gardenia/gpio.c | |
parent | 192a12fb6ab0b4a2033f087cec8a232d42a4c000 (diff) |
vboot: Clean up pre-RAM use of vboot_recovery_mode_enabled()
vboot_recovery_mode_enabled() was recently changed to assert() when it
is called before vboot logic has run, because we cannot determine
whether we're going to be in recovery mode at that point and we wanted
to flush out existing uses that pretended that we could. Turns out there
are a bunch of uses like that, and there is some code that is shared
across configurations that can and those that can't.
This patch cleans them up to either remove checks that cannot return
true, or add explicit Kconfig guards to clarify that the code is shared.
This means that using a separate recovery MRC cache is no longer
supported on boards that use VBOOT_STARTS_IN_ROMSTAGE (this has already
been broken with CB:38780, but with this patch those boards will boot
again using their normal MRC caches rather than just die). Skipping the
MRC cache and always regenerating from scratch in recovery mode is
likewise no longer supported for VBOOT_STARTS_IN_ROMSTAGE.
For FSP1.1 boards, none of them support VBOOT_STARTS_IN_BOOTBLOCK and
that is unlikely to change in the future so we will just hardcode that
fact in Kconfig (otherwise, fsp1.1 raminit would also have to be fixed
to work around this issue).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I31bfc7663724fdacab9955224dcaf650d1ec1c3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39221
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Diffstat (limited to 'src/mainboard/amd/gardenia/gpio.c')
0 files changed, 0 insertions, 0 deletions