SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94

[Manuel Luís Reis]

Hi Eugen,

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

Indeed I have. After my previous emails trying to find if there was
anything messing with the timer, I went the other way and dug further
into mem_init and ddr2_init. In ddr2_init there is a call to udelay,
udelay(200) in arch/arm/mach-at91/mpddrc.c line 70.

I have commented this out in v2020.07 with no visible consequences. In
v2021.01, SPL did move a bit further, BUT when dealing with the sd
card, within the mmc driver, the errors continued. There are quite a
few udelay() calls within the mmc drivers, so I felt I shouldn't be
changing that.

Instead, I went to check the udelay -> get_ticks -> dm_timer_init
function. And it seems the problem is exactly here. The function tries
to find a timer in the device tree, if I understand correctly, but it
doesn't find one, returning the -ENODEV  error, on the following
function: ret = uclass_first_device_err(UCLASS_TIMER, &dev);

I checked the device tree and the pit timer is there. The UCLASS
driver looks good to me as per documentation. I have also tried adding
the "chosen" "tick-timer" parameter in the device tree pointing to the
pit timer so it would be recognized in the PLATDATA section of this
function, but still it wasn't recognized. (I might not have done this
correctly though it was compiled successfully)

So there seems to be an issue of some kind of misconfiguration with
the declaration of the timer in the device tree that it doesn't get
read back.

Any ideas?

Thanks








On Mon, 5 Apr 2021 at 13:44, <Eugen.Hristev at microchip.com> wrote:
>
> 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 <mluis.reis at gmail.com>
> > wrote:
> >> FYI:
> >>
> >> the output from serial port:
> >> <debug_uart>
> >> 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 <mluis.reis at gmail.com>
> >> 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 <timer_init>:
> >>>    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,
> >
> >
>