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