New mechanism to define SRAM/memory map with automatic bounds checking

This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.

The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).

BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.

Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>

1 files changed, 0 insertions, 55 deletions

diff --git a/src/soc/samsung/exynos5250/Kconfig b/src/soc/samsung/exynos5250/Kconfig
index 3c7d6c4e77..4126ec1e59 100644
--- a/src/soc/samsung/exynos5250/Kconfig
+++ b/src/soc/samsung/exynos5250/Kconfig
@@ -32,59 +32,4 @@ config CBFS_ROM_OFFSET
 	hex "offset of CBFS data in ROM"
 	default 0x0A080
 
-config SYS_SDRAM_BASE
-	hex
-	default 0x40000000
-
-# Example SRAM/iRAM map for Exynos5250 platform:
-#
-# 0x0202_0000: vendor-provided BL1
-# 0x0202_3400: bootblock, assume up to 32KB in size
-# 0x0203_0000: romstage, assume up to 128KB in size.
-# 0x0207_8000: stack pointer
-
-config BOOTBLOCK_BASE
-	hex
-	default 0x02023400
-
-config ROMSTAGE_BASE
-	hex
-	default 0x02030000
-
-config RAMSTAGE_BASE
-	hex
-	default SYS_SDRAM_BASE
-
-# Stack may reside in either IRAM or DRAM. We will define it to live
-# at the top of IRAM for now.
-#
-# Stack grows downward, push operation stores register contents in
-# consecutive memory locations ending just below SP
-config STACK_TOP
-	hex
-	default 0x02078000
-
-config STACK_BOTTOM
-	hex
-	default 0x02074000
-
-config STACK_SIZE
-	hex
-	default 0x4000
-
-# TODO We may probably move this to board-specific implementation files instead
-# of KConfig values.
-config CBFS_CACHE_ADDRESS
-	hex "memory address to put CBFS cache data"
-	default 0x0205c000
-
-config CBFS_CACHE_SIZE
-	hex "size of CBFS cache data"
-	default 0x00018000
-
-# TTB needs to be aligned to 16KB.
-config TTB_BUFFER
-	hex "memory address of the TTB buffer"
-	default 0x02058000
-
 endif