From patchwork Sun May 10 20:17:02 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Glass X-Patchwork-Id: 245481 List-Id: U-Boot discussion From: sjg at chromium.org (Simon Glass) Date: Sun, 10 May 2020 14:17:02 -0600 Subject: [PATCH v2 39/39] bdinfo: x86: vesa: Update fb_base to the correct value In-Reply-To: <20200510201702.196031-1-sjg@chromium.org> References: <20200510201702.196031-1-sjg@chromium.org> Message-ID: <20200510201702.196031-31-sjg@chromium.org> Set this value in global_data so that it is reported correctly on x86 boards. In fact, U-Boot allocates space for the frame buffer even though it is not used. Then the FSP picks the address itself (e.g. 0xb0000000). So the value set by U-Boot (high in memory with everything else that is relocated), is not actually the correct value. Signed-off-by: Simon Glass Reviewed-by: Bin Meng --- Changes in v2: - Update the commit message to explain the address more arch/x86/lib/fsp/fsp_graphics.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/lib/fsp/fsp_graphics.c b/arch/x86/lib/fsp/fsp_graphics.c index 98b762209f..46fb907dc3 100644 --- a/arch/x86/lib/fsp/fsp_graphics.c +++ b/arch/x86/lib/fsp/fsp_graphics.c @@ -96,6 +96,7 @@ static int fsp_video_probe(struct udevice *dev) * For IGD, it seems to be always on BAR2. */ vesa->phys_base_ptr = dm_pci_read_bar32(dev, 2); + gd->fb_base = vesa->phys_base_ptr; ret = vbe_setup_video_priv(vesa, uc_priv, plat); if (ret) @@ -104,8 +105,8 @@ static int fsp_video_probe(struct udevice *dev) mtrr_add_request(MTRR_TYPE_WRCOMB, vesa->phys_base_ptr, 256 << 20); mtrr_commit(true); - printf("%dx%dx%d\n", uc_priv->xsize, uc_priv->ysize, - vesa->bits_per_pixel); + printf("%dx%dx%d @ %x\n", uc_priv->xsize, uc_priv->ysize, + vesa->bits_per_pixel, vesa->phys_base_ptr); return 0;