early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko <andy.shevchenko at gmail.com> wrote:
>
> On Wed, Nov 25, 2020 at 1:41 AM Simon Glass <sjg at chromium.org> wrote:
> > On Tue, 24 Nov 2020 at 12:46, Andy Shevchenko <andy.shevchenko at gmail.com> wrote:
> > > On Tue, Nov 24, 2020 at 6:54 PM Simon Glass <sjg at chromium.org> wrote:
> > > > On Tue, 24 Nov 2020 at 06:57, Andy Shevchenko <andy.shevchenko at gmail.com> wrote:
>
> ...
>
> > > > Did you get the console working?
> > >
> > > Nope. The PCI (framebuffer) driver is not getting probed.
>
> Can you elaborate how Gfx PCI driver is supposed to be enumerated in
> the DM model?

I think you should be more worried about the UART!

If graphics has been started up earlier, then I don't know if you can
do it again, nor how you can find out the video parameters to use.

I'm guessing you are not using the FSP in U-Boot, so fsp_graphics.c is
not being used. Perhaps you have enabled vesa.c but it expects to be
able to run the video ROM. There is also drivers/video/coreboot.c
which reads a coreboot table to find out where the frame buffer is
used. For Broadwell there is a special driver at
drivers/video/broadwell_igd.c

Note that graphics uses lazy init, like everything else in U-Boot, so
unless you have 'vidconsole' in your stdout it won't actually init it.
You can use something like this to force probing video:

struct udevice *dev;
int ret = uclass_first_device_err(UCLASS_VIDEO, &dev);

Regards,
Simon