early stage debugging on a real product

[Simon Glass]

Hi Andy,

On Tue, 24 Nov 2020 at 06:57, Andy Shevchenko <andy.shevchenko at gmail.com> wrote:
>
> On Mon, Nov 23, 2020 at 9:08 PM Simon Glass <sjg at chromium.org> wrote:
> > On Mon, 23 Nov 2020 at 07:04, Andy Shevchenko <andy.shevchenko at 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