early stage debugging on a real product

[Andy Shevchenko]

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.

> 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.

> 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!

-- 
With Best Regards,
Andy Shevchenko