summaryrefslogtreecommitdiff
path: root/src/mainboard/google/link/acpi
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2017-03-17 16:54:48 -0700
committerJulius Werner <jwerner@chromium.org>2017-03-28 22:17:35 +0200
commit73d042bd90bc8877f9bfd8b846578fe3e12444c3 (patch)
tree313a7814c4c9ca76e42b5239d07037e7ea537f42 /src/mainboard/google/link/acpi
parent5fc7c2896ae0d628903144041ff13349c79f2619 (diff)
vboot: Disallow separate verstage after romstage, try to clarify logic
No board has ever tried to combine CONFIG_SEPARATE_VERSTAGE with CONFIG_VBOOT_STARTS_IN_ROMSTAGE. There are probably many reasons why this wouldn't work (e.g. x86 CAR migration logic currently always assumes verstage code to run pre-migration). It would also not really make sense: the reason we use separate verstages is to decrease bootblock size (mitigating the boot speed cost of slow boot ROM SPI drivers) and to allow the SRAM-saving RETURN_FROM_VERSTAGE trick, neither of which would apply to the after-romstage case. It is better to just forbid that case explicitly and give programmers more guarantees about what the verstage is (e.g. now the assumption that it runs pre-RAM is always valid). Since Kconfig dependencies aren't always guaranteed in the face of 'select' statements, also add some explicit compile-time assertions to the vboot code. We can simplify some of the loader logic which now no longer needs to provide for the forbidden case. In addition, also try to make some of the loader logic more readable by writing it in a more functional style that allows us to put more assertions about which cases should be unreachable in there, which will hopefully make it more robust and fail-fast with future changes (e.g. addition of new stages). Change-Id: Iaf60040af4eff711d9b80ee0e5950ce05958b3aa Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18983 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
Diffstat (limited to 'src/mainboard/google/link/acpi')
0 files changed, 0 insertions, 0 deletions