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