diff options
| author | Julius Werner <jwerner@chromium.org> | 2015-01-14 14:53:59 -0800 |
|---|---|---|
| committer | Patrick Georgi <pgeorgi@google.com> | 2015-04-17 09:23:49 +0200 |
| commit | 249f9ccacbaefd2f6edf693b571de9e0f57dee18 (patch) | |
| tree | 6ba47c594662b2eaf5f52514844c2aef4292ba70 /src/soc/rockchip/rk3288/include | |
| parent | deaaab25365b093229836d4294b1868093df7c47 (diff) | |
| download | coreboot-249f9ccacbaefd2f6edf693b571de9e0f57dee18.tar.xz | |
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>
Diffstat (limited to 'src/soc/rockchip/rk3288/include')
| -rw-r--r-- | src/soc/rockchip/rk3288/include/soc/memlayout.ld | 1 | ||||
| -rw-r--r-- | src/soc/rockchip/rk3288/include/soc/soc.h | 8 |
2 files changed, 1 insertions, 8 deletions
diff --git a/src/soc/rockchip/rk3288/include/soc/memlayout.ld b/src/soc/rockchip/rk3288/include/soc/memlayout.ld index 7a8b77ccaa..f5d3ca84d4 100644 --- a/src/soc/rockchip/rk3288/include/soc/memlayout.ld +++ b/src/soc/rockchip/rk3288/include/soc/memlayout.ld @@ -31,6 +31,7 @@ SECTIONS RAMSTAGE(0x00200000, 128K) POSTRAM_CBFS_CACHE(0x01000000, 1M) DMA_COHERENT(0x10000000, 2M) + FRAMEBUFFER(0x10800000, 8M) SRAM_START(0xFF700000) TTB(0xFF700000, 16K) diff --git a/src/soc/rockchip/rk3288/include/soc/soc.h b/src/soc/rockchip/rk3288/include/soc/soc.h index c6ab7f46f6..05f54da1c3 100644 --- a/src/soc/rockchip/rk3288/include/soc/soc.h +++ b/src/soc/rockchip/rk3288/include/soc/soc.h @@ -27,12 +27,4 @@ #define RK_SETBITS(set) RK_CLRSETBITS(0, set) #define RK_CLRBITS(clr) RK_CLRSETBITS(clr, 0) -#define FB_SIZE_KB 8192 -#define RAM_BASE_KB ((uintptr_t)_dram >> 10) -#define RAM_SIZE_KB (CONFIG_DRAM_SIZE_MB << 10UL) - -static inline u32 get_fb_base_kb(void) -{ - return RAM_BASE_KB + RAM_SIZE_KB - FB_SIZE_KB; -} #endif |