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 <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33952
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Joel Kitching <kitching@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>

1 files changed, 0 insertions, 1 deletions

diff --git a/src/soc/qualcomm/qcs405/Kconfig b/src/soc/qualcomm/qcs405/Kconfig
index e24993a2f0..aa867c2f25 100644
--- a/src/soc/qualcomm/qcs405/Kconfig
+++ b/src/soc/qualcomm/qcs405/Kconfig
@@ -19,7 +19,6 @@ config VBOOT
 	select VBOOT_SEPARATE_VERSTAGE
 	select VBOOT_RETURN_FROM_VERSTAGE
 	select VBOOT_STARTS_IN_BOOTBLOCK
-	select VBOOT_MIGRATE_WORKING_DATA
 
 config QCS405_BLSP_SPI
 	bool