early stage debugging on a real product

early stage debugging on a real product

[Andy Shevchenko]

Hi!

I have been debugging U-Boot on a product (Android-based) device (*)
which is not yet supported by U-Boot. It's x86 based.

I have stumbled over the couple of things:
1/ it required me to enable TIMER_EARLY and by code analysing I can
tell that DM loop fails by some reason
2/ it hangs
   reserve_uboot,
   reserve_malloc,
   reserve_board,
   ...here...

My suspicion that fastboot does bad things to it (overwritten memory)
or something I have missed. Any ideas what to try / where to look into
besides the above which I'm on?

(*) Only I can get is just an approximate place where the code is
stuck / hangs. And it's time consuming...

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Andy Shevchenko]

On Mon, Nov 23, 2020 at 4:05 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> Hi!
>
> I have been debugging U-Boot on a product (Android-based) device (*)
> which is not yet supported by U-Boot. It's x86 based.
>
> I have stumbled over the couple of things:
> 1/ it required me to enable TIMER_EARLY and by code analysing I can
> tell that DM loop fails by some reason
> 2/ it hangs
>    reserve_uboot,
>    reserve_malloc,
>    reserve_board,
>    ...here...

Basically this line in reserve_board() makes it hangs (likely page fault)
              memset(gd->bd, '\0', sizeof(struct bd_info));

I run U-Boot as a chainloader.

> My suspicion that fastboot does bad things to it (overwritten memory)
> or something I have missed. Any ideas what to try / where to look into
> besides the above which I'm on?

boot.img has the following memory map:

vmlinuz: 0x10008000
initrd: 0x11000000
u-boot: 0x01101000
Net
The working android kernel shows this:
<6>[    0.000000] e820: BIOS-provided physical RAM map:
<6>[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000097fff] usable
<6>[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000003ffffff] usable
<6>[    0.000000] BIOS-e820: [mem
0x0000000004000000-0x00000000051fffff] reserved
<6>[    0.000000] BIOS-e820: [mem 0x0000000005200000-0x0000000005bfffff] usable
<6>[    0.000000] BIOS-e820: [mem
0x0000000005c00000-0x0000000005ffffff] reserved
<6>[    0.000000] BIOS-e820: [mem 0x0000000006000000-0x000000007f5fffff] usable
<6>[    0.000000] BIOS-e820: [mem
0x000000007f600000-0x00000000fec033ff] reserved
<6>[    0.000000] BIOS-e820: [mem
0x00000000fec04000-0x00000000fefff3ff] reserved
<6>[    0.000000] BIOS-e820: [mem
0x00000000ff000000-0x00000000ffffffff] reserved
<6>[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000017fffffff] usable

> (*) Only I can get is just an approximate place where the code is
> stuck / hangs. And it's time consuming...

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Mon, 23 Nov 2020 at 07:04, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> Hi!
>
> I have been debugging U-Boot on a product (Android-based) device (*)
> which is not yet supported by U-Boot. It's x86 based.
>
> I have stumbled over the couple of things:
> 1/ it required me to enable TIMER_EARLY and by code analysing I can
> tell that DM loop fails by some reason
> 2/ it hangs
>    reserve_uboot,
>    reserve_malloc,
>    reserve_board,
>    ...here...
>
> My suspicion that fastboot does bad things to it (overwritten memory)
> or something I have missed. Any ideas what to try / where to look into
> besides the above which I'm on?

#define DEBUG at the top of board_f.c - you might need DEBUG_UART

Make sure that start.S puts the top of memory in a sensible place. If
something has set up RAM already then you probably want it to be the
top of RAM, below 2GB.

>
> (*) Only I can get is just an approximate place where the code is
> stuck / hangs. And it's time consuming...
>

Use a Dediprog SPI emulator and an Intel debugger.

Regards,
Simon

early stage debugging on a real product

[Andy Shevchenko]

On Mon, Nov 23, 2020 at 9:08 PM Simon Glass <sjg@chromium.org> wrote:
> On Mon, 23 Nov 2020 at 07:04, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

Thanks! My comments below.

> > I have been debugging U-Boot on a product (Android-based) device (*)
> > which is not yet supported by U-Boot. It's x86 based.
> >
> > I have stumbled over the couple of things:
> > 1/ it required me to enable TIMER_EARLY and by code analysing I can
> > tell that DM loop fails by some reason
> > 2/ it hangs
> >    reserve_uboot,
> >    reserve_malloc,
> >    reserve_board,
> >    ...here...
> >
> > My suspicion that fastboot does bad things to it (overwritten memory)
> > or something I have missed. Any ideas what to try / where to look into
> > besides the above which I'm on?
>
> #define DEBUG at the top of board_f.c - you might need DEBUG_UART
>
> Make sure that start.S puts the top of memory in a sensible place. If
> something has set up RAM already then you probably want it to be the
> top of RAM, below 2GB.

I wasn't clear, there is no means to debug (See * below).
There is no output except vibra, perhaps I may have (charger) led, but
former I got working, maybe I need to implement morse code.

> > (*) Only I can get is just an approximate place where the code is
> > stuck / hangs. And it's time consuming...
> >
>
> Use a Dediprog SPI emulator and an Intel debugger.

Not sure how it is possible... The only connector I have is micro-B.

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Andy Shevchenko]

On Mon, Nov 23, 2020 at 9:18 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Mon, Nov 23, 2020 at 9:08 PM Simon Glass <sjg@chromium.org> wrote:
> > On Mon, 23 Nov 2020 at 07:04, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> > Make sure that start.S puts the top of memory in a sensible place. If
> > something has set up RAM already then you probably want it to be the
> > top of RAM, below 2GB.

This makes me go much further, thanks. It appears that the default
method to calculate RAM top is not correct.


-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Andy Shevchenko]

On Mon, Nov 23, 2020 at 9:08 PM Simon Glass <sjg@chromium.org> wrote:
> On Mon, 23 Nov 2020 at 07:04, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> > I have been debugging U-Boot on a product (Android-based) device (*)
> > which is not yet supported by U-Boot. It's x86 based.
> >
> > I have stumbled over the couple of things:
> > 1/ it required me to enable TIMER_EARLY and by code analysing I can
> > tell that DM loop fails by some reason
> > 2/ it hangs
> >    reserve_uboot,
> >    reserve_malloc,
> >    reserve_board,
> >    ...here...
> >
> > My suspicion that fastboot does bad things to it (overwritten memory)
> > or something I have missed. Any ideas what to try / where to look into
> > besides the above which I'm on?

> Make sure that start.S puts the top of memory in a sensible place. If
> something has set up RAM already then you probably want it to be the
> top of RAM, below 2GB.

Now I'm struggling to get *delay() working. In run_main_loop() if I
call mdelay(<whatever>) the code gets stuck (presumably by not getting
timer initialized and returning -EAGAIN).
Any ideas?

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Tue, 24 Nov 2020 at 06:57, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Mon, Nov 23, 2020 at 9:08 PM Simon Glass <sjg@chromium.org> wrote:
> > On Mon, 23 Nov 2020 at 07:04, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> > > I have been debugging U-Boot on a product (Android-based) device (*)
> > > which is not yet supported by U-Boot. It's x86 based.
> > >
> > > I have stumbled over the couple of things:
> > > 1/ it required me to enable TIMER_EARLY and by code analysing I can
> > > tell that DM loop fails by some reason
> > > 2/ it hangs
> > >    reserve_uboot,
> > >    reserve_malloc,
> > >    reserve_board,
> > >    ...here...
> > >
> > > My suspicion that fastboot does bad things to it (overwritten memory)
> > > or something I have missed. Any ideas what to try / where to look into
> > > besides the above which I'm on?
>
> > Make sure that start.S puts the top of memory in a sensible place. If
> > something has set up RAM already then you probably want it to be the
> > top of RAM, below 2GB.
>
> Now I'm struggling to get *delay() working. In run_main_loop() if I
> call mdelay(<whatever>) the code gets stuck (presumably by not getting
> timer initialized and returning -EAGAIN).
> Any ideas?

Do you mean in get_ticks() in lib/time.c ?

Some panic() calls were recently added in there to check that the
timer is ready.

Did you get the console working?

Regards,
Simon

early stage debugging on a real product

[Andy Shevchenko]

On Tue, Nov 24, 2020 at 6:54 PM Simon Glass <sjg@chromium.org> wrote:
> On Tue, 24 Nov 2020 at 06:57, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Mon, Nov 23, 2020 at 9:08 PM Simon Glass <sjg@chromium.org> wrote:
> > > On Mon, 23 Nov 2020 at 07:04, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

...

> > > Make sure that start.S puts the top of memory in a sensible place. If
> > > something has set up RAM already then you probably want it to be the
> > > top of RAM, below 2GB.
> >
> > Now I'm struggling to get *delay() working. In run_main_loop() if I
> > call mdelay(<whatever>) the code gets stuck (presumably by not getting
> > timer initialized and returning -EAGAIN).
> > Any ideas?
>
> Do you mean in get_ticks() in lib/time.c ?
>
> Some panic() calls were recently added in there to check that the
> timer is ready.
>
> Did you get the console working?

Nope. The PCI (framebuffer) driver is not getting probed.

Nevertheless the above problem is gone when I cleaned up configuration.

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Tue, 24 Nov 2020 at 12:46, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Tue, Nov 24, 2020 at 6:54 PM Simon Glass <sjg@chromium.org> wrote:
> > On Tue, 24 Nov 2020 at 06:57, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > On Mon, Nov 23, 2020 at 9:08 PM Simon Glass <sjg@chromium.org> wrote:
> > > > On Mon, 23 Nov 2020 at 07:04, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> ...
>
> > > > Make sure that start.S puts the top of memory in a sensible place. If
> > > > something has set up RAM already then you probably want it to be the
> > > > top of RAM, below 2GB.
> > >
> > > Now I'm struggling to get *delay() working. In run_main_loop() if I
> > > call mdelay(<whatever>) the code gets stuck (presumably by not getting
> > > timer initialized and returning -EAGAIN).
> > > Any ideas?
> >
> > Do you mean in get_ticks() in lib/time.c ?
> >
> > Some panic() calls were recently added in there to check that the
> > timer is ready.
> >
> > Did you get the console working?
>
> Nope. The PCI (framebuffer) driver is not getting probed.
>
> Nevertheless the above problem is gone when I cleaned up configuration.

I'm amazed how far you can get without a UART. There must be a way to
make it ouput...

Regards,
Simon

early stage debugging on a real product

[Andy Shevchenko]

On Wed, Nov 25, 2020 at 1:41 AM Simon Glass <sjg@chromium.org> wrote:
> On Tue, 24 Nov 2020 at 12:46, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> > Nope. The PCI (framebuffer) driver is not getting probed.
> >
> > Nevertheless the above problem is gone when I cleaned up configuration.
>
> I'm amazed how far you can get without a UART. There must be a way to
> make it ouput...

I could call this Hawking-style of debugging (when you have one bit of output).

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Andy Shevchenko]

On Wed, Nov 25, 2020 at 1:41 AM Simon Glass <sjg@chromium.org> wrote:
> On Tue, 24 Nov 2020 at 12:46, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Tue, Nov 24, 2020 at 6:54 PM Simon Glass <sjg@chromium.org> wrote:
> > > On Tue, 24 Nov 2020 at 06:57, Andy Shevchenko <andy.shevchenko@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?

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Wed, Nov 25, 2020 at 1:41 AM Simon Glass <sjg@chromium.org> wrote:
> > On Tue, 24 Nov 2020 at 12:46, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > On Tue, Nov 24, 2020 at 6:54 PM Simon Glass <sjg@chromium.org> wrote:
> > > > On Tue, 24 Nov 2020 at 06:57, Andy Shevchenko <andy.shevchenko@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

early stage debugging on a real product

[Andy Shevchenko]

On Wed, Nov 25, 2020 at 4:50 PM Simon Glass <sjg@chromium.org> wrote:
> On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Wed, Nov 25, 2020 at 1:41 AM Simon Glass <sjg@chromium.org> wrote:
> > > On Tue, 24 Nov 2020 at 12:46, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > > On Tue, Nov 24, 2020 at 6:54 PM Simon Glass <sjg@chromium.org> wrote:
> > > > > On Tue, 24 Nov 2020 at 06:57, Andy Shevchenko <andy.shevchenko@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

early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Wed, 25 Nov 2020 at 08:07, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Wed, Nov 25, 2020 at 4:50 PM Simon Glass <sjg@chromium.org> wrote:
> > On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > On Wed, Nov 25, 2020 at 1:41 AM Simon Glass <sjg@chromium.org> wrote:
> > > > On Tue, 24 Nov 2020 at 12:46, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > > > On Tue, Nov 24, 2020 at 6:54 PM Simon Glass <sjg@chromium.org> wrote:
> > > > > > On Tue, 24 Nov 2020 at 06:57, Andy Shevchenko <andy.shevchenko@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

early stage debugging on a real product

[Andy Shevchenko]

On Wed, Nov 25, 2020 at 5:23 PM Simon Glass <sjg@chromium.org> wrote:
> On Wed, 25 Nov 2020 at 08:07, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Wed, Nov 25, 2020 at 4:50 PM Simon Glass <sjg@chromium.org> wrote:
> > > On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko <andy.shevchenko@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).

...

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

...

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

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Wed, 25 Nov 2020 at 08:35, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Wed, Nov 25, 2020 at 5:23 PM Simon Glass <sjg@chromium.org> wrote:
> > On Wed, 25 Nov 2020 at 08:07, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > On Wed, Nov 25, 2020 at 4:50 PM Simon Glass <sjg@chromium.org> wrote:
> > > > On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko <andy.shevchenko@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

early stage debugging on a real product

[Ovidiu Panait]

Hi Andy,

On 25.11.2020 17:36, Andy Shevchenko wrote:
> [Please note this e-mail is from an EXTERNAL e-mail address]
>
> On Wed, Nov 25, 2020 at 5:23 PM Simon Glass <sjg@chromium.org> wrote:
>> On Wed, 25 Nov 2020 at 08:07, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>> On Wed, Nov 25, 2020 at 4:50 PM Simon Glass <sjg@chromium.org> wrote:
>>>> On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko <andy.shevchenko@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).
>
> ...
>
>>>> 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.
>
> ...
>
Could you try to enable CONFIG_PCI_INIT_R=y ? This should call 
pci_init() during boot, after relocation.


Ovidiu

>>>> 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.
>
> --
> With Best Regards,
> Andy Shevchenko

early stage debugging on a real product

[Andy Shevchenko]

On Wed, Nov 25, 2020 at 5:55 PM Ovidiu Panait
<ovidiu.panait@windriver.com> wrote:
> On 25.11.2020 17:36, Andy Shevchenko wrote:
> On Wed, Nov 25, 2020 at 5:23 PM Simon Glass <sjg@chromium.org> wrote:
> On Wed, 25 Nov 2020 at 08:07, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Wed, Nov 25, 2020 at 4:50 PM Simon Glass <sjg@chromium.org> wrote:
> On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

...

> Thanks. But the question is still open why DM PCI et al. is not
> getting initialized.

> Could you try to enable CONFIG_PCI_INIT_R=y ? This should call pci_init() during boot, after relocation.

Thanks. I saw that possibility, but right now...

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

...I have tried this and it makes the device to reboot (probably due
to panic / missed initialization).

I am going to read video.h to understand what parts must be present to
make vidconsole working.

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Andy Shevchenko]

On Wed, Nov 25, 2020 at 5:45 PM Simon Glass <sjg@chromium.org> wrote:
> On Wed, 25 Nov 2020 at 08:35, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Wed, Nov 25, 2020 at 5:23 PM Simon Glass <sjg@chromium.org> wrote:

...

> > 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;
>         };

I have so far

        pci {
               compatible = "pci-x86";
               #address-cells = <3>;
               #size-cells = <2>;
               u-boot,dm-pre-reloc;
               ranges = <0x02000000 0x0 0x80000000 0x80000000 0 0x40000000
                         0x42000000 0x0 0xc0000000 0xc0000000 0 0x20000000
                         0x01000000 0x0 0x2000 0x2000 0 0xe000>;
       };

pci_init() makes the system hang.

WRT video I will try later when I see PCI initialized successfully.

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Wed, 25 Nov 2020 at 09:58, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Wed, Nov 25, 2020 at 5:45 PM Simon Glass <sjg@chromium.org> wrote:
> > On Wed, 25 Nov 2020 at 08:35, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > On Wed, Nov 25, 2020 at 5:23 PM Simon Glass <sjg@chromium.org> wrote:
>
> ...
>
> > > 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;
> >         };
>
> I have so far
>
>         pci {
>                compatible = "pci-x86";
>                #address-cells = <3>;
>                #size-cells = <2>;
>                u-boot,dm-pre-reloc;
>                ranges = <0x02000000 0x0 0x80000000 0x80000000 0 0x40000000
>                          0x42000000 0x0 0xc0000000 0xc0000000 0 0x20000000
>                          0x01000000 0x0 0x2000 0x2000 0 0xe000>;
>        };
>
> pci_init() makes the system hang.
>
> WRT video I will try later when I see PCI initialized successfully.

Probably PCI autoconfig is already done. See CONFIG_PCI_PNP. BTW there
is also ll_boot_init() which disables various init that might already
be done.

Regards,
Simon

early stage debugging on a real product

[Siarhei Siamashka]

On Wed, Nov 25, 2020 at 5:36 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Wed, Nov 25, 2020 at 5:23 PM Simon Glass <sjg@chromium.org> wrote:
> > On Wed, 25 Nov 2020 at 08:07, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > > On Wed, Nov 25, 2020 at 4:50 PM Simon Glass <sjg@chromium.org> wrote:
> > > > On Wed, 25 Nov 2020 at 06:26, Andy Shevchenko <andy.shevchenko@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).

Does this tablet / phone have an MMC slot? For example, on all
Allwinner tablets it is technically possible to use MMC pins for UART
via a different non-standard pin mux setup and a breakout board:

  https://linux-sunxi.org/MicroSD_Breakout
  https://linux-sunxi.org/File:MSI_Primo81_and_MicroSD_breakout.jpg

Also are you sure that there are really no UART pads on the PCB to
solder some wires if you disassemble your tablet / phone?

early stage debugging on a real product

[Andy Shevchenko]

On Wed, Nov 25, 2020 at 7:11 PM Siarhei Siamashka
<siarhei.siamashka@gmail.com> wrote:
> On Wed, Nov 25, 2020 at 5:36 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:

...

> Does this tablet / phone have an MMC slot?

In fact it does.

> For example, on all
> Allwinner tablets it is technically possible to use MMC pins for UART
> via a different non-standard pin mux setup and a breakout board:
>
>   https://linux-sunxi.org/MicroSD_Breakout
>   https://linux-sunxi.org/File:MSI_Primo81_and_MicroSD_breakout.jpg
>
> Also are you sure that there are really no UART pads on the PCB to
> solder some wires if you disassemble your tablet / phone?

There are UARTs which are soldered with real devices connected. MMC
can be switched to GPIO, so it would be rather bitbanging with some
non-standard speed.
Does U-Boot have a bitbang UART driver?

-- 
With Best Regards,
Andy Shevchenko

early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Wed, 25 Nov 2020 at 10:33, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
> On Wed, Nov 25, 2020 at 7:11 PM Siarhei Siamashka
> <siarhei.siamashka@gmail.com> wrote:
> > On Wed, Nov 25, 2020 at 5:36 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
>
> ...
>
> > Does this tablet / phone have an MMC slot?
>
> In fact it does.
>
> > For example, on all
> > Allwinner tablets it is technically possible to use MMC pins for UART
> > via a different non-standard pin mux setup and a breakout board:
> >
> >   https://linux-sunxi.org/MicroSD_Breakout
> >   https://linux-sunxi.org/File:MSI_Primo81_and_MicroSD_breakout.jpg
> >
> > Also are you sure that there are really no UART pads on the PCB to
> > solder some wires if you disassemble your tablet / phone?
>
> There are UARTs which are soldered with real devices connected. MMC
> can be switched to GPIO, so it would be rather bitbanging with some
> non-standard speed.
> Does U-Boot have a bitbang UART driver?

I don't think so.

Regards,
Simon

early stage debugging on a real product

[Andy Shevchenko]

On Wed, Nov 25, 2020 at 7:03 PM Simon Glass <sjg@chromium.org> wrote:
> On Wed, 25 Nov 2020 at 09:58, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Wed, Nov 25, 2020 at 5:45 PM Simon Glass <sjg@chromium.org> wrote:

...

> > pci_init() makes the system hang.
> >
> > WRT video I will try later when I see PCI initialized successfully.
>
> Probably PCI autoconfig is already done. See CONFIG_PCI_PNP. BTW there
> is also ll_boot_init() which disables various init that might already
> be done.

Disabling PCI_PNP helped, thanks.

-- 
With Best Regards,
Andy Shevchenko