[36/36] bdinfo: x86: vesa: Update fb_base to the correct value

Set this value in global_data so that it is reported correctly on x86
boards.

In fact, space is allocated for the frame buffer even though it is not
used. The FSP picks the address itself, which is why the current value
is wrong.

Signed-off-by: Simon Glass <sjg at chromium.org>
---

 arch/x86/lib/fsp/fsp_graphics.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Hi Simon,

On Tue, May 5, 2020 at 7:19 AM Simon Glass <sjg at chromium.org> wrote:
>
> Set this value in global_data so that it is reported correctly on x86
> boards.
>
> In fact, space is allocated for the frame buffer even though it is not
> used. The FSP picks the address itself, which is why the current value
> is wrong.

I don't get it about the "current value is wrong"?

>
> Signed-off-by: Simon Glass <sjg at chromium.org>
> ---
>
>  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;
>

Reviewed-by: Bin Meng <bmeng.cn at gmail.com>

Regards,
Bin