rk3399: Reserve enough framebuffer memory for 32bpp hires panels
Some of our RK3399 devices have panel resolutions as high as 2400x1600. With 16bpp that barely still fit into an 8MB framebuffer, but then we changed it to 32bpp for better image quality... Note that this is a band-aid. Coreboot-allocated framebuffers shouldn't be used at all on ARM64 devices, since libpayload is perfectly capable to dynamically allocate it with the right size based on EDID-information on this architecture. That will require some more elaborate work to be fixed with later patches. BRANCH=gru BUG=chrome-os-partner:58044 TEST=Warm-reboot Kevin on the dev screen, confirm that you don't see the lower half of the screen that overflowed our allocated framebuffer preserved from the last boot as soon as the backlight turns on. Change-Id: Ia1fa28971c65d7d0639966e715f742309245172b Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/399966 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This commit is contained in:
parent
7c483951a0
commit
d2718efcac
1 changed files with 1 additions and 1 deletions
|
|
@ -22,7 +22,7 @@ SECTIONS
|
|||
POSTRAM_CBFS_CACHE(0x00100000, 1M)
|
||||
RAMSTAGE(0x00300000, 256K)
|
||||
DMA_COHERENT(0x10000000, 2M)
|
||||
FRAMEBUFFER(0x10200000, 8M)
|
||||
FRAMEBUFFER(0x10200000, 16M)
|
||||
|
||||
/* 8K of special SRAM in PMU power domain. */
|
||||
SYMBOL(pmu_sram, 0xFF3B0000)
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue