early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Wed, 25 Nov 2020 at 08:35, Andy Shevchenko <andy.shevchenko at gmail.com> wrote:
>
> On Wed, Nov 25, 2020 at 5:23 PM Simon Glass <sjg at chromium.org> wrote:
> > 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:
>
> ...
>
> > > > 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.
>
> It's not a board. As I stated in the subject line it's a real product
> (tablet / phone).

Oh dear, that is certainly harder. Presumably there is a debug
connector or pads somewhere but you don't have it.

>
> ...
>
> > > > 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.
>
> Thanks. But the question is still open why DM PCI et al. is not
> getting initialized.

PCI should come up so long as you have a PCI driver. See the various
other boards - you need a pci-x86 device:

        pci {
                compatible = "pci-x86";
                u-boot,dm-pre-reloc;
        };

>
> ...
>
> > > > 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?
>
> Yes, there is an initialized framebuffer by bootloader (droidboot). I
> need a glue driver that will find FB parameters and set up a graphical
> console on it.
> So far I have a custom code.

OK, well following along with the vesa driver will help a bit, and
video.h documents what fields you need to set up for the vidconsole to
work.

Regards,
Simon