From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Tue, 24 Nov 2020 15:58:09 +0200
Subject: early stage debugging on a real product
In-Reply-To: <CAPnjgZ0ZyMOadUXWJg8Js2TsM8RBZyui_OXcXK4LgnsFoe1yMQ@mail.gmail.com>
References: <CAHp75VdPTU-THtHi3eRiD7rd_tC90fC66AiUvzMnoF2Ky0J_HQ@mail.gmail.com>
 <CAPnjgZ0ZyMOadUXWJg8Js2TsM8RBZyui_OXcXK4LgnsFoe1yMQ@mail.gmail.com>
Message-ID: <CAHp75VeCkXxNG4sriUfv7Kwk81PUP6yC5uMZ1rNFNydCzxxafw@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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