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

[Eugen.Hristev at microchip.com <Eugen.Hristev@microchip.com>]

On 4/5/21 3:47 PM, Manuel Lu?s Reis wrote:
> 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.


Does the node have the property

u-boot,dm-pre-reloc;

Maybe try to add this and see if it changes anything ?

> 
> Any ideas?
> 
> Thanks
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, 5 Apr 2021 at 13:44, <Eugen.Hristev@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@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@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,
>>>
>>>
>>