rk3288: Handle framebuffer through memlayout, not the resource system

We've traditionally tucked the framebuffer at the end of memory (above
CBMEM) on ARM and declared it reserved through coreboot's resource
allocator. This causes depthcharge to mark this area as reserved in the
kernel's device tree, which may be necessary to avoid display corruption
on handoff but also wastes space that the OS could use instead.

Since rk3288 boards now have proper display shutdown code in
depthcharge, keeping the framebuffer memory reserved across the handoff
(and thus throughout the lifetime of the system) should no longer be
necessary. For now let's just switch the rk3288 implementation to define
it through memlayout instead, which is not communicated through the
coreboot tables and will get treated as normal memory by depthcharge.
Note that this causes it to get wiped in developer/recovery mode, which
should not be a problem because that is done in response to VbInit()
(long before any images are drawn) and 0 is the default value for a
corebootfb anyway (a black pixel).

Eventually, we might want to think about adding more memory types to
coreboot's resource system (e.g. "reserved until kernel handoff", or
something specifically for the frame buffer) to model this situation
better, and maybe merge it with memlayout somehow.

CQ-DEPEND=CL:239470
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes
than before (curiously not 0x80000 bytes, I guess there's some alignment
waste in the kernel somewhere). Made sure the memory map output from
coreboot looks as expected, there's no visible display corruption in
developer/recovery mode and the 'cbmem' utility still works.

Change-Id: I12b7bfc1b7525f5a08cb7c64f0ff1b174df252d4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2
Original-Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240819
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9732
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>

1 files changed, 9 insertions, 2 deletions

diff --git a/src/arch/arm/include/arch/memlayout.h b/src/arch/arm/include/arch/memlayout.h
index 2c733946a2..1cba7bd325 100644
--- a/src/arch/arm/include/arch/memlayout.h
+++ b/src/arch/arm/include/arch/memlayout.h
@@ -22,6 +22,8 @@
 #ifndef __ARCH_MEMLAYOUT_H
 #define __ARCH_MEMLAYOUT_H
 
+#define SUPERPAGE_SIZE ((1 + IS_ENABLED(CONFIG_ARM_LPAE)) * 1M)
+
 #define TTB(addr, size) \
 	REGION(ttb, addr, size, 16K) \
 	_ = ASSERT(size >= 16K + IS_ENABLED(CONFIG_ARM_LPAE) * 32, \
@@ -36,8 +38,13 @@
 #define STACK(addr, size) REGION(stack, addr, size, 8)
 
 #define DMA_COHERENT(addr, size) \
-	REGION(dma_coherent, addr, size, (1 + IS_ENABLED(CONFIG_ARM_LPAE)) * 1M) \
-	_ = ASSERT(size % ((1 + IS_ENABLED(CONFIG_ARM_LPAE)) * 1M) == 0, \
+	REGION(dma_coherent, addr, size, SUPERPAGE_SIZE) \
+	_ = ASSERT(size % SUPERPAGE_SIZE == 0, \
 		"DMA coherency buffer must fit exactly in full superpages!");
 
+#define FRAMEBUFFER(addr, size) \
+	REGION(framebuffer, addr, size, SUPERPAGE_SIZE) \
+	_ = ASSERT(size % SUPERPAGE_SIZE == 0, \
+		"Framebuffer must fit exactly in full superpages!");
+
 #endif /* __ARCH_MEMLAYOUT_H */