[coreboot-gerrit] Patch merged into coreboot/master: 249f9cc rk3288: Handle framebuffer through memlayout, not the resource system

[gerrit at coreboot.org]

the following patch was just integrated into master:
commit 249f9ccacbaefd2f6edf693b571de9e0f57dee18
Author: Julius Werner <jwerner at chromium.org>
Date:   Wed Jan 14 14:53:59 2015 -0800

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


See http://review.coreboot.org/9732 for details.

-gerrit