early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Wed, 25 Nov 2020 at 08:07, Andy Shevchenko <andy.shevchenko at gmail.com> wrote:
>
> On Wed, Nov 25, 2020 at 4:50 PM Simon Glass <sjg at chromium.org> wrote:
> > 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!
>
> How? There is no UART (there are ports, but all of them are occupied
> by real devices wired up). The only connector is microB and getting
> USB to work in a gadget mode seems to me a harder task to achieve.

The board designers should be severely punished. Do you have post codes?

Some boards have an FTDI chip to do the USB/serial conversion but I
guess your one does not.

>
> > 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.
>
> That is my question, how to start a PCI subsystem in U-Boot.
> In DM model it seems some should actually call one of PCI function
> against device. AFAIU the vidconsole driver should find somehow the
> adapter in DT or so and load
>
> > I'm guessing you are not using the FSP in U-Boot, so fsp_graphics.c is
> > not being used.
>
> No, it's not.
>
> > Perhaps you have enabled vesa.c but it expects to be
> > able to run the video ROM.
>
> There is no video ROM as far as I can tell.
>
> > 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.
>
> I have no environment for now (ENV_IS_NO_WHERE) and I have provided
>
> #define CONFIG_STD_DEVICES_SETTINGS     "stdin=serial\0" \
>                                        "stdout=vidconsole\0" \
>                                        "stderr=vidconsole\0"
>
> in the configuration header. Not sure if it's correct and/or enough.

Should be fine.

>
> > You can use something like this to force probing video:
> >
> > struct udevice *dev;
> > int ret = uclass_first_device_err(UCLASS_VIDEO, &dev);
>
> I will try this, thanks!

But you'll need to select the driver, or write one that finds the
frame buffer. Is video already set up by the earlier loader?

Regards,
Simon