* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
@ 2021-03-23 11:06 Manuel Luís Reis
2021-03-23 11:14 ` Eugen.Hristev at microchip.com
0 siblings, 1 reply; 19+ messages in thread
From: Manuel Luís Reis @ 2021-03-23 11:06 UTC (permalink / raw)
To: u-boot
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
<debug_uart>
Could not initialize timer (err -19)
.....
-----------------------------------------------
I could trace back the error to commit 4b2be78.
This topic has been raised before on
http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
Tried the suggestions there with the same result.
I'm am not too knowledgeable with U-Boot nor this board. Could you shed
some light on this? Any pointers would be appreciated.
Let me know if you require additional information.
Cheers,
Manuel
Output from dm_dump_all():
Class Index Probed Driver Name
-----------------------------------------------------------
root 0 [ + ] root_driver root_driver
simple_bus 0 [ ] simple_bus `-- ahb
simple_bus 1 [ ] simple_bus `-- apb
mmc 0 [ ] atmel-mci |-- mmc at f0000000
blk 0 [ ] mmc_blk | `-- mmc at f0000000.blk
mmc 1 [ ] atmel-mci |-- mmc at f8000000
blk 1 [ ] mmc_blk | `-- mmc at f8000000.blk
serial 0 [ ] serial_atmel |-- serial at ffffee00
pinctrl 0 [ ] atmel_sama5d3_pinctrl |-- pinctrl at fffff200
pinconfig 0 [ ] pinconfig | |-- dbgu
pinconfig 1 [ ] pinconfig | | `-- dbgu-0
pinconfig 2 [ ] pinconfig | |-- mmc0
pinconfig 3 [ ] pinconfig | | |-- mmc0_clk_cmd_dat0
pinconfig 4 [ ] pinconfig | | |-- mmc0_dat1_3
pinconfig 5 [ ] pinconfig | | `-- mmc0_dat4_7
pinconfig 6 [ ] pinconfig | |-- mmc1
pinconfig 7 [ ] pinconfig | | |-- mmc1_clk_cmd_dat0
pinconfig 8 [ ] pinconfig | | `-- mmc1_dat1_3
pinconfig 9 [ ] pinconfig | |-- spi0
pinconfig 10 [ ] pinconfig | | `-- spi0-0
pinconfig 11 [ ] pinconfig | |-- spi1
pinconfig 12 [ ] pinconfig | | `-- spi1-0
pinconfig 13 [ ] pinconfig | `-- board
pinconfig 14 [ ] pinconfig | |-- mmc0_cd
pinconfig 15 [ ] pinconfig | `-- mmc1_cd
gpio 0 [ ] atmel_at91rm9200_gpio |-- gpio at fffff200
gpio 1 [ ] atmel_at91rm9200_gpio |-- gpio at fffff400
gpio 2 [ ] atmel_at91rm9200_gpio |-- gpio at fffff600
gpio 3 [ ] atmel_at91rm9200_gpio |-- gpio at fffff800
gpio 4 [ ] atmel_at91rm9200_gpio |-- gpio at fffffa00
simple_bus 2 [ ] at91-pmc `-- pmc at fffffc00
clk 0 [ ] at91sam9x5-utmi-clk |-- utmick
clk 1 [ ] at91-master-clk |-- masterck
misc 0 [ ] sam9x5-periph-clk `-- periphck
clk 2 [ ] periph-clk |-- dbgu_clk at 2
clk 3 [ ] periph-clk |-- pioA_clk at 6
clk 4 [ ] periph-clk |-- pioB_clk at 7
clk 5 [ ] periph-clk |-- pioC_clk at 8
clk 6 [ ] periph-clk |-- pioD_clk at 9
clk 7 [ ] periph-clk |-- pioE_clk at 10
clk 8 [ ] periph-clk |-- mci0_clk at 21
clk 9 [ ] periph-clk |-- mci1_clk at 22
clk 10 [ ] periph-clk |-- spi0_clk at 24
clk 11 [ ] periph-clk `-- spi1_clk at 25
Could not initialize timer (err -19)
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-03-23 11:06 SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94 Manuel Luís Reis
@ 2021-03-23 11:14 ` Eugen.Hristev at microchip.com
2021-03-23 11:28 ` Manuel Luís Reis
0 siblings, 1 reply; 19+ messages in thread
From: Eugen.Hristev at microchip.com @ 2021-03-23 11:14 UTC (permalink / raw)
To: u-boot
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 Reis wrote:
> 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
>
> <debug_uart>
> Could not initialize timer (err -19)
> .....
> -----------------------------------------------
>
> I could trace back the error to commit?4b2be78.
>
> This topic has been raised before on
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
> Tried the suggestions there with the same result.
>
> I'm am not too knowledgeable with U-Boot nor this board. Could you shed
> some light on this? Any pointers would be appreciated.
>
> Let me know if you require additional information.
>
> Cheers,
> Manuel
>
> Output from dm_dump_all():
>
> ?Class ? ? Index ?Probed ?Driver ? ? ? ? ? ? ? ?Name
> -----------------------------------------------------------
> ?root ?0 ?[ + ] ? root_driver ?root_driver
> ?simple_bus ?0 ?[ ? ] ? simple_bus ?`-- ahb
> ?simple_bus ?1 ?[ ? ] ? simple_bus ? ? ?`-- apb
> ?mmc ?0 ?[ ? ] ? atmel-mci ? ? ? ? ?|-- mmc at f0000000
> ?blk ?0 ?[ ? ] ? mmc_blk ? ? ? ? ?| ? `-- mmc at f0000000.blk
> ?mmc ?1 ?[ ? ] ? atmel-mci ? ? ? ? ?|-- mmc at f8000000
> ?blk ?1 ?[ ? ] ? mmc_blk ? ? ? ? ?| ? `-- mmc at f8000000.blk
> ?serial ?0 ?[ ? ] ? serial_atmel ? ? ? ? ?|-- serial at ffffee00
> ?pinctrl ?0 ?[ ? ] ? atmel_sama5d3_pinctrl ? ? ? ? ?|-- pinctrl at fffff200
> ?pinconfig ?0 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- dbgu
> ?pinconfig ?1 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `-- dbgu-0
> ?pinconfig ?2 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- mmc0
> ?pinconfig ?3 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? |-- mmc0_clk_cmd_dat0
> ?pinconfig ?4 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? |-- mmc0_dat1_3
> ?pinconfig ?5 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `-- mmc0_dat4_7
> ?pinconfig ?6 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- mmc1
> ?pinconfig ?7 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? |-- mmc1_clk_cmd_dat0
> ?pinconfig ?8 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `-- mmc1_dat1_3
> ?pinconfig ?9 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- spi0
> ?pinconfig ?10 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `-- spi0-0
> ?pinconfig ?11 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- spi1
> ?pinconfig ?12 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `-- spi1-0
> ?pinconfig ?13 ?[ ? ] ? pinconfig ? ? ? ? ?| ? `-- board
> ?pinconfig ?14 ?[ ? ] ? pinconfig ? ? ? ? ?| ? ? ? |-- mmc0_cd
> ?pinconfig ?15 ?[ ? ] ? pinconfig ? ? ? ? ?| ? ? ? `-- mmc1_cd
> ?gpio ?0 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|-- gpio at fffff200
> ?gpio ?1 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|-- gpio at fffff400
> ?gpio ?2 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|-- gpio at fffff600
> ?gpio ?3 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|-- gpio at fffff800
> ?gpio ?4 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|-- gpio at fffffa00
> ?simple_bus ?2 ?[ ? ] ? at91-pmc ? ? ? ? ?`-- pmc at fffffc00
> ?clk ?0 ?[ ? ] ? at91sam9x5-utmi-clk ? ? ? ? ? ? ?|-- utmick
> ?clk ?1 ?[ ? ] ? at91-master-clk ? ? ? ? ? ? ?|-- masterck
> ?misc ?0 ?[ ? ] ? sam9x5-periph-clk ? ? ? ? ? ? ?`-- periphck
> ?clk ?2 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- dbgu_clk at 2
> ?clk ?3 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- pioA_clk at 6
> ?clk ?4 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- pioB_clk at 7
> ?clk ?5 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- pioC_clk at 8
> ?clk ?6 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- pioD_clk at 9
> ?clk ?7 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- pioE_clk at 10
> ?clk ?8 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- mci0_clk at 21
> ?clk ?9 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- mci1_clk at 22
> ?clk ?10 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- spi0_clk at 24
> ?clk ?11 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?`-- spi1_clk at 25
> Could not initialize timer (err -19)
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-03-23 11:14 ` Eugen.Hristev at microchip.com
@ 2021-03-23 11:28 ` Manuel Luís Reis
2021-03-23 11:38 ` Eugen.Hristev at microchip.com
0 siblings, 1 reply; 19+ messages in thread
From: Manuel Luís Reis @ 2021-03-23 11:28 UTC (permalink / raw)
To: u-boot
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 Mar 2021 at 11:14, <Eugen.Hristev@microchip.com> wrote:
> 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 Reis wrote:
> > 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
> >
> > <debug_uart>
> > Could not initialize timer (err -19)
> > .....
> > -----------------------------------------------
> >
> > I could trace back the error to commit 4b2be78.
> >
> > This topic has been raised before on
> >
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
> > Tried the suggestions there with the same result.
> >
> > I'm am not too knowledgeable with U-Boot nor this board. Could you shed
> > some light on this? Any pointers would be appreciated.
> >
> > Let me know if you require additional information.
> >
> > Cheers,
> > Manuel
> >
> > Output from dm_dump_all():
> >
> > Class Index Probed Driver Name
> > -----------------------------------------------------------
> > root 0 [ + ] root_driver root_driver
> > simple_bus 0 [ ] simple_bus `-- ahb
> > simple_bus 1 [ ] simple_bus `-- apb
> > mmc 0 [ ] atmel-mci |-- mmc at f0000000
> > blk 0 [ ] mmc_blk | `-- mmc at f0000000.blk
> > mmc 1 [ ] atmel-mci |-- mmc at f8000000
> > blk 1 [ ] mmc_blk | `-- mmc at f8000000.blk
> > serial 0 [ ] serial_atmel |-- serial at ffffee00
> > pinctrl 0 [ ] atmel_sama5d3_pinctrl |-- pinctrl at fffff200
> > pinconfig 0 [ ] pinconfig | |-- dbgu
> > pinconfig 1 [ ] pinconfig | | `-- dbgu-0
> > pinconfig 2 [ ] pinconfig | |-- mmc0
> > pinconfig 3 [ ] pinconfig | | |-- mmc0_clk_cmd_dat0
> > pinconfig 4 [ ] pinconfig | | |-- mmc0_dat1_3
> > pinconfig 5 [ ] pinconfig | | `-- mmc0_dat4_7
> > pinconfig 6 [ ] pinconfig | |-- mmc1
> > pinconfig 7 [ ] pinconfig | | |-- mmc1_clk_cmd_dat0
> > pinconfig 8 [ ] pinconfig | | `-- mmc1_dat1_3
> > pinconfig 9 [ ] pinconfig | |-- spi0
> > pinconfig 10 [ ] pinconfig | | `-- spi0-0
> > pinconfig 11 [ ] pinconfig | |-- spi1
> > pinconfig 12 [ ] pinconfig | | `-- spi1-0
> > pinconfig 13 [ ] pinconfig | `-- board
> > pinconfig 14 [ ] pinconfig | |-- mmc0_cd
> > pinconfig 15 [ ] pinconfig | `-- mmc1_cd
> > gpio 0 [ ] atmel_at91rm9200_gpio |-- gpio at fffff200
> > gpio 1 [ ] atmel_at91rm9200_gpio |-- gpio at fffff400
> > gpio 2 [ ] atmel_at91rm9200_gpio |-- gpio at fffff600
> > gpio 3 [ ] atmel_at91rm9200_gpio |-- gpio at fffff800
> > gpio 4 [ ] atmel_at91rm9200_gpio |-- gpio at fffffa00
> > simple_bus 2 [ ] at91-pmc `-- pmc at fffffc00
> > clk 0 [ ] at91sam9x5-utmi-clk |-- utmick
> > clk 1 [ ] at91-master-clk |-- masterck
> > misc 0 [ ] sam9x5-periph-clk `-- periphck
> > clk 2 [ ] periph-clk |-- dbgu_clk at 2
> > clk 3 [ ] periph-clk |-- pioA_clk at 6
> > clk 4 [ ] periph-clk |-- pioB_clk at 7
> > clk 5 [ ] periph-clk |-- pioC_clk at 8
> > clk 6 [ ] periph-clk |-- pioD_clk at 9
> > clk 7 [ ] periph-clk |-- pioE_clk at 10
> > clk 8 [ ] periph-clk |-- mci0_clk at 21
> > clk 9 [ ] periph-clk |-- mci1_clk at 22
> > clk 10 [ ] periph-clk |-- spi0_clk at 24
> > clk 11 [ ] periph-clk `-- spi1_clk at 25
> > Could not initialize timer (err -19)
> >
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-03-23 11:28 ` Manuel Luís Reis
@ 2021-03-23 11:38 ` Eugen.Hristev at microchip.com
2021-03-23 13:20 ` Manuel Luís Reis
0 siblings, 1 reply; 19+ messages in thread
From: Eugen.Hristev at microchip.com @ 2021-03-23 11:38 UTC (permalink / raw)
To: u-boot
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.
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 ?
Thanks,
Eugen
>
> I am using up-to-date mainline U-Boot.
>
> Thanks
>
>
>
> On Tue, 23 Mar 2021 at 11:14, <Eugen.Hristev@microchip.com
> <mailto:Eugen.Hristev@microchip.com>> wrote:
>
> 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 Reis wrote:
> > 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
> >
> > <debug_uart>
> > Could not initialize timer (err -19)
> > .....
> > -----------------------------------------------
> >
> > I could trace back the error to commit?4b2be78.
> >
> > This topic has been raised before on
> >
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
> > Tried the suggestions there with the same result.
> >
> > I'm am not too knowledgeable with U-Boot nor this board. Could
> you shed
> > some light on this? Any pointers would be appreciated.
> >
> > Let me know if you require additional information.
> >
> > Cheers,
> > Manuel
> >
> > Output from dm_dump_all():
> >
> >? ?Class ? ? Index ?Probed ?Driver ? ? ? ? ? ? ? ?Name
> > -----------------------------------------------------------
> >? ?root ?0 ?[ + ] ? root_driver ?root_driver
> >? ?simple_bus ?0 ?[ ? ] ? simple_bus ?`-- ahb
> >? ?simple_bus ?1 ?[ ? ] ? simple_bus ? ? ?`-- apb
> >? ?mmc ?0 ?[ ? ] ? atmel-mci ? ? ? ? ?|-- mmc at f0000000
> >? ?blk ?0 ?[ ? ] ? mmc_blk ? ? ? ? ?| ? `-- mmc at f0000000.blk
> >? ?mmc ?1 ?[ ? ] ? atmel-mci ? ? ? ? ?|-- mmc at f8000000
> >? ?blk ?1 ?[ ? ] ? mmc_blk ? ? ? ? ?| ? `-- mmc at f8000000.blk
> >? ?serial ?0 ?[ ? ] ? serial_atmel ? ? ? ? ?|-- serial at ffffee00
> >? ?pinctrl ?0 ?[ ? ] ? atmel_sama5d3_pinctrl ? ? ? ? ?|--
> pinctrl at fffff200
> >? ?pinconfig ?0 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- dbgu
> >? ?pinconfig ?1 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `-- dbgu-0
> >? ?pinconfig ?2 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- mmc0
> >? ?pinconfig ?3 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? |--
> mmc0_clk_cmd_dat0
> >? ?pinconfig ?4 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? |-- mmc0_dat1_3
> >? ?pinconfig ?5 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `-- mmc0_dat4_7
> >? ?pinconfig ?6 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- mmc1
> >? ?pinconfig ?7 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? |--
> mmc1_clk_cmd_dat0
> >? ?pinconfig ?8 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `-- mmc1_dat1_3
> >? ?pinconfig ?9 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- spi0
> >? ?pinconfig ?10 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `-- spi0-0
> >? ?pinconfig ?11 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- spi1
> >? ?pinconfig ?12 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `-- spi1-0
> >? ?pinconfig ?13 ?[ ? ] ? pinconfig ? ? ? ? ?| ? `-- board
> >? ?pinconfig ?14 ?[ ? ] ? pinconfig ? ? ? ? ?| ? ? ? |-- mmc0_cd
> >? ?pinconfig ?15 ?[ ? ] ? pinconfig ? ? ? ? ?| ? ? ? `-- mmc1_cd
> >? ?gpio ?0 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|-- gpio at fffff200
> >? ?gpio ?1 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|-- gpio at fffff400
> >? ?gpio ?2 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|-- gpio at fffff600
> >? ?gpio ?3 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|-- gpio at fffff800
> >? ?gpio ?4 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|-- gpio at fffffa00
> >? ?simple_bus ?2 ?[ ? ] ? at91-pmc ? ? ? ? ?`-- pmc at fffffc00
> >? ?clk ?0 ?[ ? ] ? at91sam9x5-utmi-clk ? ? ? ? ? ? ?|-- utmick
> >? ?clk ?1 ?[ ? ] ? at91-master-clk ? ? ? ? ? ? ?|-- masterck
> >? ?misc ?0 ?[ ? ] ? sam9x5-periph-clk ? ? ? ? ? ? ?`-- periphck
> >? ?clk ?2 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- dbgu_clk at 2
> >? ?clk ?3 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- pioA_clk at 6
> >? ?clk ?4 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- pioB_clk at 7
> >? ?clk ?5 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- pioC_clk at 8
> >? ?clk ?6 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- pioD_clk at 9
> >? ?clk ?7 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- pioE_clk at 10
> >? ?clk ?8 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- mci0_clk at 21
> >? ?clk ?9 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- mci1_clk at 22
> >? ?clk ?10 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|-- spi0_clk at 24
> >? ?clk ?11 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?`-- spi1_clk at 25
> > Could not initialize timer (err -19)
> >
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-03-23 11:38 ` Eugen.Hristev at microchip.com
@ 2021-03-23 13:20 ` Manuel Luís Reis
2021-03-23 16:08 ` Manuel Luís Reis
0 siblings, 1 reply; 19+ messages in thread
From: Manuel Luís Reis @ 2021-03-23 13:20 UTC (permalink / raw)
To: u-boot
> 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 seems to be board independent ->
mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards, sama5d3
inclusive?
I don't see where else I could make a change like that.
Thanks for your patience.
On Tue, 23 Mar 2021 at 11:38, <Eugen.Hristev@microchip.com> wrote:
> 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.
>
> 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 ?
>
> Thanks,
> Eugen
>
> >
> > I am using up-to-date mainline U-Boot.
> >
> > Thanks
> >
> >
> >
> > On Tue, 23 Mar 2021 at 11:14, <Eugen.Hristev@microchip.com
> > <mailto:Eugen.Hristev@microchip.com>> wrote:
> >
> > 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 Reis wrote:
> > > 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
> > >
> > > <debug_uart>
> > > Could not initialize timer (err -19)
> > > .....
> > > -----------------------------------------------
> > >
> > > I could trace back the error to commit 4b2be78.
> > >
> > > This topic has been raised before on
> > >
> >
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
> > > Tried the suggestions there with the same result.
> > >
> > > I'm am not too knowledgeable with U-Boot nor this board. Could
> > you shed
> > > some light on this? Any pointers would be appreciated.
> > >
> > > Let me know if you require additional information.
> > >
> > > Cheers,
> > > Manuel
> > >
> > > Output from dm_dump_all():
> > >
> > > Class Index Probed Driver Name
> > > -----------------------------------------------------------
> > > root 0 [ + ] root_driver root_driver
> > > simple_bus 0 [ ] simple_bus `-- ahb
> > > simple_bus 1 [ ] simple_bus `-- apb
> > > mmc 0 [ ] atmel-mci |-- mmc at f0000000
> > > blk 0 [ ] mmc_blk | `-- mmc at f0000000.blk
> > > mmc 1 [ ] atmel-mci |-- mmc at f8000000
> > > blk 1 [ ] mmc_blk | `-- mmc at f8000000.blk
> > > serial 0 [ ] serial_atmel |-- serial at ffffee00
> > > pinctrl 0 [ ] atmel_sama5d3_pinctrl |--
> > pinctrl at fffff200
> > > pinconfig 0 [ ] pinconfig | |-- dbgu
> > > pinconfig 1 [ ] pinconfig | | `-- dbgu-0
> > > pinconfig 2 [ ] pinconfig | |-- mmc0
> > > pinconfig 3 [ ] pinconfig | | |--
> > mmc0_clk_cmd_dat0
> > > pinconfig 4 [ ] pinconfig | | |-- mmc0_dat1_3
> > > pinconfig 5 [ ] pinconfig | | `-- mmc0_dat4_7
> > > pinconfig 6 [ ] pinconfig | |-- mmc1
> > > pinconfig 7 [ ] pinconfig | | |--
> > mmc1_clk_cmd_dat0
> > > pinconfig 8 [ ] pinconfig | | `-- mmc1_dat1_3
> > > pinconfig 9 [ ] pinconfig | |-- spi0
> > > pinconfig 10 [ ] pinconfig | | `-- spi0-0
> > > pinconfig 11 [ ] pinconfig | |-- spi1
> > > pinconfig 12 [ ] pinconfig | | `-- spi1-0
> > > pinconfig 13 [ ] pinconfig | `-- board
> > > pinconfig 14 [ ] pinconfig | |-- mmc0_cd
> > > pinconfig 15 [ ] pinconfig | `-- mmc1_cd
> > > gpio 0 [ ] atmel_at91rm9200_gpio |--
> gpio at fffff200
> > > gpio 1 [ ] atmel_at91rm9200_gpio |--
> gpio at fffff400
> > > gpio 2 [ ] atmel_at91rm9200_gpio |--
> gpio at fffff600
> > > gpio 3 [ ] atmel_at91rm9200_gpio |--
> gpio at fffff800
> > > gpio 4 [ ] atmel_at91rm9200_gpio |--
> gpio at fffffa00
> > > simple_bus 2 [ ] at91-pmc `-- pmc at fffffc00
> > > clk 0 [ ] at91sam9x5-utmi-clk |-- utmick
> > > clk 1 [ ] at91-master-clk |-- masterck
> > > misc 0 [ ] sam9x5-periph-clk `-- periphck
> > > clk 2 [ ] periph-clk |-- dbgu_clk at 2
> > > clk 3 [ ] periph-clk |-- pioA_clk at 6
> > > clk 4 [ ] periph-clk |-- pioB_clk at 7
> > > clk 5 [ ] periph-clk |-- pioC_clk at 8
> > > clk 6 [ ] periph-clk |-- pioD_clk at 9
> > > clk 7 [ ] periph-clk |-- pioE_clk at 10
> > > clk 8 [ ] periph-clk |-- mci0_clk at 21
> > > clk 9 [ ] periph-clk |-- mci1_clk at 22
> > > clk 10 [ ] periph-clk |-- spi0_clk at 24
> > > clk 11 [ ] periph-clk `-- spi1_clk at 25
> > > Could not initialize timer (err -19)
> > >
> >
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-03-23 13:20 ` Manuel Luís Reis
@ 2021-03-23 16:08 ` Manuel Luís Reis
2021-03-23 16:26 ` Eugen.Hristev at microchip.com
0 siblings, 1 reply; 19+ messages in thread
From: Manuel Luís Reis @ 2021-03-23 16:08 UTC (permalink / raw)
To: u-boot
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 here is probed, but additionally nothing has UCLASS_TIMER.
What do you expect the timer device to be?"
Is the timer missing for SAMA5D3 board? I cannot find it in /drivers/timer,
other than mchp-pit64b-timer.c, which doesn't
seem to be used ins this particular board as far as I could tell.
Any thoughts on how to fix this? Anything I can do to help?
Cheers
On Tue, 23 Mar 2021 at 13:20, Manuel Lu?s Reis <mluis.reis@gmail.com> wrote:
>
> > 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 seems to be board independent ->
> mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards, sama5d3
> inclusive?
> I don't see where else I could make a change like that.
>
> Thanks for your patience.
>
>
>
> On Tue, 23 Mar 2021 at 11:38, <Eugen.Hristev@microchip.com> wrote:
>
>> 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.
>>
>> 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 ?
>>
>> Thanks,
>> Eugen
>>
>> >
>> > I am using up-to-date mainline U-Boot.
>> >
>> > Thanks
>> >
>> >
>> >
>> > On Tue, 23 Mar 2021 at 11:14, <Eugen.Hristev@microchip.com
>> > <mailto:Eugen.Hristev@microchip.com>> wrote:
>> >
>> > 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 Reis wrote:
>> > > 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
>> > >
>> > > <debug_uart>
>> > > Could not initialize timer (err -19)
>> > > .....
>> > > -----------------------------------------------
>> > >
>> > > I could trace back the error to commit 4b2be78.
>> > >
>> > > This topic has been raised before on
>> > >
>> >
>> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
>> > > Tried the suggestions there with the same result.
>> > >
>> > > I'm am not too knowledgeable with U-Boot nor this board. Could
>> > you shed
>> > > some light on this? Any pointers would be appreciated.
>> > >
>> > > Let me know if you require additional information.
>> > >
>> > > Cheers,
>> > > Manuel
>> > >
>> > > Output from dm_dump_all():
>> > >
>> > > Class Index Probed Driver Name
>> > > -----------------------------------------------------------
>> > > root 0 [ + ] root_driver root_driver
>> > > simple_bus 0 [ ] simple_bus `-- ahb
>> > > simple_bus 1 [ ] simple_bus `-- apb
>> > > mmc 0 [ ] atmel-mci |-- mmc at f0000000
>> > > blk 0 [ ] mmc_blk | `-- mmc at f0000000.blk
>> > > mmc 1 [ ] atmel-mci |-- mmc at f8000000
>> > > blk 1 [ ] mmc_blk | `-- mmc at f8000000.blk
>> > > serial 0 [ ] serial_atmel |-- serial at ffffee00
>> > > pinctrl 0 [ ] atmel_sama5d3_pinctrl |--
>> > pinctrl at fffff200
>> > > pinconfig 0 [ ] pinconfig | |-- dbgu
>> > > pinconfig 1 [ ] pinconfig | | `-- dbgu-0
>> > > pinconfig 2 [ ] pinconfig | |-- mmc0
>> > > pinconfig 3 [ ] pinconfig | | |--
>> > mmc0_clk_cmd_dat0
>> > > pinconfig 4 [ ] pinconfig | | |--
>> mmc0_dat1_3
>> > > pinconfig 5 [ ] pinconfig | | `--
>> mmc0_dat4_7
>> > > pinconfig 6 [ ] pinconfig | |-- mmc1
>> > > pinconfig 7 [ ] pinconfig | | |--
>> > mmc1_clk_cmd_dat0
>> > > pinconfig 8 [ ] pinconfig | | `--
>> mmc1_dat1_3
>> > > pinconfig 9 [ ] pinconfig | |-- spi0
>> > > pinconfig 10 [ ] pinconfig | | `-- spi0-0
>> > > pinconfig 11 [ ] pinconfig | |-- spi1
>> > > pinconfig 12 [ ] pinconfig | | `-- spi1-0
>> > > pinconfig 13 [ ] pinconfig | `-- board
>> > > pinconfig 14 [ ] pinconfig | |-- mmc0_cd
>> > > pinconfig 15 [ ] pinconfig | `-- mmc1_cd
>> > > gpio 0 [ ] atmel_at91rm9200_gpio |--
>> gpio at fffff200
>> > > gpio 1 [ ] atmel_at91rm9200_gpio |--
>> gpio at fffff400
>> > > gpio 2 [ ] atmel_at91rm9200_gpio |--
>> gpio at fffff600
>> > > gpio 3 [ ] atmel_at91rm9200_gpio |--
>> gpio at fffff800
>> > > gpio 4 [ ] atmel_at91rm9200_gpio |--
>> gpio at fffffa00
>> > > simple_bus 2 [ ] at91-pmc `-- pmc at fffffc00
>> > > clk 0 [ ] at91sam9x5-utmi-clk |-- utmick
>> > > clk 1 [ ] at91-master-clk |-- masterck
>> > > misc 0 [ ] sam9x5-periph-clk `-- periphck
>> > > clk 2 [ ] periph-clk |-- dbgu_clk at 2
>> > > clk 3 [ ] periph-clk |-- pioA_clk at 6
>> > > clk 4 [ ] periph-clk |-- pioB_clk at 7
>> > > clk 5 [ ] periph-clk |-- pioC_clk at 8
>> > > clk 6 [ ] periph-clk |-- pioD_clk at 9
>> > > clk 7 [ ] periph-clk |-- pioE_clk at 10
>> > > clk 8 [ ] periph-clk |-- mci0_clk at 21
>> > > clk 9 [ ] periph-clk |-- mci1_clk at 22
>> > > clk 10 [ ] periph-clk |-- spi0_clk at 24
>> > > clk 11 [ ] periph-clk `-- spi1_clk at 25
>> > > Could not initialize timer (err -19)
>> > >
>> >
>>
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-03-23 16:08 ` Manuel Luís Reis
@ 2021-03-23 16:26 ` Eugen.Hristev at microchip.com
2021-03-23 16:54 ` Manuel Luís Reis
0 siblings, 1 reply; 19+ messages in thread
From: Eugen.Hristev at microchip.com @ 2021-03-23 16:26 UTC (permalink / raw)
To: u-boot
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-non-monotonic-td426172.html
>
> Sean Anderson asks:
>
> "So nothing here is probed, but additionally nothing has UCLASS_TIMER.
> What do you expect the timer device to be?"
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/ comply
Either way, I think we have to see how we can get one timer to register
itself as an UCLASS_TIMER
>
> Is the timer missing for SAMA5D3 board? I cannot find it in
> /drivers/timer, other than mchp-pit64b-timer.c, which doesn't
> seem to be used ins this particular board as far as I could tell.
This timer is a new hardware timer which is not present in the sama5d3 SoC.
Sama5d3 should have old PIT timers, (programmable interrupt timer)
and most likely that code has not been converted to DM (UCLASSes)
One possible approach is to convert specific old PIT code to comply with
DM requirements (or if that code is already available, we have to
use/enable it ).
I add Claudiu in the mail thread, as he is more familiar with PIT and
timers than I am, and maybe he has some opinion related to this issue.
Eugen
>
> Any thoughts on how to fix this? Anything I can do to help?
>
> Cheers
>
>
> On Tue, 23 Mar 2021 at 13:20, Manuel Lu?s Reis <mluis.reis@gmail.com
> <mailto:mluis.reis@gmail.com>> wrote:
>
>
> > 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 seems to be board independent ->
> mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards,
> sama5d3 inclusive?
> I don't see where else I could make a change like that.
>
> Thanks for your patience.
>
>
>
> On Tue, 23 Mar 2021 at 11:38, <Eugen.Hristev@microchip.com
> <mailto:Eugen.Hristev@microchip.com>> wrote:
>
> 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.
>
> 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 ?
>
> Thanks,
> Eugen
>
> >
> > I am using up-to-date mainline U-Boot.
> >
> > Thanks
> >
> >
> >
> > On Tue, 23 Mar 2021 at 11:14, <Eugen.Hristev@microchip.com
> <mailto:Eugen.Hristev@microchip.com>
> > <mailto:Eugen.Hristev@microchip.com
> <mailto:Eugen.Hristev@microchip.com>>> wrote:
> >
> >? ? ?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 Reis wrote:
> >? ? ? > 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
> >? ? ? >
> >? ? ? > <debug_uart>
> >? ? ? > Could not initialize timer (err -19)
> >? ? ? > .....
> >? ? ? > -----------------------------------------------
> >? ? ? >
> >? ? ? > I could trace back the error to commit?4b2be78.
> >? ? ? >
> >? ? ? > This topic has been raised before on
> >? ? ? >
> >
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
> >? ? ? > Tried the suggestions there with the same result.
> >? ? ? >
> >? ? ? > I'm am not too knowledgeable with U-Boot nor this
> board. Could
> >? ? ?you shed
> >? ? ? > some light on this? Any pointers would be appreciated.
> >? ? ? >
> >? ? ? > Let me know if you require additional information.
> >? ? ? >
> >? ? ? > Cheers,
> >? ? ? > Manuel
> >? ? ? >
> >? ? ? > Output from dm_dump_all():
> >? ? ? >
> >? ? ? >? ?Class ? ? Index ?Probed ?Driver ? ? ? ? ? ? ? ?Name
> >? ? ? >
> -----------------------------------------------------------
> >? ? ? >? ?root ?0 ?[ + ] ? root_driver ?root_driver
> >? ? ? >? ?simple_bus ?0 ?[ ? ] ? simple_bus ?`-- ahb
> >? ? ? >? ?simple_bus ?1 ?[ ? ] ? simple_bus ? ? ?`-- apb
> >? ? ? >? ?mmc ?0 ?[ ? ] ? atmel-mci ? ? ? ? ?|-- mmc at f0000000
> >? ? ? >? ?blk ?0 ?[ ? ] ? mmc_blk ? ? ? ? ?| ? `--
> mmc at f0000000.blk
> >? ? ? >? ?mmc ?1 ?[ ? ] ? atmel-mci ? ? ? ? ?|-- mmc at f8000000
> >? ? ? >? ?blk ?1 ?[ ? ] ? mmc_blk ? ? ? ? ?| ? `--
> mmc at f8000000.blk
> >? ? ? >? ?serial ?0 ?[ ? ] ? serial_atmel ? ? ? ? ?|--
> serial at ffffee00
> >? ? ? >? ?pinctrl ?0 ?[ ? ] ? atmel_sama5d3_pinctrl ? ? ? ? ?|--
> >? ? ?pinctrl at fffff200
> >? ? ? >? ?pinconfig ?0 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- dbgu
> >? ? ? >? ?pinconfig ?1 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `--
> dbgu-0
> >? ? ? >? ?pinconfig ?2 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- mmc0
> >? ? ? >? ?pinconfig ?3 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? |--
> >? ? ?mmc0_clk_cmd_dat0
> >? ? ? >? ?pinconfig ?4 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? |--
> mmc0_dat1_3
> >? ? ? >? ?pinconfig ?5 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `--
> mmc0_dat4_7
> >? ? ? >? ?pinconfig ?6 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- mmc1
> >? ? ? >? ?pinconfig ?7 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? |--
> >? ? ?mmc1_clk_cmd_dat0
> >? ? ? >? ?pinconfig ?8 ?[ ? ] ? pinconfig ? ? ? ? ?| ? | ? `--
> mmc1_dat1_3
> >? ? ? >? ?pinconfig ?9 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- spi0
> >? ? ? >? ?pinconfig ?10 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |
> `-- spi0-0
> >? ? ? >? ?pinconfig ?11 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |-- spi1
> >? ? ? >? ?pinconfig ?12 ?[ ? ] ? pinconfig ? ? ? ? ?| ? |
> `-- spi1-0
> >? ? ? >? ?pinconfig ?13 ?[ ? ] ? pinconfig ? ? ? ? ?| ? `-- board
> >? ? ? >? ?pinconfig ?14 ?[ ? ] ? pinconfig ? ? ? ? ?|
> |-- mmc0_cd
> >? ? ? >? ?pinconfig ?15 ?[ ? ] ? pinconfig ? ? ? ? ?|
> `-- mmc1_cd
> >? ? ? >? ?gpio ?0 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|--
> gpio at fffff200
> >? ? ? >? ?gpio ?1 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|--
> gpio at fffff400
> >? ? ? >? ?gpio ?2 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|--
> gpio at fffff600
> >? ? ? >? ?gpio ?3 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|--
> gpio at fffff800
> >? ? ? >? ?gpio ?4 ?[ ? ] ? atmel_at91rm9200_gpio ? ? ? ? ?|--
> gpio at fffffa00
> >? ? ? >? ?simple_bus ?2 ?[ ? ] ? at91-pmc ? ? ? ? ?`--
> pmc at fffffc00
> >? ? ? >? ?clk ?0 ?[ ? ] ? at91sam9x5-utmi-clk ? ? ? ? ? ? ?|--
> utmick
> >? ? ? >? ?clk ?1 ?[ ? ] ? at91-master-clk ? ? ? ? ? ? ?|--
> masterck
> >? ? ? >? ?misc ?0 ?[ ? ] ? sam9x5-periph-clk ? ? ? ? ? ? ?`--
> periphck
> >? ? ? >? ?clk ?2 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|--
> dbgu_clk at 2
> >? ? ? >? ?clk ?3 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|--
> pioA_clk at 6
> >? ? ? >? ?clk ?4 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|--
> pioB_clk at 7
> >? ? ? >? ?clk ?5 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|--
> pioC_clk at 8
> >? ? ? >? ?clk ?6 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|--
> pioD_clk at 9
> >? ? ? >? ?clk ?7 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|--
> pioE_clk at 10
> >? ? ? >? ?clk ?8 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|--
> mci0_clk at 21
> >? ? ? >? ?clk ?9 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|--
> mci1_clk at 22
> >? ? ? >? ?clk ?10 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?|--
> spi0_clk at 24
> >? ? ? >? ?clk ?11 ?[ ? ] ? periph-clk ? ? ? ? ? ? ? ? ?`--
> spi1_clk at 25
> >? ? ? > Could not initialize timer (err -19)
> >? ? ? >
> >
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-03-23 16:26 ` Eugen.Hristev at microchip.com
@ 2021-03-23 16:54 ` Manuel Luís Reis
2021-03-24 0:34 ` Sean Anderson
2021-03-25 10:25 ` Claudiu.Beznea at microchip.com
0 siblings, 2 replies; 19+ messages in thread
From: Manuel Luís Reis @ 2021-03-23 16:54 UTC (permalink / raw)
To: u-boot
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/ comply
>
> Either way, I think we have to see how we can get one timer to register
> itself as an UCLASS_TIMER
I understand.
> This timer is a new hardware timer which is not present in the sama5d3 SoC.
>
> Sama5d3 should have old PIT timers, (programmable interrupt timer)
> and most likely that code has not been converted to DM (UCLASSes)
>
> One possible approach is to convert specific old PIT code to comply with
> DM requirements (or if that code is already available, we have to
> use/enable it ).
>
> I add Claudiu in the mail thread, as he is more familiar with PIT and
> timers than I am, and maybe he has some opinion related to this issue.
Thanks for clarifying this for me.
Look forward to hearing from Claudiu.
Cheers,
On Tue, 23 Mar 2021 at 16:26, <Eugen.Hristev@microchip.com> wrote:
>
> 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-non-monotonic-td426172.html
> >
> > Sean Anderson asks:
> >
> > "So nothing here is probed, but additionally nothing has UCLASS_TIMER.
> > What do you expect the timer device to be?"
>
> 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/ comply
>
> Either way, I think we have to see how we can get one timer to register
> itself as an UCLASS_TIMER
>
>
> >
> > Is the timer missing for SAMA5D3 board? I cannot find it in
> > /drivers/timer, other than mchp-pit64b-timer.c, which doesn't
> > seem to be used ins this particular board as far as I could tell.
>
> This timer is a new hardware timer which is not present in the sama5d3 SoC.
>
> Sama5d3 should have old PIT timers, (programmable interrupt timer)
> and most likely that code has not been converted to DM (UCLASSes)
>
> One possible approach is to convert specific old PIT code to comply with
> DM requirements (or if that code is already available, we have to
> use/enable it ).
>
> I add Claudiu in the mail thread, as he is more familiar with PIT and
> timers than I am, and maybe he has some opinion related to this issue.
>
> Eugen
>
> >
> > Any thoughts on how to fix this? Anything I can do to help?
> >
> > Cheers
> >
> >
> > On Tue, 23 Mar 2021 at 13:20, Manuel Lu?s Reis <mluis.reis@gmail.com
> > <mailto:mluis.reis@gmail.com>> wrote:
> >
> >
> > > 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 seems to be board independent ->
> > mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards,
> > sama5d3 inclusive?
> > I don't see where else I could make a change like that.
> >
> > Thanks for your patience.
> >
> >
> >
> > On Tue, 23 Mar 2021 at 11:38, <Eugen.Hristev@microchip.com
> > <mailto:Eugen.Hristev@microchip.com>> wrote:
> >
> > 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.
> >
> > 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 ?
> >
> > Thanks,
> > Eugen
> >
> > >
> > > I am using up-to-date mainline U-Boot.
> > >
> > > Thanks
> > >
> > >
> > >
> > > On Tue, 23 Mar 2021 at 11:14, <Eugen.Hristev@microchip.com
> > <mailto:Eugen.Hristev@microchip.com>
> > > <mailto:Eugen.Hristev@microchip.com
> > <mailto:Eugen.Hristev@microchip.com>>> wrote:
> > >
> > > 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 Reis wrote:
> > > > 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
> > > >
> > > > <debug_uart>
> > > > Could not initialize timer (err -19)
> > > > .....
> > > > -----------------------------------------------
> > > >
> > > > I could trace back the error to commit 4b2be78.
> > > >
> > > > This topic has been raised before on
> > > >
> > >
> > http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
> > > > Tried the suggestions there with the same result.
> > > >
> > > > I'm am not too knowledgeable with U-Boot nor this
> > board. Could
> > > you shed
> > > > some light on this? Any pointers would be appreciated.
> > > >
> > > > Let me know if you require additional information.
> > > >
> > > > Cheers,
> > > > Manuel
> > > >
> > > > Output from dm_dump_all():
> > > >
> > > > Class Index Probed Driver Name
> > > >
> > -----------------------------------------------------------
> > > > root 0 [ + ] root_driver root_driver
> > > > simple_bus 0 [ ] simple_bus `-- ahb
> > > > simple_bus 1 [ ] simple_bus `-- apb
> > > > mmc 0 [ ] atmel-mci |-- mmc at f0000000
> > > > blk 0 [ ] mmc_blk | `--
> > mmc at f0000000.blk
> > > > mmc 1 [ ] atmel-mci |-- mmc at f8000000
> > > > blk 1 [ ] mmc_blk | `--
> > mmc at f8000000.blk
> > > > serial 0 [ ] serial_atmel |--
> > serial at ffffee00
> > > > pinctrl 0 [ ] atmel_sama5d3_pinctrl |--
> > > pinctrl at fffff200
> > > > pinconfig 0 [ ] pinconfig | |-- dbgu
> > > > pinconfig 1 [ ] pinconfig | | `--
> > dbgu-0
> > > > pinconfig 2 [ ] pinconfig | |-- mmc0
> > > > pinconfig 3 [ ] pinconfig | | |--
> > > mmc0_clk_cmd_dat0
> > > > pinconfig 4 [ ] pinconfig | | |--
> > mmc0_dat1_3
> > > > pinconfig 5 [ ] pinconfig | | `--
> > mmc0_dat4_7
> > > > pinconfig 6 [ ] pinconfig | |-- mmc1
> > > > pinconfig 7 [ ] pinconfig | | |--
> > > mmc1_clk_cmd_dat0
> > > > pinconfig 8 [ ] pinconfig | | `--
> > mmc1_dat1_3
> > > > pinconfig 9 [ ] pinconfig | |-- spi0
> > > > pinconfig 10 [ ] pinconfig | |
> > `-- spi0-0
> > > > pinconfig 11 [ ] pinconfig | |-- spi1
> > > > pinconfig 12 [ ] pinconfig | |
> > `-- spi1-0
> > > > pinconfig 13 [ ] pinconfig | `-- board
> > > > pinconfig 14 [ ] pinconfig |
> > |-- mmc0_cd
> > > > pinconfig 15 [ ] pinconfig |
> > `-- mmc1_cd
> > > > gpio 0 [ ] atmel_at91rm9200_gpio |--
> > gpio at fffff200
> > > > gpio 1 [ ] atmel_at91rm9200_gpio |--
> > gpio at fffff400
> > > > gpio 2 [ ] atmel_at91rm9200_gpio |--
> > gpio at fffff600
> > > > gpio 3 [ ] atmel_at91rm9200_gpio |--
> > gpio at fffff800
> > > > gpio 4 [ ] atmel_at91rm9200_gpio |--
> > gpio at fffffa00
> > > > simple_bus 2 [ ] at91-pmc `--
> > pmc at fffffc00
> > > > clk 0 [ ] at91sam9x5-utmi-clk |--
> > utmick
> > > > clk 1 [ ] at91-master-clk |--
> > masterck
> > > > misc 0 [ ] sam9x5-periph-clk `--
> > periphck
> > > > clk 2 [ ] periph-clk |--
> > dbgu_clk at 2
> > > > clk 3 [ ] periph-clk |--
> > pioA_clk at 6
> > > > clk 4 [ ] periph-clk |--
> > pioB_clk at 7
> > > > clk 5 [ ] periph-clk |--
> > pioC_clk at 8
> > > > clk 6 [ ] periph-clk |--
> > pioD_clk at 9
> > > > clk 7 [ ] periph-clk |--
> > pioE_clk at 10
> > > > clk 8 [ ] periph-clk |--
> > mci0_clk at 21
> > > > clk 9 [ ] periph-clk |--
> > mci1_clk at 22
> > > > clk 10 [ ] periph-clk |--
> > spi0_clk at 24
> > > > clk 11 [ ] periph-clk `--
> > spi1_clk at 25
> > > > Could not initialize timer (err -19)
> > > >
> > >
> >
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-03-23 16:54 ` Manuel Luís Reis
@ 2021-03-24 0:34 ` Sean Anderson
2021-03-25 10:25 ` Claudiu.Beznea at microchip.com
1 sibling, 0 replies; 19+ messages in thread
From: Sean Anderson @ 2021-03-24 0:34 UTC (permalink / raw)
To: u-boot
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
>> either:
>> 1/ stop the enforcement
>> 2/ comply
>>
>> Either way, I think we have to see how we can get one timer to register
>> itself as an UCLASS_TIMER
You can also track down the early call to get_ticks. Whatever is doing
it probably doesn't need to, considering that before this patch it was
getting back garbage.
--Sean
>
> I understand.
>
>> This timer is a new hardware timer which is not present in the sama5d3 SoC.
>>
>> Sama5d3 should have old PIT timers, (programmable interrupt timer)
>> and most likely that code has not been converted to DM (UCLASSes)
>>
>> One possible approach is to convert specific old PIT code to comply with
>> DM requirements (or if that code is already available, we have to
>> use/enable it ).
>>
>> I add Claudiu in the mail thread, as he is more familiar with PIT and
>> timers than I am, and maybe he has some opinion related to this issue.
>
> Thanks for clarifying this for me.
>
> Look forward to hearing from Claudiu.
>
> Cheers,
>
>
>
>
> On Tue, 23 Mar 2021 at 16:26, <Eugen.Hristev@microchip.com> wrote:
>>
>> 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-non-monotonic-td426172.html
>>>
>>> Sean Anderson asks:
>>>
>>> "So nothing here is probed, but additionally nothing has UCLASS_TIMER.
>>> What do you expect the timer device to be?"
>>
>> 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/ comply
>>
>> Either way, I think we have to see how we can get one timer to register
>> itself as an UCLASS_TIMER
>>
>>
>>>
>>> Is the timer missing for SAMA5D3 board? I cannot find it in
>>> /drivers/timer, other than mchp-pit64b-timer.c, which doesn't
>>> seem to be used ins this particular board as far as I could tell.
>>
>> This timer is a new hardware timer which is not present in the sama5d3 SoC.
>>
>> Sama5d3 should have old PIT timers, (programmable interrupt timer)
>> and most likely that code has not been converted to DM (UCLASSes)
>>
>> One possible approach is to convert specific old PIT code to comply with
>> DM requirements (or if that code is already available, we have to
>> use/enable it ).
>>
>> I add Claudiu in the mail thread, as he is more familiar with PIT and
>> timers than I am, and maybe he has some opinion related to this issue.
>>
>> Eugen
>>
>>>
>>> Any thoughts on how to fix this? Anything I can do to help?
>>>
>>> Cheers
>>>
>>>
>>> On Tue, 23 Mar 2021 at 13:20, Manuel Lu?s Reis <mluis.reis@gmail.com
>>> <mailto:mluis.reis@gmail.com>> wrote:
>>>
>>>
>>> > 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 seems to be board independent ->
>>> mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards,
>>> sama5d3 inclusive?
>>> I don't see where else I could make a change like that.
>>>
>>> Thanks for your patience.
>>>
>>>
>>>
>>> On Tue, 23 Mar 2021 at 11:38, <Eugen.Hristev@microchip.com
>>> <mailto:Eugen.Hristev@microchip.com>> wrote:
>>>
>>> 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.
>>>
>>> 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 ?
>>>
>>> Thanks,
>>> Eugen
>>>
>>> >
>>> > I am using up-to-date mainline U-Boot.
>>> >
>>> > Thanks
>>> >
>>> >
>>> >
>>> > On Tue, 23 Mar 2021 at 11:14, <Eugen.Hristev@microchip.com
>>> <mailto:Eugen.Hristev@microchip.com>
>>> > <mailto:Eugen.Hristev@microchip.com
>>> <mailto:Eugen.Hristev@microchip.com>>> wrote:
>>> >
>>> > 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 Reis wrote:
>>> > > 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
>>> > >
>>> > > <debug_uart>
>>> > > Could not initialize timer (err -19)
>>> > > .....
>>> > > -----------------------------------------------
>>> > >
>>> > > I could trace back the error to commit 4b2be78.
>>> > >
>>> > > This topic has been raised before on
>>> > >
>>> >
>>> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
>>> > > Tried the suggestions there with the same result.
>>> > >
>>> > > I'm am not too knowledgeable with U-Boot nor this
>>> board. Could
>>> > you shed
>>> > > some light on this? Any pointers would be appreciated.
>>> > >
>>> > > Let me know if you require additional information.
>>> > >
>>> > > Cheers,
>>> > > Manuel
>>> > >
>>> > > Output from dm_dump_all():
>>> > >
>>> > > Class Index Probed Driver Name
>>> > >
>>> -----------------------------------------------------------
>>> > > root 0 [ + ] root_driver root_driver
>>> > > simple_bus 0 [ ] simple_bus `-- ahb
>>> > > simple_bus 1 [ ] simple_bus `-- apb
>>> > > mmc 0 [ ] atmel-mci |-- mmc at f0000000
>>> > > blk 0 [ ] mmc_blk | `--
>>> mmc at f0000000.blk
>>> > > mmc 1 [ ] atmel-mci |-- mmc at f8000000
>>> > > blk 1 [ ] mmc_blk | `--
>>> mmc at f8000000.blk
>>> > > serial 0 [ ] serial_atmel |--
>>> serial at ffffee00
>>> > > pinctrl 0 [ ] atmel_sama5d3_pinctrl |--
>>> > pinctrl at fffff200
>>> > > pinconfig 0 [ ] pinconfig | |-- dbgu
>>> > > pinconfig 1 [ ] pinconfig | | `--
>>> dbgu-0
>>> > > pinconfig 2 [ ] pinconfig | |-- mmc0
>>> > > pinconfig 3 [ ] pinconfig | | |--
>>> > mmc0_clk_cmd_dat0
>>> > > pinconfig 4 [ ] pinconfig | | |--
>>> mmc0_dat1_3
>>> > > pinconfig 5 [ ] pinconfig | | `--
>>> mmc0_dat4_7
>>> > > pinconfig 6 [ ] pinconfig | |-- mmc1
>>> > > pinconfig 7 [ ] pinconfig | | |--
>>> > mmc1_clk_cmd_dat0
>>> > > pinconfig 8 [ ] pinconfig | | `--
>>> mmc1_dat1_3
>>> > > pinconfig 9 [ ] pinconfig | |-- spi0
>>> > > pinconfig 10 [ ] pinconfig | |
>>> `-- spi0-0
>>> > > pinconfig 11 [ ] pinconfig | |-- spi1
>>> > > pinconfig 12 [ ] pinconfig | |
>>> `-- spi1-0
>>> > > pinconfig 13 [ ] pinconfig | `-- board
>>> > > pinconfig 14 [ ] pinconfig |
>>> |-- mmc0_cd
>>> > > pinconfig 15 [ ] pinconfig |
>>> `-- mmc1_cd
>>> > > gpio 0 [ ] atmel_at91rm9200_gpio |--
>>> gpio at fffff200
>>> > > gpio 1 [ ] atmel_at91rm9200_gpio |--
>>> gpio at fffff400
>>> > > gpio 2 [ ] atmel_at91rm9200_gpio |--
>>> gpio at fffff600
>>> > > gpio 3 [ ] atmel_at91rm9200_gpio |--
>>> gpio at fffff800
>>> > > gpio 4 [ ] atmel_at91rm9200_gpio |--
>>> gpio at fffffa00
>>> > > simple_bus 2 [ ] at91-pmc `--
>>> pmc at fffffc00
>>> > > clk 0 [ ] at91sam9x5-utmi-clk |--
>>> utmick
>>> > > clk 1 [ ] at91-master-clk |--
>>> masterck
>>> > > misc 0 [ ] sam9x5-periph-clk `--
>>> periphck
>>> > > clk 2 [ ] periph-clk |--
>>> dbgu_clk at 2
>>> > > clk 3 [ ] periph-clk |--
>>> pioA_clk at 6
>>> > > clk 4 [ ] periph-clk |--
>>> pioB_clk at 7
>>> > > clk 5 [ ] periph-clk |--
>>> pioC_clk at 8
>>> > > clk 6 [ ] periph-clk |--
>>> pioD_clk at 9
>>> > > clk 7 [ ] periph-clk |--
>>> pioE_clk at 10
>>> > > clk 8 [ ] periph-clk |--
>>> mci0_clk at 21
>>> > > clk 9 [ ] periph-clk |--
>>> mci1_clk at 22
>>> > > clk 10 [ ] periph-clk |--
>>> spi0_clk at 24
>>> > > clk 11 [ ] periph-clk `--
>>> spi1_clk at 25
>>> > > Could not initialize timer (err -19)
>>> > >
>>> >
>>>
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-03-23 16:54 ` Manuel Luís Reis
2021-03-24 0:34 ` Sean Anderson
@ 2021-03-25 10:25 ` Claudiu.Beznea at microchip.com
2021-04-02 17:12 ` Manuel Luís Reis
1 sibling, 1 reply; 19+ messages in thread
From: Claudiu.Beznea at microchip.com @ 2021-03-25 10:25 UTC (permalink / raw)
To: u-boot
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 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/ comply
>>
>> Either way, I think we have to see how we can get one timer to register
>> itself as an UCLASS_TIMER
>
> I understand.
>
>> This timer is a new hardware timer which is not present in the sama5d3 SoC.
>>
>> Sama5d3 should have old PIT timers, (programmable interrupt timer)
>> and most likely that code has not been converted to DM (UCLASSes)
>>
>> One possible approach is to convert specific old PIT code to comply with
>> DM requirements (or if that code is already available, we have to
>> use/enable it ).
>>
>> I add Claudiu in the mail thread, as he is more familiar with PIT and
>> timers than I am, and maybe he has some opinion related to this issue.
>
> Thanks for clarifying this for me.
>
> Look forward to hearing from Claudiu.
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?
>
> Cheers,
>
>
>
>
> On Tue, 23 Mar 2021 at 16:26, <Eugen.Hristev@microchip.com> wrote:
>>
>> 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-non-monotonic-td426172.html
>>>
>>> Sean Anderson asks:
>>>
>>> "So nothing here is probed, but additionally nothing has UCLASS_TIMER.
>>> What do you expect the timer device to be?"
>>
>> 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/ comply
>>
>> Either way, I think we have to see how we can get one timer to register
>> itself as an UCLASS_TIMER
>>
>>
>>>
>>> Is the timer missing for SAMA5D3 board? I cannot find it in
>>> /drivers/timer, other than mchp-pit64b-timer.c, which doesn't
>>> seem to be used ins this particular board as far as I could tell.
>>
>> This timer is a new hardware timer which is not present in the sama5d3 SoC.
>>
>> Sama5d3 should have old PIT timers, (programmable interrupt timer)
>> and most likely that code has not been converted to DM (UCLASSes)
>>
>> One possible approach is to convert specific old PIT code to comply with
>> DM requirements (or if that code is already available, we have to
>> use/enable it ).
>>
>> I add Claudiu in the mail thread, as he is more familiar with PIT and
>> timers than I am, and maybe he has some opinion related to this issue.
>>
>> Eugen
>>
>>>
>>> Any thoughts on how to fix this? Anything I can do to help?
>>>
>>> Cheers
>>>
>>>
>>> On Tue, 23 Mar 2021 at 13:20, Manuel Lu?s Reis <mluis.reis@gmail.com
>>> <mailto:mluis.reis@gmail.com>> wrote:
>>>
>>>
>>> > 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 seems to be board independent ->
>>> mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards,
>>> sama5d3 inclusive?
>>> I don't see where else I could make a change like that.
>>>
>>> Thanks for your patience.
>>>
>>>
>>>
>>> On Tue, 23 Mar 2021 at 11:38, <Eugen.Hristev@microchip.com
>>> <mailto:Eugen.Hristev@microchip.com>> wrote:
>>>
>>> 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.
>>>
>>> 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 ?
>>>
>>> Thanks,
>>> Eugen
>>>
>>> >
>>> > I am using up-to-date mainline U-Boot.
>>> >
>>> > Thanks
>>> >
>>> >
>>> >
>>> > On Tue, 23 Mar 2021 at 11:14, <Eugen.Hristev@microchip.com
>>> <mailto:Eugen.Hristev@microchip.com>
>>> > <mailto:Eugen.Hristev@microchip.com
>>> <mailto:Eugen.Hristev@microchip.com>>> wrote:
>>> >
>>> > 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 Reis wrote:
>>> > > 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
>>> > >
>>> > > <debug_uart>
>>> > > Could not initialize timer (err -19)
>>> > > .....
>>> > > -----------------------------------------------
>>> > >
>>> > > I could trace back the error to commit 4b2be78.
>>> > >
>>> > > This topic has been raised before on
>>> > >
>>> >
>>> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
>>> > > Tried the suggestions there with the same result.
>>> > >
>>> > > I'm am not too knowledgeable with U-Boot nor this
>>> board. Could
>>> > you shed
>>> > > some light on this? Any pointers would be appreciated.
>>> > >
>>> > > Let me know if you require additional information.
>>> > >
>>> > > Cheers,
>>> > > Manuel
>>> > >
>>> > > Output from dm_dump_all():
>>> > >
>>> > > Class Index Probed Driver Name
>>> > >
>>> -----------------------------------------------------------
>>> > > root 0 [ + ] root_driver root_driver
>>> > > simple_bus 0 [ ] simple_bus `-- ahb
>>> > > simple_bus 1 [ ] simple_bus `-- apb
>>> > > mmc 0 [ ] atmel-mci |-- mmc at f0000000
>>> > > blk 0 [ ] mmc_blk | `--
>>> mmc at f0000000.blk
>>> > > mmc 1 [ ] atmel-mci |-- mmc at f8000000
>>> > > blk 1 [ ] mmc_blk | `--
>>> mmc at f8000000.blk
>>> > > serial 0 [ ] serial_atmel |--
>>> serial at ffffee00
>>> > > pinctrl 0 [ ] atmel_sama5d3_pinctrl |--
>>> > pinctrl at fffff200
>>> > > pinconfig 0 [ ] pinconfig | |-- dbgu
>>> > > pinconfig 1 [ ] pinconfig | | `--
>>> dbgu-0
>>> > > pinconfig 2 [ ] pinconfig | |-- mmc0
>>> > > pinconfig 3 [ ] pinconfig | | |--
>>> > mmc0_clk_cmd_dat0
>>> > > pinconfig 4 [ ] pinconfig | | |--
>>> mmc0_dat1_3
>>> > > pinconfig 5 [ ] pinconfig | | `--
>>> mmc0_dat4_7
>>> > > pinconfig 6 [ ] pinconfig | |-- mmc1
>>> > > pinconfig 7 [ ] pinconfig | | |--
>>> > mmc1_clk_cmd_dat0
>>> > > pinconfig 8 [ ] pinconfig | | `--
>>> mmc1_dat1_3
>>> > > pinconfig 9 [ ] pinconfig | |-- spi0
>>> > > pinconfig 10 [ ] pinconfig | |
>>> `-- spi0-0
>>> > > pinconfig 11 [ ] pinconfig | |-- spi1
>>> > > pinconfig 12 [ ] pinconfig | |
>>> `-- spi1-0
>>> > > pinconfig 13 [ ] pinconfig | `-- board
>>> > > pinconfig 14 [ ] pinconfig |
>>> |-- mmc0_cd
>>> > > pinconfig 15 [ ] pinconfig |
>>> `-- mmc1_cd
>>> > > gpio 0 [ ] atmel_at91rm9200_gpio |--
>>> gpio at fffff200
>>> > > gpio 1 [ ] atmel_at91rm9200_gpio |--
>>> gpio at fffff400
>>> > > gpio 2 [ ] atmel_at91rm9200_gpio |--
>>> gpio at fffff600
>>> > > gpio 3 [ ] atmel_at91rm9200_gpio |--
>>> gpio at fffff800
>>> > > gpio 4 [ ] atmel_at91rm9200_gpio |--
>>> gpio at fffffa00
>>> > > simple_bus 2 [ ] at91-pmc `--
>>> pmc at fffffc00
>>> > > clk 0 [ ] at91sam9x5-utmi-clk |--
>>> utmick
>>> > > clk 1 [ ] at91-master-clk |--
>>> masterck
>>> > > misc 0 [ ] sam9x5-periph-clk `--
>>> periphck
>>> > > clk 2 [ ] periph-clk |--
>>> dbgu_clk at 2
>>> > > clk 3 [ ] periph-clk |--
>>> pioA_clk at 6
>>> > > clk 4 [ ] periph-clk |--
>>> pioB_clk at 7
>>> > > clk 5 [ ] periph-clk |--
>>> pioC_clk at 8
>>> > > clk 6 [ ] periph-clk |--
>>> pioD_clk at 9
>>> > > clk 7 [ ] periph-clk |--
>>> pioE_clk at 10
>>> > > clk 8 [ ] periph-clk |--
>>> mci0_clk at 21
>>> > > clk 9 [ ] periph-clk |--
>>> mci1_clk at 22
>>> > > clk 10 [ ] periph-clk |--
>>> spi0_clk at 24
>>> > > clk 11 [ ] periph-clk `--
>>> spi1_clk at 25
>>> > > Could not initialize timer (err -19)
>>> > >
>>> >
>>>
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-03-25 10:25 ` Claudiu.Beznea at microchip.com
@ 2021-04-02 17:12 ` Manuel Luís Reis
2021-04-02 17:15 ` Manuel Luís Reis
0 siblings, 1 reply; 19+ messages in thread
From: Manuel Luís Reis @ 2021-04-02 17:12 UTC (permalink / raw)
To: u-boot
> 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.
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,
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-04-02 17:12 ` Manuel Luís Reis
@ 2021-04-02 17:15 ` Manuel Luís Reis
2021-04-04 16:25 ` Manuel Reis
0 siblings, 1 reply; 19+ messages in thread
From: Manuel Luís Reis @ 2021-04-02 17:15 UTC (permalink / raw)
To: u-boot
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.
> 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,
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-04-02 17:15 ` Manuel Luís Reis
@ 2021-04-04 16:25 ` Manuel Reis
2021-04-05 12:44 ` Eugen.Hristev at microchip.com
0 siblings, 1 reply; 19+ messages in thread
From: Manuel Reis @ 2021-04-04 16:25 UTC (permalink / raw)
To: u-boot
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.
>> 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,
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-04-04 16:25 ` Manuel Reis
@ 2021-04-05 12:44 ` Eugen.Hristev at microchip.com
2021-04-05 12:47 ` Manuel Luís Reis
0 siblings, 1 reply; 19+ messages in thread
From: Eugen.Hristev at microchip.com @ 2021-04-05 12:44 UTC (permalink / raw)
To: u-boot
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,
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-04-05 12:44 ` Eugen.Hristev at microchip.com
@ 2021-04-05 12:47 ` Manuel Luís Reis
2021-04-05 13:58 ` Eugen.Hristev at microchip.com
0 siblings, 1 reply; 19+ messages in thread
From: Manuel Luís Reis @ 2021-04-05 12:47 UTC (permalink / raw)
To: u-boot
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@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,
> >
> >
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-04-05 12:47 ` Manuel Luís Reis
@ 2021-04-05 13:58 ` Eugen.Hristev at microchip.com
2021-04-05 15:42 ` Manuel Luís Reis
0 siblings, 1 reply; 19+ messages in thread
From: Eugen.Hristev at microchip.com @ 2021-04-05 13:58 UTC (permalink / raw)
To: u-boot
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,
>>>
>>>
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-04-05 13:58 ` Eugen.Hristev at microchip.com
@ 2021-04-05 15:42 ` Manuel Luís Reis
2021-04-05 16:00 ` Eugen.Hristev at microchip.com
0 siblings, 1 reply; 19+ messages in thread
From: Manuel Luís Reis @ 2021-04-05 15:42 UTC (permalink / raw)
To: u-boot
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 was also failing (maybe too early for a timer
call!?), but it seems to be redundant as it sits between two nops,
and is working well as far as I can tell. If extra time is needed in that
place, maybe extra NOPs could be considered instead.
I am sending a patch for the fix. Could you review it please?
Let me know if you'd like me to change anything.
Thanks again,
--------------------------------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-04-05 15:42 ` Manuel Luís Reis
@ 2021-04-05 16:00 ` Eugen.Hristev at microchip.com
2021-04-05 17:50 ` Manuel Luís Reis
0 siblings, 1 reply; 19+ messages in thread
From: Eugen.Hristev at microchip.com @ 2021-04-05 16:00 UTC (permalink / raw)
To: u-boot
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 call in ddr2_init for the fix to work.
> The udelay call in ddr2_init was also failing (maybe too early for a
> timer call!?), but it seems to be redundant as it sits between two nops,
> and is working well as far as I can tell. If extra time is needed in
> that place, maybe extra NOPs could be considered instead.
>
> I am sending a patch for the fix. Could you review it please?
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 ?
To make a proper review, please use 'git send-email' command to send
your patch , not attach it to the email here.
If you modify the device tree, and some other code, you need to have two
separate patches.
each patch has to adhere to the subject rule : subsystem: component:
change ...
Check other commits in the area you are committing to see how they look like
>
> Let me know if you'd like me to change anything.
>
> Thanks?again,
> --------------------------------------------------------------------------------------------------------
>
>
> From cff45e15a96facc702c852a9beff27907b2c92e5 Mon Sep 17 00:00:00 2001
> From: Manuel Reis <mluis.reis at gmail.com <mailto:mluis.reis@gmail.com>>
> Date: Mon, 5 Apr 2021 16:31:38 +0100
> Subject: [PATCH] add u-boot properties to pit timer
>
> timer node was not detected when udelay was used.
> udelay call removed from ddr2_init as: it sits between two NOP;
>
> Signed-off-by: Manuel Reis <mluis.reis@gmail.com
> <mailto:mluis.reis@gmail.com>>
> ---
> ?arch/arm/dts/sama5d3.dtsi ? | 1 +
> ?arch/arm/mach-at91/mpddrc.c | 3 ---
> ?2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm/dts/sama5d3.dtsi b/arch/arm/dts/sama5d3.dtsi
> index 6ed218eaad..3cd30d574d 100644
> --- a/arch/arm/dts/sama5d3.dtsi
> +++ b/arch/arm/dts/sama5d3.dtsi
> @@ -1316,6 +1316,7 @@
> ? ? ? ? ? ? ? ? ? ? ? ? };
>
> ? ? ? ? ? ? ? ? ? ? ? ? pit: timer at fffffe30 {
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u-boot,dm-pre-reloc;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? compatible = "atmel,at91sam9260-pit";
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? reg = <0xfffffe30 0xf>;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? interrupts = <3 IRQ_TYPE_LEVEL_HIGH 5>;
> diff --git a/arch/arm/mach-at91/mpddrc.c b/arch/arm/mach-at91/mpddrc.c
> index 5422c05456..2e52595e30 100644
> --- a/arch/arm/mach-at91/mpddrc.c
> +++ b/arch/arm/mach-at91/mpddrc.c
> @@ -66,9 +66,6 @@ int ddr2_init(const unsigned int base,
> ? ? ? ? /* Issue a NOP command */
> ? ? ? ? atmel_mpddr_op(mpddr, ATMEL_MPDDRC_MR_MODE_NOP_CMD, ram_address);
>
> - ? ? ? /* A 200 us is provided to precede any signal toggle */
> - ? ? ? udelay(200);
> -
> ? ? ? ? /* Issue a NOP command */
> ? ? ? ? atmel_mpddr_op(mpddr, ATMEL_MPDDRC_MR_MODE_NOP_CMD, ram_address);
>
> --
> 2.27.0
>
>
>
>
>
>
>
> On Mon, 5 Apr 2021 at 14:58, <Eugen.Hristev@microchip.com
> <mailto:Eugen.Hristev@microchip.com>> wrote:
>
> 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
> <mailto: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 at gmail.com <mailto: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 at gmail.com <mailto: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,
> >>>
> >>>
> >>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94
2021-04-05 16:00 ` Eugen.Hristev at microchip.com
@ 2021-04-05 17:50 ` Manuel Luís Reis
0 siblings, 0 replies; 19+ messages in thread
From: Manuel Luís Reis @ 2021-04-05 17:50 UTC (permalink / raw)
To: u-boot
> 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 understand how the timer gets initiated. Doesn't the
UCLASS framework handle it? It does seem to be after board_init_f.
There is an option to make it available early, but it doesn't seem to
be implemented for this board. Maybe Claudiu can give a few pointers?
If I get some free time I'll try to dig further on this topic.
> To make a proper review, please use 'git send-email' command to send
> your patch , not attach it to the email here.
>
> If you modify the device tree, and some other code, you need to have two
> separate patches.
> each patch has to adhere to the subject rule : subsystem: component:
> change ...
>
> Check other commits in the area you are committing to see how they look like
Got it. Thanks.
I have sent the first patch for the device tree, but didn't go quite
as planned. Let me know. if there is a need to correct anything.
Cheers
On Mon, 5 Apr 2021 at 17:00, <Eugen.Hristev@microchip.com> wrote:
>
> 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 call in ddr2_init for the fix to work.
> > The udelay call in ddr2_init was also failing (maybe too early for a
> > timer call!?), but it seems to be redundant as it sits between two nops,
> > and is working well as far as I can tell. If extra time is needed in
> > that place, maybe extra NOPs could be considered instead.
> >
> > I am sending a patch for the fix. Could you review it please?
>
> 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 ?
>
> To make a proper review, please use 'git send-email' command to send
> your patch , not attach it to the email here.
>
> If you modify the device tree, and some other code, you need to have two
> separate patches.
> each patch has to adhere to the subject rule : subsystem: component:
> change ...
>
> Check other commits in the area you are committing to see how they look like
>
> >
> > Let me know if you'd like me to change anything.
> >
> > Thanks again,
> > --------------------------------------------------------------------------------------------------------
> >
> >
> > From cff45e15a96facc702c852a9beff27907b2c92e5 Mon Sep 17 00:00:00 2001
> > From: Manuel Reis <mluis.reis at gmail.com <mailto:mluis.reis@gmail.com>>
> > Date: Mon, 5 Apr 2021 16:31:38 +0100
> > Subject: [PATCH] add u-boot properties to pit timer
> >
> > timer node was not detected when udelay was used.
> > udelay call removed from ddr2_init as: it sits between two NOP;
> >
> > Signed-off-by: Manuel Reis <mluis.reis@gmail.com
> > <mailto:mluis.reis@gmail.com>>
> > ---
> > arch/arm/dts/sama5d3.dtsi | 1 +
> > arch/arm/mach-at91/mpddrc.c | 3 ---
> > 2 files changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/dts/sama5d3.dtsi b/arch/arm/dts/sama5d3.dtsi
> > index 6ed218eaad..3cd30d574d 100644
> > --- a/arch/arm/dts/sama5d3.dtsi
> > +++ b/arch/arm/dts/sama5d3.dtsi
> > @@ -1316,6 +1316,7 @@
> > };
> >
> > pit: timer at fffffe30 {
> > + u-boot,dm-pre-reloc;
> > compatible = "atmel,at91sam9260-pit";
> > reg = <0xfffffe30 0xf>;
> > interrupts = <3 IRQ_TYPE_LEVEL_HIGH 5>;
> > diff --git a/arch/arm/mach-at91/mpddrc.c b/arch/arm/mach-at91/mpddrc.c
> > index 5422c05456..2e52595e30 100644
> > --- a/arch/arm/mach-at91/mpddrc.c
> > +++ b/arch/arm/mach-at91/mpddrc.c
> > @@ -66,9 +66,6 @@ int ddr2_init(const unsigned int base,
> > /* Issue a NOP command */
> > atmel_mpddr_op(mpddr, ATMEL_MPDDRC_MR_MODE_NOP_CMD, ram_address);
> >
> > - /* A 200 us is provided to precede any signal toggle */
> > - udelay(200);
> > -
> > /* Issue a NOP command */
> > atmel_mpddr_op(mpddr, ATMEL_MPDDRC_MR_MODE_NOP_CMD, ram_address);
> >
> > --
> > 2.27.0
> >
> >
> >
> >
> >
> >
> >
> > On Mon, 5 Apr 2021 at 14:58, <Eugen.Hristev@microchip.com
> > <mailto:Eugen.Hristev@microchip.com>> wrote:
> >
> > 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
> > <mailto: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 at gmail.com <mailto: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 at gmail.com <mailto: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,
> > >>>
> > >>>
> > >>
> >
>
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-04-05 17:50 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-23 11:06 SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94 Manuel Luís Reis
2021-03-23 11:14 ` Eugen.Hristev at microchip.com
2021-03-23 11:28 ` Manuel Luís Reis
2021-03-23 11:38 ` Eugen.Hristev at microchip.com
2021-03-23 13:20 ` Manuel Luís Reis
2021-03-23 16:08 ` Manuel Luís Reis
2021-03-23 16:26 ` Eugen.Hristev at microchip.com
2021-03-23 16:54 ` Manuel Luís Reis
2021-03-24 0:34 ` Sean Anderson
2021-03-25 10:25 ` Claudiu.Beznea at microchip.com
2021-04-02 17:12 ` Manuel Luís Reis
2021-04-02 17:15 ` Manuel Luís Reis
2021-04-04 16:25 ` Manuel Reis
2021-04-05 12:44 ` Eugen.Hristev at microchip.com
2021-04-05 12:47 ` Manuel Luís Reis
2021-04-05 13:58 ` Eugen.Hristev at microchip.com
2021-04-05 15:42 ` Manuel Luís Reis
2021-04-05 16:00 ` Eugen.Hristev at microchip.com
2021-04-05 17:50 ` Manuel Luís Reis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.