]> git.dujemihanovic.xyz Git - u-boot.git/commit
sunxi: store DRAM size in SPL header
authorAndre Przywara <andre.przywara@arm.com>
Thu, 25 Oct 2018 09:23:07 +0000 (17:23 +0800)
committerJagan Teki <jagan@amarulasolutions.com>
Mon, 29 Oct 2018 15:11:15 +0000 (20:41 +0530)
commit5776610e9ef022e2d8a15793d4b9955c3f8076ed
tree04edf763dc3f6e3a0a6e2302a20597c88ab95c06
parentf8aa3f8d84af6e9ae0dce9c3577d342c6a013b14
sunxi: store DRAM size in SPL header

At the moment we rely on the infamous get_ram_size() function to learn
the actual DRAM size in U-Boot proper. This function has two issues:
1) It only works if the DRAM size is a power of two. We start to see
boards which have 3GB of (usable) DRAM, so this does not fit anymore.
2) As U-Boot has no notion of reserved memory so far, it will happily
ride through the DRAM, possibly stepping on secure-only memory. This
could be a region of DRAM reserved for OP-TEE or some other secure
payload, for instance. It will most likely crash in that case.

As the SPL DRAM init routine has very accurate knowledge of the actual
DRAM size, lets propagate this wisdom to U-Boot proper.
We re-purpose a currently reserved word in our SPL header for that.
The SPL itself stores the detected DRAM size there, and bumps the SPL
header version number in that case. U-Boot proper checks for a valid
SPL header and a high enough version number, then uses the DRAM size
from there. If the SPL header field is not sufficient, we fall back to
the old DRAM scanning routine.

Part of the DRAM might be present and probed by SPL, but not accessible
by the CPU. They're restricted in the main U-Boot binary, when accessing
the DRAM size from SPL header.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
arch/arm/include/asm/arch-sunxi/spl.h
board/sunxi/board.c