From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugen.Hristev at microchip.com Date: Mon, 5 Apr 2021 12:44:41 +0000 Subject: SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94 In-Reply-To: <8AS1RQ.LLEADDUOJVBP2@gmail.com> References: <32474781-93e4-0d71-b5c0-b0b3743ea085@microchip.com> <61fa8518-41ca-cff6-c88b-a0ba5df42edd@microchip.com> <8AS1RQ.LLEADDUOJVBP2@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 4/4/21 7:25 PM, Manuel Reis wrote: > Hi again, > > I guess I misunderstood things a bit. Apologies for that. > Nevertheless, timer_init in board_init_f is pointing to the weak > timer_init in /lib/time.c, which is empty. > > Is there a way we can force start the pit timer? > Any pointer would be very helpful. Let me know if you'd like me to do > something in particular. > > Thanks > > > > On sex, 2 abr, 2021 at 18:15, Manuel Lu?s Reis > wrote: >> FYI: >> >> the output from serial port: >> >> board_init_f spl_atmel.c 130 mem_init 182 ddr2_init mpddr.c 66udelay >> lib time.c 196__udelay lib time.c 177Could not initialize timer (err >> -11) >> >> udelay lib time.c 196__udelay lib time.c 177Could not initialize >> timer (err -11) >> >> udelay lib time.c 196__udelay lib time.c 177Could not initialize >> timer (err -11) >> ... >> >> >> >> >> On Fri, 2 Apr 2021 at 18:12, Manuel Lu?s Reis >> wrote: >>> >>> ?> As it seems from the dump of dm_dump_all() the atmel_pit_timer is >>> not >>> ?> probed. I did a bit of debug and the dm_timer_init() -> >>> ?> uclass_first_device() -> uclass_find_first_device() found zero >>> timers >>> ?> registered for UCLASS_TIMER. The driver is compiled.? Also >>> checked that >>> ?> atmel_pit_timer probe function is not called at all. The question >>> should be >>> ?> why it is not probed at all? >>> >>> ?Hi, >>> >>> ?So, I put objdump and puts to some good use and could backtrace the >>> ?initial error to a udelay call in ddr2_init function on mpddr.c >>> file. >>> ?This function is called from mem_init on >>> ?sama5d3_xplained/sama5d3_xplained.c, which in turn is called from >>> ?board_init_f on spl_atmel.c. Hi Manuel, As Sean Anderson pointed out : the call to timer must have not worked at all before this change that now breaks things. Have you tried removing the call to the timer from this mem_init, to see if this makes the board boot correctly ? In mem_init I guess there are multiple calls to this timer function. >>> ?I couldn't, however, find which timer_init function is being called >>> ?here. I still have a few to try, but disassembly gives me a pretty >>> ?empty function: >>> >>> ?00303690 : >>> ?? 303690:?????? e3a00000??????? mov???? r0, #0 >>> ?? 303694:?????? e12fff1e??????? bx????? lr >>> >>> ?This work didn't give me many answers, but I got a couple of newbie >>> questions: >>> >>> ?Why is it calling board_init_f from spl_atmel.c and not spl_at91.c? >>> ?Isn't the latter the appropriate architecture for this board? >>> ?Do you know which timer_init function it is getting here?? Could >>> this >>> ?be the reason timer isn't getting probed? >>> >>> ?Cheers, > >