From eda20b677f55707eb84c98bf04a15ec5b9eb3c33 Mon Sep 17 00:00:00 2001 From: Julius Werner Date: Mon, 1 Jul 2019 16:44:01 -0700 Subject: vboot: Use CONFIG_VBOOT_MIGRATE_WORKING_DATA on all platforms When we added CONFIG_VBOOT_MIGRATE_WORKING_DATA, the idea was that on some Arm platforms the original working data buffer was in SRAM, which stays accessbile for the whole runtime of the system. There is no reason to migrate it into CBMEM on those platforms because ramstage and the payload could continue to access it in SRAM. Now that we've had a couple of months of experience with this option, we found that most of our Arm platforms have some issue that requires migrating anyway, because BL31 often claims SRAM for itself and makes it inaccessible to the payload. On the remaining platforms, accessing SRAM from the payload is possible but still an issue, because libpayload doesn't have enough memory layout information to set up proper page tables for it, so we're accessing it uncached and at risk of alignment errors. Rather than having to figure out how to map the right SRAM range for every platform in the payload, let's just get rid of the option. memcpy()ing 12KB isn't worth this much hassle. Change-Id: I1b94e01c998f723c8950be4d12cc8f02b363a1bf Signed-off-by: Julius Werner Reviewed-on: https://review.coreboot.org/c/coreboot/+/33952 Tested-by: build bot (Jenkins) Reviewed-by: Joel Kitching Reviewed-by: Paul Menzel Reviewed-by: Hung-Te Lin --- src/soc/rockchip/rk3399/Kconfig | 1 - 1 file changed, 1 deletion(-) (limited to 'src/soc/rockchip') diff --git a/src/soc/rockchip/rk3399/Kconfig b/src/soc/rockchip/rk3399/Kconfig index 897a5979d4..83fc437073 100644 --- a/src/soc/rockchip/rk3399/Kconfig +++ b/src/soc/rockchip/rk3399/Kconfig @@ -17,7 +17,6 @@ config SOC_ROCKCHIP_RK3399 if SOC_ROCKCHIP_RK3399 config VBOOT - select VBOOT_MIGRATE_WORKING_DATA select VBOOT_SEPARATE_VERSTAGE select VBOOT_RETURN_FROM_VERSTAGE select VBOOT_MUST_REQUEST_DISPLAY -- cgit v1.2.3