From 249f9ccacbaefd2f6edf693b571de9e0f57dee18 Mon Sep 17 00:00:00 2001 From: Julius Werner Date: Wed, 14 Jan 2015 14:53:59 -0800 Subject: 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 Original-Commit-Id: 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2 Original-Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03 Original-Signed-off-by: Julius Werner Original-Reviewed-on: https://chromium-review.googlesource.com/240819 Original-Reviewed-by: David Hendricks Original-Reviewed-by: Aaron Durbin Reviewed-on: http://review.coreboot.org/9732 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer --- src/soc/rockchip/rk3288/soc.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) (limited to 'src/soc/rockchip/rk3288/soc.c') 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 #include #include +#include #include #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, }; -- cgit v1.2.3