On 4/5/21 6:42 PM, Manuel Luís Reis wrote:
> Hi Eugen,
>
> > Does the node have the property
> >
> > u-boot,dm-pre-reloc;
> >
> > Maybe try to add this and see if it changes anything ?
>
> Thanks. Indeed it didn't have those properties. I have added them and
> also had to remove the udelay
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 corre
> Okay, I am glad that you somehow found a solution.
> I am not sure why the ddr2_init call to udelay fails. Maybe we should
> initialize something (timer) before calling ddr2_init ?
> Or timers are initialized just after ddr2 , in which case we need to
> revert the order ?
I don't really understa
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
Hi Eugen,
> Does the node have the property
>
> u-boot,dm-pre-reloc;
>
> Maybe try to add this and see if it changes anything ?
Thanks. Indeed it didn't have those properties. I have added them and also
had to remove the udelay call in ddr2_init for the fix to work.
The udelay call in ddr2_init w
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 ca
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
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 tim
> 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
On 23.03.2021 18:54, Manuel Luís Reis wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hi again,
>
>> There are timers on the board. How come it used to work, before the
>> commit that breaks it ?
>>
>> I understand that nobody registers a
On 3/23/21 12:54 PM, Manuel Luís Reis wrote:
Hi again,
There are timers on the board. How come it used to work, before the
commit that breaks it ?
I understand that nobody registers a driver in the UCLASS_TIMER , but
why was this enforced? and if this enforcement breaks our board, we can
eithe
On 3/23/21 6:08 PM, Manuel Luís Reis wrote:
> Hi again,
>
> FYI: As a small test I commented out the change you mentioned but got
> the same mistake. Begs to wonder if it is
> related to the issue at hand.
>
> Going back to
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being
Hi again,
> There are timers on the board. How come it used to work, before the
> commit that breaks it ?
>
> I understand that nobody registers a driver in the UCLASS_TIMER , but
> why was this enforced? and if this enforcement breaks our board, we can
> either:
> 1/ stop the enforcement
> 2/ com
Hi again,
FYI: As a small test I commented out the change you mentioned but got the
same mistake. Begs to wonder if it is
related to the issue at hand.
Going back to
http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
Sean Anderson asks:
"So nothing
On 3/23/21 1:28 PM, Manuel Luís Reis wrote:
> Hi,
>
> Thanks for your reply.
>
> > Can you please check if this commit is in your tree, or, if the same has
> > to be applied in your case (sama5d3), to make it work ?
>
> I've got that change in my tree, but I'm still getting the error message.
Hi,
Can you please check if this commit is in your tree, or, if the same has
to be applied in your case (sama5d3), to make it work ?
Here is the commit :
https://source.denx.de/u-boot/custodians/u-boot-atmel/-/commit/786f35b619ddbfb88e4532d11a56413f5dab473f
On 3/23/21 1:06 PM, Manuel Luís R
> The change may be dedicated to sama5d2 devices. Could you have a look
> please if your device (sama5d3) needs this change as well ? I mean, does
> doing something similar for sama5d3 fixes your problem ?
I am not quite sure how to check what you suggest to be honest.
The commit you've sent see
Hi,
Thanks for your reply.
> Can you please check if this commit is in your tree, or, if the same has
> to be applied in your case (sama5d3), to make it work ?
I've got that change in my tree, but I'm still getting the error message.
I am using up-to-date mainline U-Boot.
Thanks
On Tue, 23
Hello,
I've been having issues with SPL booting in the SAMA5D3 Xplained board
getting the following error, with up-to-date mainline U-boot and
sama5d3_xplained _mmc_defconfig:
---
RomBOOT
Could not initialize timer (err -19)
.
19 matches
Mail list logo
