summaryrefslogtreecommitdiff
path: root/src/soc/rockchip
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2015-01-14 14:53:59 -0800
committerPatrick Georgi <pgeorgi@google.com>2015-04-17 09:23:49 +0200
commit249f9ccacbaefd2f6edf693b571de9e0f57dee18 (patch)
tree6ba47c594662b2eaf5f52514844c2aef4292ba70 /src/soc/rockchip
parentdeaaab25365b093229836d4294b1868093df7c47 (diff)
downloadcoreboot-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')
-rw-r--r--src/soc/rockchip/rk3288/cbmem.c4
-rw-r--r--src/soc/rockchip/rk3288/include/soc/memlayout.ld1
-rw-r--r--src/soc/rockchip/rk3288/include/soc/soc.h8
-rw-r--r--src/soc/rockchip/rk3288/soc.c12
4 files changed, 8 insertions, 17 deletions
diff --git a/src/soc/rockchip/rk3288/cbmem.c b/src/soc/rockchip/rk3288/cbmem.c
index 1c3a902d0e..2eed97281a 100644
--- a/src/soc/rockchip/rk3288/cbmem.c
+++ b/src/soc/rockchip/rk3288/cbmem.c
@@ -18,11 +18,11 @@
*/
#include <cbmem.h>
-#include <soc/soc.h>
#include <stddef.h>
+#include <symbols.h>
void *cbmem_top(void)
{
- return (void *)(get_fb_base_kb()*KiB);
+ return _dram + (size_t)CONFIG_DRAM_SIZE_MB*MiB;
}
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
diff --git a/src/soc/rockchip/rk3288/soc.c b/src/soc/rockchip/rk3288/soc.c
index abd93d70f0..fa26c6db36 100644
--- a/src/soc/rockchip/rk3288/soc.c
+++ b/src/soc/rockchip/rk3288/soc.c
@@ -28,30 +28,28 @@
#include <stddef.h>
#include <stdlib.h>
#include <string.h>
+#include <symbols.h>
#include <vendorcode/google/chromeos/chromeos.h>
#include "chip.h"
static void soc_init(device_t dev)
{
- unsigned long fb_size = FB_SIZE_KB * KiB;
- u32 lcdbase = get_fb_base_kb() * KiB;
-
- ram_resource(dev, 0, RAM_BASE_KB, RAM_SIZE_KB);
- mmio_resource(dev, 1, lcdbase / KiB, fb_size / KiB);
+ ram_resource(dev, 0, (uintptr_t)_dram/KiB,
+ CONFIG_DRAM_SIZE_MB*(MiB/KiB));
if (vboot_skip_display_init())
printk(BIOS_INFO, "Skipping display init.\n");
#if !IS_ENABLED(CONFIG_SKIP_DISPLAY_INIT_HACK)
else
- rk_display_init(dev, lcdbase, fb_size);
+ rk_display_init(dev, (uintptr_t)_framebuffer,
+ _framebuffer_size);
#endif
}
static struct device_operations soc_ops = {
.read_resources = DEVICE_NOOP,
.set_resources = DEVICE_NOOP,
- .enable_resources = DEVICE_NOOP,
.init = soc_init,
.scan_bus = 0,
};