rockchip/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: I00a63cfef35a8ee734543abbdb298344fb529283
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d2718efcacb50371624d9f6a3b586c298e8c2fec
Original-Change-Id: Ia1fa28971c65d7d0639966e715f742309245172b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/399966
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/17108
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>

src/soc/rockchip/rk3399/include/soc/memlayout.ld

@@ -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)