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 sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
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;