* Re: Converting to DM SERIAL for Kirkwood boards [not found] <CAJaLiFxnRPEPv83wasDBeuxzV2o39qF=hvSQvkft14irmH=L9A@mail.gmail.com> @ 2022-12-09 3:55 ` Tony Dinh 2022-12-09 6:56 ` Stefan Roese 0 siblings, 1 reply; 21+ messages in thread From: Tony Dinh @ 2022-12-09 3:55 UTC (permalink / raw) To: Simon Glass, U-Boot Mailing List; +Cc: Pali Rohár, Stefan Roese Hi Simon et al, (Resend to include u-boot mailing list) I'm in the process of converting Kirkwood boards to use DM SERIAL. I could not seem to get it to work, having tried adding CONFIG_DM_SERIAL, and also playing with various related CONFIG options (CONFIG_SPECIFY_CONSOLE_INDEX and CONFIG_CONS_INDEX ). From my reading various board configurations that were already converted to DM_SERIAL, I'm under the impression that just turning on CONFIG_DM_SERIAL would work without any other addition. The board I'm testing is Zyxel NSA310S Kirkwood 6702 (6192) SoC. diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig index afa0cad041..e81d1495bd 100644 --- a/configs/nsa310s_defconfig +++ b/configs/nsa310s_defconfig @@ -41,7 +41,6 @@ CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_NAND=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y -CONFIG_NETCONSOLE=y CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y CONFIG_SATA_MV=y CONFIG_SYS_SATA_MAX_DEVICE=1 @@ -53,6 +52,7 @@ CONFIG_MTD_RAW_NAND=y CONFIG_PHY_MARVELL=y CONFIG_MVGBE=y CONFIG_MII=y +CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y I also added kirkwood-nsa310s-u-boot.dtsi to help in running kwboot. &uart0 { u-boot,dm-pre-reloc; }; I've tried kwboot the new u-boot image, and also flashed this image to NAND, and in both cases, I got a silent serial console. It seems to hang up right off the bat. Hope you can help by giving me some pointers on how to debug this. Thanks, Tony ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-09 3:55 ` Converting to DM SERIAL for Kirkwood boards Tony Dinh @ 2022-12-09 6:56 ` Stefan Roese 2022-12-09 20:45 ` Tony Dinh 0 siblings, 1 reply; 21+ messages in thread From: Stefan Roese @ 2022-12-09 6:56 UTC (permalink / raw) To: Tony Dinh, Simon Glass, U-Boot Mailing List; +Cc: Pali Rohár Hi Tony, On 12/9/22 04:55, Tony Dinh wrote: > Hi Simon et al, > > (Resend to include u-boot mailing list) > > I'm in the process of converting Kirkwood boards to use DM SERIAL. I > could not seem to get it to work, having tried adding > CONFIG_DM_SERIAL, and also playing with various related CONFIG > options (CONFIG_SPECIFY_CONSOLE_INDEX and CONFIG_CONS_INDEX ). From > my reading various board configurations that were already converted to > DM_SERIAL, I'm under the impression that just turning on > CONFIG_DM_SERIAL would work without any other addition. > > The board I'm testing is Zyxel NSA310S Kirkwood 6702 (6192) SoC. > > diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig > index afa0cad041..e81d1495bd 100644 > --- a/configs/nsa310s_defconfig > +++ b/configs/nsa310s_defconfig > @@ -41,7 +41,6 @@ CONFIG_ENV_OVERWRITE=y > CONFIG_ENV_IS_IN_NAND=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > CONFIG_NET_RANDOM_ETHADDR=y > -CONFIG_NETCONSOLE=y > CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y > CONFIG_SATA_MV=y > CONFIG_SYS_SATA_MAX_DEVICE=1 > @@ -53,6 +52,7 @@ CONFIG_MTD_RAW_NAND=y > CONFIG_PHY_MARVELL=y > CONFIG_MVGBE=y > CONFIG_MII=y > +CONFIG_DM_SERIAL=y > CONFIG_SYS_NS16550=y > CONFIG_USB=y > CONFIG_USB_EHCI_HCD=y > > I also added kirkwood-nsa310s-u-boot.dtsi to help in running kwboot. > > &uart0 { > u-boot,dm-pre-reloc; > }; > > I've tried kwboot the new u-boot image, and also flashed this image to > NAND, and in both cases, I got a silent serial console. It seems to > hang up right off the bat. Hope you can help by giving me some > pointers on how to debug this. Might be that the alias is missing and / or that the uart DT node is not enabled. Please give this test-only patch a try: diff --git a/arch/arm/dts/kirkwood-nsa310s.dts b/arch/arm/dts/kirkwood-nsa310s.dts index 09ee76c2a2e0..ca7a49af9ba4 100644 --- a/arch/arm/dts/kirkwood-nsa310s.dts +++ b/arch/arm/dts/kirkwood-nsa310s.dts @@ -17,6 +17,10 @@ model = "Zyxel NSA310S"; compatible = "zyxel,nsa320s", "marvell,kirkwood-88f6702", "marvell,kirkwood"; + aliases { + serial0 = &uart0; + }; + memory { device_type = "memory"; reg = <0x00000000 0x10000000>; @@ -317,3 +321,8 @@ &pcie0 { status = "okay"; }; + +&uart0 { + status = "okay"; + u-boot,dm-pre-reloc; +}; Thanks, Stefan ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-09 6:56 ` Stefan Roese @ 2022-12-09 20:45 ` Tony Dinh 2022-12-12 9:03 ` Michael Walle 0 siblings, 1 reply; 21+ messages in thread From: Tony Dinh @ 2022-12-09 20:45 UTC (permalink / raw) To: Stefan Roese; +Cc: Simon Glass, U-Boot Mailing List, Pali Rohár On Thu, Dec 8, 2022 at 10:56 PM Stefan Roese <sr@denx.de> wrote: > > Hi Tony, > > On 12/9/22 04:55, Tony Dinh wrote: > > Hi Simon et al, > > > > (Resend to include u-boot mailing list) > > > > I'm in the process of converting Kirkwood boards to use DM SERIAL. I > > could not seem to get it to work, having tried adding > > CONFIG_DM_SERIAL, and also playing with various related CONFIG > > options (CONFIG_SPECIFY_CONSOLE_INDEX and CONFIG_CONS_INDEX ). From > > my reading various board configurations that were already converted to > > DM_SERIAL, I'm under the impression that just turning on > > CONFIG_DM_SERIAL would work without any other addition. > > > > The board I'm testing is Zyxel NSA310S Kirkwood 6702 (6192) SoC. > > > > diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig > > index afa0cad041..e81d1495bd 100644 > > --- a/configs/nsa310s_defconfig > > +++ b/configs/nsa310s_defconfig > > @@ -41,7 +41,6 @@ CONFIG_ENV_OVERWRITE=y > > CONFIG_ENV_IS_IN_NAND=y > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > > CONFIG_NET_RANDOM_ETHADDR=y > > -CONFIG_NETCONSOLE=y > > CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y > > CONFIG_SATA_MV=y > > CONFIG_SYS_SATA_MAX_DEVICE=1 > > @@ -53,6 +52,7 @@ CONFIG_MTD_RAW_NAND=y > > CONFIG_PHY_MARVELL=y > > CONFIG_MVGBE=y > > CONFIG_MII=y > > +CONFIG_DM_SERIAL=y > > CONFIG_SYS_NS16550=y > > CONFIG_USB=y > > CONFIG_USB_EHCI_HCD=y > > > > I also added kirkwood-nsa310s-u-boot.dtsi to help in running kwboot. > > > > &uart0 { > > u-boot,dm-pre-reloc; > > }; > > > > I've tried kwboot the new u-boot image, and also flashed this image to > > NAND, and in both cases, I got a silent serial console. It seems to > > hang up right off the bat. Hope you can help by giving me some > > pointers on how to debug this. > > Might be that the alias is missing and / or that the uart DT node is > not enabled. Please give this test-only patch a try: > > diff --git a/arch/arm/dts/kirkwood-nsa310s.dts > b/arch/arm/dts/kirkwood-nsa310s.dts > index 09ee76c2a2e0..ca7a49af9ba4 100644 > --- a/arch/arm/dts/kirkwood-nsa310s.dts > +++ b/arch/arm/dts/kirkwood-nsa310s.dts > @@ -17,6 +17,10 @@ > model = "Zyxel NSA310S"; > compatible = "zyxel,nsa320s", "marvell,kirkwood-88f6702", > "marvell,kirkwood"; > > + aliases { > + serial0 = &uart0; > + }; > + > memory { > device_type = "memory"; > reg = <0x00000000 0x10000000>; > @@ -317,3 +321,8 @@ > &pcie0 { > status = "okay"; > }; > + > +&uart0 { > + status = "okay"; > + u-boot,dm-pre-reloc; > +}; Thanks for the patch! but the behavior is still the same (silent serial console and hung the board). Thanks, Tony > > > Thanks, > Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-09 20:45 ` Tony Dinh @ 2022-12-12 9:03 ` Michael Walle 2022-12-13 1:18 ` Tony Dinh 0 siblings, 1 reply; 21+ messages in thread From: Michael Walle @ 2022-12-12 9:03 UTC (permalink / raw) To: mibodhi; +Cc: pali, sjg, sr, u-boot, Michael Walle >> On 12/9/22 04:55, Tony Dinh wrote: >> > Hi Simon et al, >> > >> > (Resend to include u-boot mailing list) >> > >> > I'm in the process of converting Kirkwood boards to use DM SERIAL. I >> > could not seem to get it to work, having tried adding >> > CONFIG_DM_SERIAL, and also playing with various related CONFIG >> > options (CONFIG_SPECIFY_CONSOLE_INDEX and CONFIG_CONS_INDEX ). From >> > my reading various board configurations that were already converted to >> > DM_SERIAL, I'm under the impression that just turning on >> > CONFIG_DM_SERIAL would work without any other addition. >> > >> > The board I'm testing is Zyxel NSA310S Kirkwood 6702 (6192) SoC. >> > >> > diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig >> > index afa0cad041..e81d1495bd 100644 >> > --- a/configs/nsa310s_defconfig >> > +++ b/configs/nsa310s_defconfig >> > @@ -41,7 +41,6 @@ CONFIG_ENV_OVERWRITE=y >> > CONFIG_ENV_IS_IN_NAND=y >> > CONFIG_SYS_RELOC_GD_ENV_ADDR=y >> > CONFIG_NET_RANDOM_ETHADDR=y >> > -CONFIG_NETCONSOLE=y >> > CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y >> > CONFIG_SATA_MV=y >> > CONFIG_SYS_SATA_MAX_DEVICE=1 >> > @@ -53,6 +52,7 @@ CONFIG_MTD_RAW_NAND=y >> > CONFIG_PHY_MARVELL=y >> > CONFIG_MVGBE=y >> > CONFIG_MII=y >> > +CONFIG_DM_SERIAL=y >> > CONFIG_SYS_NS16550=y >> > CONFIG_USB=y >> > CONFIG_USB_EHCI_HCD=y >> > >> > I also added kirkwood-nsa310s-u-boot.dtsi to help in running kwboot. >> > >> > &uart0 { >> > u-boot,dm-pre-reloc; >> > }; >> > >> > I've tried kwboot the new u-boot image, and also flashed this image to >> > NAND, and in both cases, I got a silent serial console. It seems to >> > hang up right off the bat. Hope you can help by giving me some >> > pointers on how to debug this. >> >> Might be that the alias is missing and / or that the uart DT node is >> not enabled. Please give this test-only patch a try: >> >> diff --git a/arch/arm/dts/kirkwood-nsa310s.dts >> b/arch/arm/dts/kirkwood-nsa310s.dts >> index 09ee76c2a2e0..ca7a49af9ba4 100644 >> --- a/arch/arm/dts/kirkwood-nsa310s.dts >> +++ b/arch/arm/dts/kirkwood-nsa310s.dts >> @@ -17,6 +17,10 @@ >> model = "Zyxel NSA310S"; >> compatible = "zyxel,nsa320s", "marvell,kirkwood-88f6702", >> "marvell,kirkwood"; >> >> + aliases { >> + serial0 = &uart0; >> + }; >> + >> memory { >> device_type = "memory"; >> reg = <0x00000000 0x10000000>; >> @@ -317,3 +321,8 @@ >> &pcie0 { >> status = "okay"; >> }; >> + >> +&uart0 { >> + status = "okay"; >> + u-boot,dm-pre-reloc; >> +}; > > Thanks for the patch! but the behavior is still the same (silent > serial console and hung the board). > > Thanks, > Tony Maybe this will help: https://lore.kernel.org/u-boot/20220817193809.1059688-20-michael@walle.cc/ The lsxl is also a kirkwood based board. -michael ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-12 9:03 ` Michael Walle @ 2022-12-13 1:18 ` Tony Dinh 2022-12-16 2:42 ` Tony Dinh 0 siblings, 1 reply; 21+ messages in thread From: Tony Dinh @ 2022-12-13 1:18 UTC (permalink / raw) To: Michael Walle; +Cc: pali, sjg, sr, u-boot Hi Michael, On Mon, Dec 12, 2022 at 1:03 AM Michael Walle <michael@walle.cc> wrote: > > >> On 12/9/22 04:55, Tony Dinh wrote: > >> > Hi Simon et al, > >> > > >> > (Resend to include u-boot mailing list) > >> > > >> > I'm in the process of converting Kirkwood boards to use DM SERIAL. I > >> > could not seem to get it to work, having tried adding > >> > CONFIG_DM_SERIAL, and also playing with various related CONFIG > >> > options (CONFIG_SPECIFY_CONSOLE_INDEX and CONFIG_CONS_INDEX ). From > >> > my reading various board configurations that were already converted to > >> > DM_SERIAL, I'm under the impression that just turning on > >> > CONFIG_DM_SERIAL would work without any other addition. > >> > > >> > The board I'm testing is Zyxel NSA310S Kirkwood 6702 (6192) SoC. > >> > > >> > diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig > >> > index afa0cad041..e81d1495bd 100644 > >> > --- a/configs/nsa310s_defconfig > >> > +++ b/configs/nsa310s_defconfig > >> > @@ -41,7 +41,6 @@ CONFIG_ENV_OVERWRITE=y > >> > CONFIG_ENV_IS_IN_NAND=y > >> > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > >> > CONFIG_NET_RANDOM_ETHADDR=y > >> > -CONFIG_NETCONSOLE=y > >> > CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y > >> > CONFIG_SATA_MV=y > >> > CONFIG_SYS_SATA_MAX_DEVICE=1 > >> > @@ -53,6 +52,7 @@ CONFIG_MTD_RAW_NAND=y > >> > CONFIG_PHY_MARVELL=y > >> > CONFIG_MVGBE=y > >> > CONFIG_MII=y > >> > +CONFIG_DM_SERIAL=y > >> > CONFIG_SYS_NS16550=y > >> > CONFIG_USB=y > >> > CONFIG_USB_EHCI_HCD=y > >> > > >> > I also added kirkwood-nsa310s-u-boot.dtsi to help in running kwboot. > >> > > >> > &uart0 { > >> > u-boot,dm-pre-reloc; > >> > }; > >> > > >> > I've tried kwboot the new u-boot image, and also flashed this image to > >> > NAND, and in both cases, I got a silent serial console. It seems to > >> > hang up right off the bat. Hope you can help by giving me some > >> > pointers on how to debug this. > >> > >> Might be that the alias is missing and / or that the uart DT node is > >> not enabled. Please give this test-only patch a try: > >> > >> diff --git a/arch/arm/dts/kirkwood-nsa310s.dts > >> b/arch/arm/dts/kirkwood-nsa310s.dts > >> index 09ee76c2a2e0..ca7a49af9ba4 100644 > >> --- a/arch/arm/dts/kirkwood-nsa310s.dts > >> +++ b/arch/arm/dts/kirkwood-nsa310s.dts > >> @@ -17,6 +17,10 @@ > >> model = "Zyxel NSA310S"; > >> compatible = "zyxel,nsa320s", "marvell,kirkwood-88f6702", > >> "marvell,kirkwood"; > >> > >> + aliases { > >> + serial0 = &uart0; > >> + }; > >> + > >> memory { > >> device_type = "memory"; > >> reg = <0x00000000 0x10000000>; > >> @@ -317,3 +321,8 @@ > >> &pcie0 { > >> status = "okay"; > >> }; > >> + > >> +&uart0 { > >> + status = "okay"; > >> + u-boot,dm-pre-reloc; > >> +}; > > > > Thanks for the patch! but the behavior is still the same (silent > > serial console and hung the board). > > > > Thanks, > > Tony > > Maybe this will help: > https://lore.kernel.org/u-boot/20220817193809.1059688-20-michael@walle.cc/ > > The lsxl is also a kirkwood based board. > Thanks! indeed that was the malloc problem. This NSA310S board is now working with DM_SERIAL. I will test a few more Kirkwood boards and keep everybody posted. All the best, Tony > -michael ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-13 1:18 ` Tony Dinh @ 2022-12-16 2:42 ` Tony Dinh 2022-12-16 6:29 ` Stefan Roese 2022-12-16 7:56 ` Pali Rohár 0 siblings, 2 replies; 21+ messages in thread From: Tony Dinh @ 2022-12-16 2:42 UTC (permalink / raw) To: Michael Walle; +Cc: pali, sjg, sr, u-boot Hi all, On Mon, Dec 12, 2022 at 5:18 PM Tony Dinh <mibodhi@gmail.com> wrote: > > Hi Michael, > > On Mon, Dec 12, 2022 at 1:03 AM Michael Walle <michael@walle.cc> wrote: > > > > >> On 12/9/22 04:55, Tony Dinh wrote: > > >> > Hi Simon et al, > > >> > > > >> > (Resend to include u-boot mailing list) > > >> > > > >> > I'm in the process of converting Kirkwood boards to use DM SERIAL. I > > >> > could not seem to get it to work, having tried adding > > >> > CONFIG_DM_SERIAL, and also playing with various related CONFIG > > >> > options (CONFIG_SPECIFY_CONSOLE_INDEX and CONFIG_CONS_INDEX ). From > > >> > my reading various board configurations that were already converted to > > >> > DM_SERIAL, I'm under the impression that just turning on > > >> > CONFIG_DM_SERIAL would work without any other addition. > > >> > > > >> > The board I'm testing is Zyxel NSA310S Kirkwood 6702 (6192) SoC. > > >> > > > >> > diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig > > >> > index afa0cad041..e81d1495bd 100644 > > >> > --- a/configs/nsa310s_defconfig > > >> > +++ b/configs/nsa310s_defconfig > > >> > @@ -41,7 +41,6 @@ CONFIG_ENV_OVERWRITE=y > > >> > CONFIG_ENV_IS_IN_NAND=y > > >> > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > > >> > CONFIG_NET_RANDOM_ETHADDR=y > > >> > -CONFIG_NETCONSOLE=y > > >> > CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y > > >> > CONFIG_SATA_MV=y > > >> > CONFIG_SYS_SATA_MAX_DEVICE=1 > > >> > @@ -53,6 +52,7 @@ CONFIG_MTD_RAW_NAND=y > > >> > CONFIG_PHY_MARVELL=y > > >> > CONFIG_MVGBE=y > > >> > CONFIG_MII=y > > >> > +CONFIG_DM_SERIAL=y > > >> > CONFIG_SYS_NS16550=y > > >> > CONFIG_USB=y > > >> > CONFIG_USB_EHCI_HCD=y > > >> > > > >> > I also added kirkwood-nsa310s-u-boot.dtsi to help in running kwboot. > > >> > > > >> > &uart0 { > > >> > u-boot,dm-pre-reloc; > > >> > }; > > >> > > > >> > I've tried kwboot the new u-boot image, and also flashed this image to > > >> > NAND, and in both cases, I got a silent serial console. It seems to > > >> > hang up right off the bat. Hope you can help by giving me some > > >> > pointers on how to debug this. > > >> > > >> Might be that the alias is missing and / or that the uart DT node is > > >> not enabled. Please give this test-only patch a try: > > >> > > >> diff --git a/arch/arm/dts/kirkwood-nsa310s.dts > > >> b/arch/arm/dts/kirkwood-nsa310s.dts > > >> index 09ee76c2a2e0..ca7a49af9ba4 100644 > > >> --- a/arch/arm/dts/kirkwood-nsa310s.dts > > >> +++ b/arch/arm/dts/kirkwood-nsa310s.dts > > >> @@ -17,6 +17,10 @@ > > >> model = "Zyxel NSA310S"; > > >> compatible = "zyxel,nsa320s", "marvell,kirkwood-88f6702", > > >> "marvell,kirkwood"; > > >> > > >> + aliases { > > >> + serial0 = &uart0; > > >> + }; > > >> + > > >> memory { > > >> device_type = "memory"; > > >> reg = <0x00000000 0x10000000>; > > >> @@ -317,3 +321,8 @@ > > >> &pcie0 { > > >> status = "okay"; > > >> }; > > >> + > > >> +&uart0 { > > >> + status = "okay"; > > >> + u-boot,dm-pre-reloc; > > >> +}; > > > > > > Thanks for the patch! but the behavior is still the same (silent > > > serial console and hung the board). > > > > > > Thanks, > > > Tony > > > > Maybe this will help: > > https://lore.kernel.org/u-boot/20220817193809.1059688-20-michael@walle.cc/ > > > > The lsxl is also a kirkwood based board. > > > > Thanks! indeed that was the malloc problem. This NSA310S board is now > working with DM_SERIAL. > > I will test a few more Kirkwood boards and keep everybody posted. Closing the loop on this DM_SERIAL conversion for Kirkwood. I've tested DM_SERIAL with Michael's malloc patches on a few other Kirkwood boards. They're all working fine with u-boot-2023.01-rc3. NSA310s Dreamplug Sheevaplug GFHome Dockstar iConnect Pogo E02 Pogo V4 (tested with u-boot-2022.10, since Pogo V4 itself was broken in u-boot-2023.01-rc3 for unknown reason). All the best, Tony ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-16 2:42 ` Tony Dinh @ 2022-12-16 6:29 ` Stefan Roese 2022-12-23 6:34 ` Tony Dinh 2022-12-16 7:56 ` Pali Rohár 1 sibling, 1 reply; 21+ messages in thread From: Stefan Roese @ 2022-12-16 6:29 UTC (permalink / raw) To: Tony Dinh, Michael Walle; +Cc: pali, sjg, u-boot Hi Tony, On 12/16/22 03:42, Tony Dinh wrote: > Hi all, > > On Mon, Dec 12, 2022 at 5:18 PM Tony Dinh <mibodhi@gmail.com> wrote: >> >> Hi Michael, >> >> On Mon, Dec 12, 2022 at 1:03 AM Michael Walle <michael@walle.cc> wrote: >>> >>>>> On 12/9/22 04:55, Tony Dinh wrote: >>>>>> Hi Simon et al, >>>>>> >>>>>> (Resend to include u-boot mailing list) >>>>>> >>>>>> I'm in the process of converting Kirkwood boards to use DM SERIAL. I >>>>>> could not seem to get it to work, having tried adding >>>>>> CONFIG_DM_SERIAL, and also playing with various related CONFIG >>>>>> options (CONFIG_SPECIFY_CONSOLE_INDEX and CONFIG_CONS_INDEX ). From >>>>>> my reading various board configurations that were already converted to >>>>>> DM_SERIAL, I'm under the impression that just turning on >>>>>> CONFIG_DM_SERIAL would work without any other addition. >>>>>> >>>>>> The board I'm testing is Zyxel NSA310S Kirkwood 6702 (6192) SoC. >>>>>> >>>>>> diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig >>>>>> index afa0cad041..e81d1495bd 100644 >>>>>> --- a/configs/nsa310s_defconfig >>>>>> +++ b/configs/nsa310s_defconfig >>>>>> @@ -41,7 +41,6 @@ CONFIG_ENV_OVERWRITE=y >>>>>> CONFIG_ENV_IS_IN_NAND=y >>>>>> CONFIG_SYS_RELOC_GD_ENV_ADDR=y >>>>>> CONFIG_NET_RANDOM_ETHADDR=y >>>>>> -CONFIG_NETCONSOLE=y >>>>>> CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y >>>>>> CONFIG_SATA_MV=y >>>>>> CONFIG_SYS_SATA_MAX_DEVICE=1 >>>>>> @@ -53,6 +52,7 @@ CONFIG_MTD_RAW_NAND=y >>>>>> CONFIG_PHY_MARVELL=y >>>>>> CONFIG_MVGBE=y >>>>>> CONFIG_MII=y >>>>>> +CONFIG_DM_SERIAL=y >>>>>> CONFIG_SYS_NS16550=y >>>>>> CONFIG_USB=y >>>>>> CONFIG_USB_EHCI_HCD=y >>>>>> >>>>>> I also added kirkwood-nsa310s-u-boot.dtsi to help in running kwboot. >>>>>> >>>>>> &uart0 { >>>>>> u-boot,dm-pre-reloc; >>>>>> }; >>>>>> >>>>>> I've tried kwboot the new u-boot image, and also flashed this image to >>>>>> NAND, and in both cases, I got a silent serial console. It seems to >>>>>> hang up right off the bat. Hope you can help by giving me some >>>>>> pointers on how to debug this. >>>>> >>>>> Might be that the alias is missing and / or that the uart DT node is >>>>> not enabled. Please give this test-only patch a try: >>>>> >>>>> diff --git a/arch/arm/dts/kirkwood-nsa310s.dts >>>>> b/arch/arm/dts/kirkwood-nsa310s.dts >>>>> index 09ee76c2a2e0..ca7a49af9ba4 100644 >>>>> --- a/arch/arm/dts/kirkwood-nsa310s.dts >>>>> +++ b/arch/arm/dts/kirkwood-nsa310s.dts >>>>> @@ -17,6 +17,10 @@ >>>>> model = "Zyxel NSA310S"; >>>>> compatible = "zyxel,nsa320s", "marvell,kirkwood-88f6702", >>>>> "marvell,kirkwood"; >>>>> >>>>> + aliases { >>>>> + serial0 = &uart0; >>>>> + }; >>>>> + >>>>> memory { >>>>> device_type = "memory"; >>>>> reg = <0x00000000 0x10000000>; >>>>> @@ -317,3 +321,8 @@ >>>>> &pcie0 { >>>>> status = "okay"; >>>>> }; >>>>> + >>>>> +&uart0 { >>>>> + status = "okay"; >>>>> + u-boot,dm-pre-reloc; >>>>> +}; >>>> >>>> Thanks for the patch! but the behavior is still the same (silent >>>> serial console and hung the board). >>>> >>>> Thanks, >>>> Tony >>> >>> Maybe this will help: >>> https://lore.kernel.org/u-boot/20220817193809.1059688-20-michael@walle.cc/ >>> >>> The lsxl is also a kirkwood based board. >>> >> >> Thanks! indeed that was the malloc problem. This NSA310S board is now >> working with DM_SERIAL. >> >> I will test a few more Kirkwood boards and keep everybody posted. > > Closing the loop on this DM_SERIAL conversion for Kirkwood. > > I've tested DM_SERIAL with Michael's malloc patches on a few other > Kirkwood boards. They're all working fine with u-boot-2023.01-rc3. Good to know. I assume that you will post some patches for these Kirkwood board soon? Or even better, making the necessary changes for Kirkwood in general in Kconfig (if possible). Thanks, Stefan > NSA310s > Dreamplug > Sheevaplug > GFHome > Dockstar > iConnect > Pogo E02 > Pogo V4 (tested with u-boot-2022.10, since Pogo V4 itself was broken > in u-boot-2023.01-rc3 for unknown reason). > > All the best, > Tony Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-16 6:29 ` Stefan Roese @ 2022-12-23 6:34 ` Tony Dinh 0 siblings, 0 replies; 21+ messages in thread From: Tony Dinh @ 2022-12-23 6:34 UTC (permalink / raw) To: Stefan Roese; +Cc: Michael Walle, pali, sjg, u-boot Hi Stefan, On Thu, Dec 15, 2022 at 10:29 PM Stefan Roese <sr@denx.de> wrote: > > Hi Tony, > > On 12/16/22 03:42, Tony Dinh wrote: > > Hi all, > > > > On Mon, Dec 12, 2022 at 5:18 PM Tony Dinh <mibodhi@gmail.com> wrote: > >> > >> Hi Michael, > >> > >> On Mon, Dec 12, 2022 at 1:03 AM Michael Walle <michael@walle.cc> wrote: > >>> > >>>>> On 12/9/22 04:55, Tony Dinh wrote: > >>>>>> Hi Simon et al, > >>>>>> > >>>>>> (Resend to include u-boot mailing list) > >>>>>> > >>>>>> I'm in the process of converting Kirkwood boards to use DM SERIAL. I > >>>>>> could not seem to get it to work, having tried adding > >>>>>> CONFIG_DM_SERIAL, and also playing with various related CONFIG > >>>>>> options (CONFIG_SPECIFY_CONSOLE_INDEX and CONFIG_CONS_INDEX ). From > >>>>>> my reading various board configurations that were already converted to > >>>>>> DM_SERIAL, I'm under the impression that just turning on > >>>>>> CONFIG_DM_SERIAL would work without any other addition. > >>>>>> > >>>>>> The board I'm testing is Zyxel NSA310S Kirkwood 6702 (6192) SoC. > >>>>>> > >>>>>> diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig > >>>>>> index afa0cad041..e81d1495bd 100644 > >>>>>> --- a/configs/nsa310s_defconfig > >>>>>> +++ b/configs/nsa310s_defconfig > >>>>>> @@ -41,7 +41,6 @@ CONFIG_ENV_OVERWRITE=y > >>>>>> CONFIG_ENV_IS_IN_NAND=y > >>>>>> CONFIG_SYS_RELOC_GD_ENV_ADDR=y > >>>>>> CONFIG_NET_RANDOM_ETHADDR=y > >>>>>> -CONFIG_NETCONSOLE=y > >>>>>> CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y > >>>>>> CONFIG_SATA_MV=y > >>>>>> CONFIG_SYS_SATA_MAX_DEVICE=1 > >>>>>> @@ -53,6 +52,7 @@ CONFIG_MTD_RAW_NAND=y > >>>>>> CONFIG_PHY_MARVELL=y > >>>>>> CONFIG_MVGBE=y > >>>>>> CONFIG_MII=y > >>>>>> +CONFIG_DM_SERIAL=y > >>>>>> CONFIG_SYS_NS16550=y > >>>>>> CONFIG_USB=y > >>>>>> CONFIG_USB_EHCI_HCD=y > >>>>>> > >>>>>> I also added kirkwood-nsa310s-u-boot.dtsi to help in running kwboot. > >>>>>> > >>>>>> &uart0 { > >>>>>> u-boot,dm-pre-reloc; > >>>>>> }; > >>>>>> > >>>>>> I've tried kwboot the new u-boot image, and also flashed this image to > >>>>>> NAND, and in both cases, I got a silent serial console. It seems to > >>>>>> hang up right off the bat. Hope you can help by giving me some > >>>>>> pointers on how to debug this. > >>>>> > >>>>> Might be that the alias is missing and / or that the uart DT node is > >>>>> not enabled. Please give this test-only patch a try: > >>>>> > >>>>> diff --git a/arch/arm/dts/kirkwood-nsa310s.dts > >>>>> b/arch/arm/dts/kirkwood-nsa310s.dts > >>>>> index 09ee76c2a2e0..ca7a49af9ba4 100644 > >>>>> --- a/arch/arm/dts/kirkwood-nsa310s.dts > >>>>> +++ b/arch/arm/dts/kirkwood-nsa310s.dts > >>>>> @@ -17,6 +17,10 @@ > >>>>> model = "Zyxel NSA310S"; > >>>>> compatible = "zyxel,nsa320s", "marvell,kirkwood-88f6702", > >>>>> "marvell,kirkwood"; > >>>>> > >>>>> + aliases { > >>>>> + serial0 = &uart0; > >>>>> + }; > >>>>> + > >>>>> memory { > >>>>> device_type = "memory"; > >>>>> reg = <0x00000000 0x10000000>; > >>>>> @@ -317,3 +321,8 @@ > >>>>> &pcie0 { > >>>>> status = "okay"; > >>>>> }; > >>>>> + > >>>>> +&uart0 { > >>>>> + status = "okay"; > >>>>> + u-boot,dm-pre-reloc; > >>>>> +}; > >>>> > >>>> Thanks for the patch! but the behavior is still the same (silent > >>>> serial console and hung the board). > >>>> > >>>> Thanks, > >>>> Tony > >>> > >>> Maybe this will help: > >>> https://lore.kernel.org/u-boot/20220817193809.1059688-20-michael@walle.cc/ > >>> > >>> The lsxl is also a kirkwood based board. > >>> > >> > >> Thanks! indeed that was the malloc problem. This NSA310S board is now > >> working with DM_SERIAL. > >> > >> I will test a few more Kirkwood boards and keep everybody posted. > > > > Closing the loop on this DM_SERIAL conversion for Kirkwood. > > > > I've tested DM_SERIAL with Michael's malloc patches on a few other > > Kirkwood boards. They're all working fine with u-boot-2023.01-rc3. > > Good to know. I assume that you will post some patches for these > Kirkwood board soon? Or even better, making the necessary changes > for Kirkwood in general in Kconfig (if possible). Here is a RFC patch to convert Kirkwood boards to DM_SERIAL and also set up the boards using Michael's approach for the CUSTOM_SYS_INIT_SP_ADDR. I'm not sure this is the best way to do it, so I thought I should run it by this list first to see if I'm on the right track. My rationale is that even though HAS_CUSTOM_SYS_INIT_SP_ADDR and CUSTOM_SYS_INIT_SP_ADDR are already defined in top level ./Kconfig, the value CUSTOM_SYS_INIT_SP_ADDR=0x5ff000 belongs in the ./arch/arm/mach-kirkwood/Kconfig. And note that it will work regardless whether DM_SERIAL is enabled or not. And since we are still converting the boards to DM_SERIAL, during the transition it should be up to the individual maintainer to do it. Once the mandatory deadline is over, we can turn it on wholesale in arch/arm/mach-kirkwood/Kconfig (by enabling CONFIG_KIRKWOOD_COMMON for each board). diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig index c8a193dd4c..45cc932636 100644 --- a/arch/arm/mach-kirkwood/Kconfig +++ b/arch/arm/mach-kirkwood/Kconfig @@ -12,6 +12,19 @@ config KW88F6281 config SHEEVA_88SV131 bool +config KIRKWOOD_COMMON + bool + select DM_SERIAL + +config HAS_CUSTOM_SYS_INIT_SP_ADDR + bool "Use a custom location for the initial stack pointer address" + default y + +config CUSTOM_SYS_INIT_SP_ADDR + hex "Static location for the initial stack pointer" + depends on HAS_CUSTOM_SYS_INIT_SP_ADDR + default 0x5ff000 + choice prompt "Marvell Kirkwood board select" optional @@ -25,6 +38,7 @@ config TARGET_DREAMPLUG bool "DreamPlug Board" select KW88F6281 select SHEEVA_88SV131 + select KIRKWOOD_COMMON config TARGET_DS109 bool "Synology DS109" @@ -40,6 +54,7 @@ config TARGET_SHEEVAPLUG bool "SheevaPlug Board" select FEROCEON_88FR131 select KW88F6281 + select KIRKWOOD_COMMON config TARGET_LSXL bool "lsxl Board" @@ -47,16 +62,19 @@ config TARGET_LSXL select KW88F6281 select BOARD_EARLY_INIT_R select MISC_INIT_R + select KIRKWOOD_COMMON config TARGET_POGO_E02 bool "pogo_e02 Board" select FEROCEON_88FR131 select KW88F6281 + select KIRKWOOD_COMMON config TARGET_POGO_V4 bool "Pogoplug V4 Board" select FEROCEON_88FR131 select KW88F6192 + select KIRKWOOD_COMMON config TARGET_DNS325 bool "dns325 Board" @@ -67,6 +85,7 @@ config TARGET_ICONNECT bool "iconnect Board" select FEROCEON_88FR131 select KW88F6281 + select KIRKWOOD_COMMON config TARGET_KM_KIRKWOOD bool "KM Kirkwood Board" @@ -92,11 +111,13 @@ config TARGET_DOCKSTAR bool "Dockstar Board" select FEROCEON_88FR131 select KW88F6281 + select KIRKWOOD_COMMON config TARGET_GOFLEXHOME bool "GoFlex Home Board" select FEROCEON_88FR131 select KW88F6281 + select KIRKWOOD_COMMON config TARGET_NAS220 bool "BlackArmor NAS220" @@ -107,6 +128,7 @@ config TARGET_NSA310S bool "Zyxel NSA310S" select FEROCEON_88FR131 select KW88F6192 + select KIRKWOOD_COMMON config TARGET_SBx81LIFKW bool "Allied Telesis SBx81GS24/SBx81GT40/SBx81XS6/SBx81XS16" Thanks, Tony > > Thanks, > Stefan > > > NSA310s > > Dreamplug > > Sheevaplug > > GFHome > > Dockstar > > iConnect > > Pogo E02 > > Pogo V4 (tested with u-boot-2022.10, since Pogo V4 itself was broken > > in u-boot-2023.01-rc3 for unknown reason). > > > > All the best, > > Tony > > Viele Grüße, > Stefan Roese > > -- > DENX Software Engineering GmbH, Managing Director: Erika Unter > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-16 2:42 ` Tony Dinh 2022-12-16 6:29 ` Stefan Roese @ 2022-12-16 7:56 ` Pali Rohár 2022-12-16 21:49 ` Tony Dinh 1 sibling, 1 reply; 21+ messages in thread From: Pali Rohár @ 2022-12-16 7:56 UTC (permalink / raw) To: Tony Dinh; +Cc: Michael Walle, sjg, sr, u-boot On Thursday 15 December 2022 18:42:20 Tony Dinh wrote: > Pogo V4 (tested with u-boot-2022.10, since Pogo V4 itself was broken > in u-boot-2023.01-rc3 for unknown reason). Could you try to git bisect which commit broke it? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-16 7:56 ` Pali Rohár @ 2022-12-16 21:49 ` Tony Dinh 2022-12-19 0:17 ` Tony Dinh 0 siblings, 1 reply; 21+ messages in thread From: Tony Dinh @ 2022-12-16 21:49 UTC (permalink / raw) To: Pali Rohár; +Cc: Michael Walle, sjg, sr, u-boot Hi Stefan, Yes, I also think we need Kconfig changes for Kirwood. I will try that and send in patches. Hi Pali, I hope debugging this will be a bit quicker now that I can tell that it got stuck (hung or infinite loop) in nand_init() in ./common/board_r.c. U-Boot 2023.01-rc3-00048-gc917865c7f-dirty (Dec 15 2022 - 21:20:41 -0800) Pogoplug V4 SoC: Kirkwood 88F6281_A1 Model: Cloud Engines PogoPlug Series 4 DRAM: 128 MiB Core: 19 devices, 15 uclasses, devicetree: separate NAND: All the best, Tony ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-16 21:49 ` Tony Dinh @ 2022-12-19 0:17 ` Tony Dinh 2022-12-19 6:17 ` Stefan Roese 0 siblings, 1 reply; 21+ messages in thread From: Tony Dinh @ 2022-12-19 0:17 UTC (permalink / raw) To: Pali Rohár; +Cc: Michael Walle, sjg, sr, u-boot Hi Stefan, On Fri, Dec 16, 2022 at 1:49 PM Tony Dinh <mibodhi@gmail.com> wrote: > > Hi Stefan, > Yes, I also think we need Kconfig changes for Kirwood. I will try that > and send in patches. > > Hi Pali, > I hope debugging this will be a bit quicker now that I can tell that > it got stuck (hung or infinite loop) in nand_init() in > ./common/board_r.c. > > U-Boot 2023.01-rc3-00048-gc917865c7f-dirty (Dec 15 2022 - 21:20:41 -0800) > Pogoplug V4 > SoC: Kirkwood 88F6281_A1 > Model: Cloud Engines PogoPlug Series 4 > DRAM: 128 MiB > Core: 19 devices, 15 uclasses, devicetree: separate > NAND: > As Pali suggested, I did a git bisect to track down the Pogo V4 problem. And the result is that perhaps we missed testing commit 37bb396669 in rc1. If I go back one commit from this one, it is working fine. So I think the orion_timer itself is working very well with no problem. git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for programming LD0 and LD1 eFuse HEAD is now at 37bb396669 timer: orion-timer: Only init timer once This is where the Pogo V4 was frozen during boot. Among the Kirkwood boards that I have and used for testing, it is the only one that has CONFIG_BOOTSTAGE=y. Should I create a new post for would like to continue this topic here in this thread? Thanks, Tony ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-19 0:17 ` Tony Dinh @ 2022-12-19 6:17 ` Stefan Roese 2022-12-19 7:29 ` Stefan Roese 0 siblings, 1 reply; 21+ messages in thread From: Stefan Roese @ 2022-12-19 6:17 UTC (permalink / raw) To: Tony Dinh, Pali Rohár; +Cc: Michael Walle, sjg, u-boot Hi Tony, On 12/19/22 01:17, Tony Dinh wrote: > Hi Stefan, > > On Fri, Dec 16, 2022 at 1:49 PM Tony Dinh <mibodhi@gmail.com> wrote: >> >> Hi Stefan, >> Yes, I also think we need Kconfig changes for Kirwood. I will try that >> and send in patches. >> >> Hi Pali, >> I hope debugging this will be a bit quicker now that I can tell that >> it got stuck (hung or infinite loop) in nand_init() in >> ./common/board_r.c. >> >> U-Boot 2023.01-rc3-00048-gc917865c7f-dirty (Dec 15 2022 - 21:20:41 -0800) >> Pogoplug V4 >> SoC: Kirkwood 88F6281_A1 >> Model: Cloud Engines PogoPlug Series 4 >> DRAM: 128 MiB >> Core: 19 devices, 15 uclasses, devicetree: separate >> NAND: >> > > As Pali suggested, I did a git bisect to track down the Pogo V4 > problem. And the result is that perhaps we missed testing commit > 37bb396669 in rc1. If I go back one commit from this one, it is > working fine. So I think the orion_timer itself is working very well > with no problem. > > git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 > Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for > programming LD0 and LD1 eFuse > HEAD is now at 37bb396669 timer: orion-timer: Only init timer once > > This is where the Pogo V4 was frozen during boot. Among the Kirkwood > boards that I have and used for testing, it is the only one that has > CONFIG_BOOTSTAGE=y. Thanks for testing and git bi-secting. > Should I create a new post for would like to continue this topic here > in this thread? Let me check, if I can find the root cause and this problem quickly. If not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for a short while until we've fixed this issue. Thanks, Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-19 6:17 ` Stefan Roese @ 2022-12-19 7:29 ` Stefan Roese 2022-12-19 21:22 ` Tony Dinh 0 siblings, 1 reply; 21+ messages in thread From: Stefan Roese @ 2022-12-19 7:29 UTC (permalink / raw) To: Tony Dinh; +Cc: Michael Walle, sjg, u-boot, Pali Rohár [-- Attachment #1: Type: text/plain, Size: 1138 bytes --] Hi Tony, On 12/19/22 07:17, Stefan Roese wrote: <snip> >> git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 >> Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for >> programming LD0 and LD1 eFuse >> HEAD is now at 37bb396669 timer: orion-timer: Only init timer once >> >> This is where the Pogo V4 was frozen during boot. Among the Kirkwood >> boards that I have and used for testing, it is the only one that has >> CONFIG_BOOTSTAGE=y. > > Thanks for testing and git bi-secting. > >> Should I create a new post for would like to continue this topic here >> in this thread? > > Let me check, if I can find the root cause and this problem quickly. If > not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for > a short while until we've fixed this issue. I fail to spot the problem with this small commit 37bb396669b27a. I can also not reproduce this on my Armada XP board - it uses SPL though, this might make a difference. Could you perhaps apply this attached debug patch and make sure, that you have DEBUG_UART enabled in your Pogo v4 config. And boot into the resulting image. Thanks, Stefan [-- Attachment #2: orion-timer-debug.patch --] [-- Type: text/x-patch, Size: 1380 bytes --] diff --git a/drivers/timer/orion-timer.c b/drivers/timer/orion-timer.c index d0eab3ce781d..8c5cfa46762c 100644 --- a/drivers/timer/orion-timer.c +++ b/drivers/timer/orion-timer.c @@ -5,6 +5,7 @@ #include <dm/device.h> #include <dm/fdtaddr.h> #include <timer.h> +#include <debug_uart.h> #define TIMER_CTRL 0x00 #define TIMER0_EN BIT(0) @@ -33,6 +34,7 @@ static void orion_timer_init(void *base, enum input_clock_type type) return; early_init_done = true; + printch('1'); // test-only writel(~0, base + TIMER0_VAL); writel(~0, base + TIMER0_RELOAD); @@ -56,6 +58,7 @@ static uint64_t orion_timer_get_count(void *base) /* Early (e.g. bootstage etc) timer functions */ static void notrace timer_early_init(void) { + printch('2'); // test-only if (IS_ENABLED(CONFIG_ARCH_MVEBU)) orion_timer_init((void *)MVEBU_TIMER_BASE, INPUT_CLOCK_25MHZ); else @@ -90,6 +93,7 @@ ulong timer_get_boot_us(void) { u64 ticks; + printch('3'); // test-only ticks = timer_early_get_count(); return lldiv(ticks * 1000, timer_early_get_rate()); } @@ -108,6 +112,7 @@ static int orion_timer_probe(struct udevice *dev) enum input_clock_type type = dev_get_driver_data(dev); struct orion_timer_priv *priv = dev_get_priv(dev); + printch('4'); // test-only priv->base = devfdt_remap_addr_index(dev, 0); if (!priv->base) { debug("unable to map registers\n"); ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-19 7:29 ` Stefan Roese @ 2022-12-19 21:22 ` Tony Dinh 2022-12-20 0:06 ` Tony Dinh 2022-12-20 6:10 ` Stefan Roese 0 siblings, 2 replies; 21+ messages in thread From: Tony Dinh @ 2022-12-19 21:22 UTC (permalink / raw) To: Stefan Roese; +Cc: Michael Walle, sjg, u-boot, Pali Rohár Hi Stefan, On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <sr@denx.de> wrote: > > Hi Tony, > > On 12/19/22 07:17, Stefan Roese wrote: > > <snip> > > >> git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 > >> Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for > >> programming LD0 and LD1 eFuse > >> HEAD is now at 37bb396669 timer: orion-timer: Only init timer once > >> > >> This is where the Pogo V4 was frozen during boot. Among the Kirkwood > >> boards that I have and used for testing, it is the only one that has > >> CONFIG_BOOTSTAGE=y. > > > > Thanks for testing and git bi-secting. > > > >> Should I create a new post for would like to continue this topic here > >> in this thread? > > > > Let me check, if I can find the root cause and this problem quickly. If > > not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for > > a short while until we've fixed this issue. > > I fail to spot the problem with this small commit 37bb396669b27a. I can > also not reproduce this on my Armada XP board - it uses SPL though, this > might make a difference. > > Could you perhaps apply this attached debug patch and make sure, that > you have DEBUG_UART enabled in your Pogo v4 config. And boot into the > resulting image. Here is the kwboot log with DEBUG_UART. Note that number 322322 below is part of the log. 322322 U-Boot 2023.01-rc3-00057-g9bd3d354a1-dirty (Dec 19 2022 - 01:29:21 -0800) Pogoplug V4 SoC: Kirkwood 88F6281_A1 Model: Cloud Engines PogoPlug Series 4 DRAM: 128 MiB 322322322Core: 19 devices, 15 uclasses, devicetree: separate NAND: 4 Thanks, Tony > Thanks, > Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-19 21:22 ` Tony Dinh @ 2022-12-20 0:06 ` Tony Dinh 2022-12-20 1:36 ` Tony Dinh 2022-12-20 6:10 ` Stefan Roese 1 sibling, 1 reply; 21+ messages in thread From: Tony Dinh @ 2022-12-20 0:06 UTC (permalink / raw) To: Stefan Roese; +Cc: Michael Walle, sjg, u-boot, Pali Rohár Hi Stefan, On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh <mibodhi@gmail.com> wrote: > > Hi Stefan, > > On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <sr@denx.de> wrote: > > > > Hi Tony, > > > > On 12/19/22 07:17, Stefan Roese wrote: > > > > <snip> > > > > >> git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 > > >> Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for > > >> programming LD0 and LD1 eFuse > > >> HEAD is now at 37bb396669 timer: orion-timer: Only init timer once > > >> > > >> This is where the Pogo V4 was frozen during boot. Among the Kirkwood > > >> boards that I have and used for testing, it is the only one that has > > >> CONFIG_BOOTSTAGE=y. > > > > > > Thanks for testing and git bi-secting. > > > > > >> Should I create a new post for would like to continue this topic here > > >> in this thread? > > > > > > Let me check, if I can find the root cause and this problem quickly. If > > > not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for > > > a short while until we've fixed this issue. > > > > I fail to spot the problem with this small commit 37bb396669b27a. I can > > also not reproduce this on my Armada XP board - it uses SPL though, this > > might make a difference. > > > > Could you perhaps apply this attached debug patch and make sure, that > > you have DEBUG_UART enabled in your Pogo v4 config. And boot into the > > resulting image. > > Here is the kwboot log with DEBUG_UART. Note that number 322322 below > is part of the log. > > 322322 > > U-Boot 2023.01-rc3-00057-g9bd3d354a1-dirty (Dec 19 2022 - 01:29:21 -0800) > Pogoplug V4 > > SoC: Kirkwood 88F6281_A1 > Model: Cloud Engines PogoPlug Series 4 > DRAM: 128 MiB > 322322322Core: 19 devices, 15 uclasses, devicetree: separate > NAND: 4 > Going a bit further with your debug patch, I've added more prints. static void orion_timer_init(void *base, enum input_clock_type type) { /* Only init the timer once */ - if (early_init_done) + if (early_init_done) { + printch('6'); // test-only return; + } And the boot log below shows somehow the early_init_done is already true by the time the orion_timer_init is called. Pretty weird, to say the least! --BEGIN LOG-- 3262632626 U-Boot 2023.01-rc4-dirty (Dec 19 2022 - 15:35:26 -0800) Pogoplug V4 SoC: Kirkwood 88F6281_A1 Model: Cloud Engines PogoPlug Series 4 DRAM: 128 MiB 326263262632626Core: 19 devices, 15 uclasses, devicetree: separate NAND: 456 --END LOG-- Thanks, Tony > Thanks, > Tony > > > Thanks, > > Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-20 0:06 ` Tony Dinh @ 2022-12-20 1:36 ` Tony Dinh 2022-12-20 6:20 ` Stefan Roese 0 siblings, 1 reply; 21+ messages in thread From: Tony Dinh @ 2022-12-20 1:36 UTC (permalink / raw) To: Stefan Roese; +Cc: Michael Walle, sjg, u-boot, Pali Rohár Hi Stefan, On Mon, Dec 19, 2022 at 4:06 PM Tony Dinh <mibodhi@gmail.com> wrote: > > Hi Stefan, > > On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > Hi Stefan, > > > > On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <sr@denx.de> wrote: > > > > > > Hi Tony, > > > > > > On 12/19/22 07:17, Stefan Roese wrote: > > > > > > <snip> > > > > > > >> git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 > > > >> Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for > > > >> programming LD0 and LD1 eFuse > > > >> HEAD is now at 37bb396669 timer: orion-timer: Only init timer once > > > >> > > > >> This is where the Pogo V4 was frozen during boot. Among the Kirkwood > > > >> boards that I have and used for testing, it is the only one that has > > > >> CONFIG_BOOTSTAGE=y. > > > > > > > > Thanks for testing and git bi-secting. > > > > > > > >> Should I create a new post for would like to continue this topic here > > > >> in this thread? > > > > > > > > Let me check, if I can find the root cause and this problem quickly. If > > > > not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for > > > > a short while until we've fixed this issue. > > > > > > I fail to spot the problem with this small commit 37bb396669b27a. I can > > > also not reproduce this on my Armada XP board - it uses SPL though, this > > > might make a difference. > > > > > > Could you perhaps apply this attached debug patch and make sure, that > > > you have DEBUG_UART enabled in your Pogo v4 config. And boot into the > > > resulting image. > > > > Here is the kwboot log with DEBUG_UART. Note that number 322322 below > > is part of the log. > > > > 322322 > > > > U-Boot 2023.01-rc3-00057-g9bd3d354a1-dirty (Dec 19 2022 - 01:29:21 -0800) > > Pogoplug V4 > > > > SoC: Kirkwood 88F6281_A1 > > Model: Cloud Engines PogoPlug Series 4 > > DRAM: 128 MiB > > 322322322Core: 19 devices, 15 uclasses, devicetree: separate > > NAND: 4 > > > > Going a bit further with your debug patch, I've added more prints. > > static void orion_timer_init(void *base, enum input_clock_type type) > { > /* Only init the timer once */ > - if (early_init_done) > + if (early_init_done) { > + printch('6'); // test-only > return; > + } > > And the boot log below shows somehow the early_init_done is already > true by the time the orion_timer_init is called. Pretty weird, to say > the least! > > --BEGIN LOG-- > 3262632626 > > U-Boot 2023.01-rc4-dirty (Dec 19 2022 - 15:35:26 -0800) > Pogoplug V4 > > SoC: Kirkwood 88F6281_A1 > Model: Cloud Engines PogoPlug Series 4 > DRAM: 128 MiB > 326263262632626Core: 19 devices, 15 uclasses, devicetree: separate > NAND: 456 > --END LOG-- > I tried this change in drivers/timer/orion-timer.c and it seems to work consistently. -static bool early_init_done __section(".data") = false; +static bool early_init_done = false; I still can't see why it would make a difference. Why does the __section macro not work? does the reallocation timing have anything to do with this variable being of the wrong value? Thanks, Tony > Thanks, > Tony > > > Thanks, > > Tony > > > > > Thanks, > > > Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-20 1:36 ` Tony Dinh @ 2022-12-20 6:20 ` Stefan Roese 2022-12-20 8:07 ` Pali Rohár 0 siblings, 1 reply; 21+ messages in thread From: Stefan Roese @ 2022-12-20 6:20 UTC (permalink / raw) To: Tony Dinh; +Cc: Michael Walle, sjg, u-boot, Pali Rohár Hi Tony, On 12/20/22 02:36, Tony Dinh wrote: > Hi Stefan, > > On Mon, Dec 19, 2022 at 4:06 PM Tony Dinh <mibodhi@gmail.com> wrote: >> >> Hi Stefan, >> >> On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh <mibodhi@gmail.com> wrote: >>> >>> Hi Stefan, >>> >>> On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <sr@denx.de> wrote: >>>> >>>> Hi Tony, >>>> >>>> On 12/19/22 07:17, Stefan Roese wrote: >>>> >>>> <snip> >>>> >>>>>> git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 >>>>>> Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for >>>>>> programming LD0 and LD1 eFuse >>>>>> HEAD is now at 37bb396669 timer: orion-timer: Only init timer once >>>>>> >>>>>> This is where the Pogo V4 was frozen during boot. Among the Kirkwood >>>>>> boards that I have and used for testing, it is the only one that has >>>>>> CONFIG_BOOTSTAGE=y. >>>>> >>>>> Thanks for testing and git bi-secting. >>>>> >>>>>> Should I create a new post for would like to continue this topic here >>>>>> in this thread? >>>>> >>>>> Let me check, if I can find the root cause and this problem quickly. If >>>>> not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for >>>>> a short while until we've fixed this issue. >>>> >>>> I fail to spot the problem with this small commit 37bb396669b27a. I can >>>> also not reproduce this on my Armada XP board - it uses SPL though, this >>>> might make a difference. >>>> >>>> Could you perhaps apply this attached debug patch and make sure, that >>>> you have DEBUG_UART enabled in your Pogo v4 config. And boot into the >>>> resulting image. >>> >>> Here is the kwboot log with DEBUG_UART. Note that number 322322 below >>> is part of the log. >>> >>> 322322 >>> >>> U-Boot 2023.01-rc3-00057-g9bd3d354a1-dirty (Dec 19 2022 - 01:29:21 -0800) >>> Pogoplug V4 >>> >>> SoC: Kirkwood 88F6281_A1 >>> Model: Cloud Engines PogoPlug Series 4 >>> DRAM: 128 MiB >>> 322322322Core: 19 devices, 15 uclasses, devicetree: separate >>> NAND: 4 >>> >> >> Going a bit further with your debug patch, I've added more prints. >> >> static void orion_timer_init(void *base, enum input_clock_type type) >> { >> /* Only init the timer once */ >> - if (early_init_done) >> + if (early_init_done) { >> + printch('6'); // test-only >> return; >> + } >> >> And the boot log below shows somehow the early_init_done is already >> true by the time the orion_timer_init is called. Pretty weird, to say >> the least! >> >> --BEGIN LOG-- >> 3262632626 >> >> U-Boot 2023.01-rc4-dirty (Dec 19 2022 - 15:35:26 -0800) >> Pogoplug V4 >> >> SoC: Kirkwood 88F6281_A1 >> Model: Cloud Engines PogoPlug Series 4 >> DRAM: 128 MiB >> 326263262632626Core: 19 devices, 15 uclasses, devicetree: separate >> NAND: 456 >> --END LOG-- >> > > I tried this change in drivers/timer/orion-timer.c and it seems to > work consistently. > > -static bool early_init_done __section(".data") = false; > +static bool early_init_done = false; > > I still can't see why it would make a difference. Why does the > __section macro not work? does the reallocation timing have anything > to do with this variable being of the wrong value? Hmmm, so we might have a problem with memory being overwritten? You should perhaps where the sections (especially data) are located and where the stack etc is located. I suggest to also enable DEBUG in board_f/c.c to see a bit more of the addresses being used. Thanks, Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-20 6:20 ` Stefan Roese @ 2022-12-20 8:07 ` Pali Rohár 2022-12-21 9:29 ` Stefan Roese 0 siblings, 1 reply; 21+ messages in thread From: Pali Rohár @ 2022-12-20 8:07 UTC (permalink / raw) To: Stefan Roese; +Cc: Tony Dinh, Michael Walle, sjg, u-boot On Tuesday 20 December 2022 07:20:15 Stefan Roese wrote: > Hi Tony, > > On 12/20/22 02:36, Tony Dinh wrote: > > Hi Stefan, > > > > On Mon, Dec 19, 2022 at 4:06 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > > Hi Stefan, > > > > > > On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > > > > Hi Stefan, > > > > > > > > On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <sr@denx.de> wrote: > > > > > > > > > > Hi Tony, > > > > > > > > > > On 12/19/22 07:17, Stefan Roese wrote: > > > > > > > > > > <snip> > > > > > > > > > > > > git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 > > > > > > > Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for > > > > > > > programming LD0 and LD1 eFuse > > > > > > > HEAD is now at 37bb396669 timer: orion-timer: Only init timer once > > > > > > > > > > > > > > This is where the Pogo V4 was frozen during boot. Among the Kirkwood > > > > > > > boards that I have and used for testing, it is the only one that has > > > > > > > CONFIG_BOOTSTAGE=y. > > > > > > > > > > > > Thanks for testing and git bi-secting. > > > > > > > > > > > > > Should I create a new post for would like to continue this topic here > > > > > > > in this thread? > > > > > > > > > > > > Let me check, if I can find the root cause and this problem quickly. If > > > > > > not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for > > > > > > a short while until we've fixed this issue. > > > > > > > > > > I fail to spot the problem with this small commit 37bb396669b27a. I can > > > > > also not reproduce this on my Armada XP board - it uses SPL though, this > > > > > might make a difference. > > > > > > > > > > Could you perhaps apply this attached debug patch and make sure, that > > > > > you have DEBUG_UART enabled in your Pogo v4 config. And boot into the > > > > > resulting image. > > > > > > > > Here is the kwboot log with DEBUG_UART. Note that number 322322 below > > > > is part of the log. > > > > > > > > 322322 > > > > > > > > U-Boot 2023.01-rc3-00057-g9bd3d354a1-dirty (Dec 19 2022 - 01:29:21 -0800) > > > > Pogoplug V4 > > > > > > > > SoC: Kirkwood 88F6281_A1 > > > > Model: Cloud Engines PogoPlug Series 4 > > > > DRAM: 128 MiB > > > > 322322322Core: 19 devices, 15 uclasses, devicetree: separate > > > > NAND: 4 > > > > > > > > > > Going a bit further with your debug patch, I've added more prints. > > > > > > static void orion_timer_init(void *base, enum input_clock_type type) > > > { > > > /* Only init the timer once */ > > > - if (early_init_done) > > > + if (early_init_done) { > > > + printch('6'); // test-only > > > return; > > > + } > > > > > > And the boot log below shows somehow the early_init_done is already > > > true by the time the orion_timer_init is called. Pretty weird, to say > > > the least! > > > > > > --BEGIN LOG-- > > > 3262632626 > > > > > > U-Boot 2023.01-rc4-dirty (Dec 19 2022 - 15:35:26 -0800) > > > Pogoplug V4 > > > > > > SoC: Kirkwood 88F6281_A1 > > > Model: Cloud Engines PogoPlug Series 4 > > > DRAM: 128 MiB > > > 326263262632626Core: 19 devices, 15 uclasses, devicetree: separate > > > NAND: 456 > > > --END LOG-- > > > > > > > I tried this change in drivers/timer/orion-timer.c and it seems to > > work consistently. > > > > -static bool early_init_done __section(".data") = false; > > +static bool early_init_done = false; > > > > I still can't see why it would make a difference. Why does the > > __section macro not work? does the reallocation timing have anything > > to do with this variable being of the wrong value? > > Hmmm, so we might have a problem with memory being overwritten? You > should perhaps where the sections (especially data) are located and > where the stack etc is located. I suggest to also enable DEBUG in > board_f/c.c to see a bit more of the addresses being used. > > Thanks, > Stefan Maybe similar issue as with mbus or atsha? https://lore.kernel.org/u-boot/20220810124609.5765-1-pali@kernel.org/ https://lore.kernel.org/u-boot/20220408143015.23163-2-pali@kernel.org/ static variables do not work correctly _before_ u-boot relocation. You should avoid usage global OR static variables in code which may be called before relocation. And on some boards are all global, static and bss variables read-only (those which use execute-in-place, e.g. ppc flash). ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-20 8:07 ` Pali Rohár @ 2022-12-21 9:29 ` Stefan Roese 2022-12-21 21:35 ` Tony Dinh 0 siblings, 1 reply; 21+ messages in thread From: Stefan Roese @ 2022-12-21 9:29 UTC (permalink / raw) To: Pali Rohár; +Cc: Tony Dinh, Michael Walle, sjg, u-boot Hi Pali, On 12/20/22 09:07, Pali Rohár wrote: > On Tuesday 20 December 2022 07:20:15 Stefan Roese wrote: >> Hi Tony, >> >> On 12/20/22 02:36, Tony Dinh wrote: >>> Hi Stefan, >>> >>> On Mon, Dec 19, 2022 at 4:06 PM Tony Dinh <mibodhi@gmail.com> wrote: >>>> >>>> Hi Stefan, >>>> >>>> On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh <mibodhi@gmail.com> wrote: >>>>> >>>>> Hi Stefan, >>>>> >>>>> On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <sr@denx.de> wrote: >>>>>> >>>>>> Hi Tony, >>>>>> >>>>>> On 12/19/22 07:17, Stefan Roese wrote: >>>>>> >>>>>> <snip> >>>>>> >>>>>>>> git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 >>>>>>>> Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for >>>>>>>> programming LD0 and LD1 eFuse >>>>>>>> HEAD is now at 37bb396669 timer: orion-timer: Only init timer once >>>>>>>> >>>>>>>> This is where the Pogo V4 was frozen during boot. Among the Kirkwood >>>>>>>> boards that I have and used for testing, it is the only one that has >>>>>>>> CONFIG_BOOTSTAGE=y. >>>>>>> >>>>>>> Thanks for testing and git bi-secting. >>>>>>> >>>>>>>> Should I create a new post for would like to continue this topic here >>>>>>>> in this thread? >>>>>>> >>>>>>> Let me check, if I can find the root cause and this problem quickly. If >>>>>>> not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for >>>>>>> a short while until we've fixed this issue. >>>>>> >>>>>> I fail to spot the problem with this small commit 37bb396669b27a. I can >>>>>> also not reproduce this on my Armada XP board - it uses SPL though, this >>>>>> might make a difference. >>>>>> >>>>>> Could you perhaps apply this attached debug patch and make sure, that >>>>>> you have DEBUG_UART enabled in your Pogo v4 config. And boot into the >>>>>> resulting image. >>>>> >>>>> Here is the kwboot log with DEBUG_UART. Note that number 322322 below >>>>> is part of the log. >>>>> >>>>> 322322 >>>>> >>>>> U-Boot 2023.01-rc3-00057-g9bd3d354a1-dirty (Dec 19 2022 - 01:29:21 -0800) >>>>> Pogoplug V4 >>>>> >>>>> SoC: Kirkwood 88F6281_A1 >>>>> Model: Cloud Engines PogoPlug Series 4 >>>>> DRAM: 128 MiB >>>>> 322322322Core: 19 devices, 15 uclasses, devicetree: separate >>>>> NAND: 4 >>>>> >>>> >>>> Going a bit further with your debug patch, I've added more prints. >>>> >>>> static void orion_timer_init(void *base, enum input_clock_type type) >>>> { >>>> /* Only init the timer once */ >>>> - if (early_init_done) >>>> + if (early_init_done) { >>>> + printch('6'); // test-only >>>> return; >>>> + } >>>> >>>> And the boot log below shows somehow the early_init_done is already >>>> true by the time the orion_timer_init is called. Pretty weird, to say >>>> the least! >>>> >>>> --BEGIN LOG-- >>>> 3262632626 >>>> >>>> U-Boot 2023.01-rc4-dirty (Dec 19 2022 - 15:35:26 -0800) >>>> Pogoplug V4 >>>> >>>> SoC: Kirkwood 88F6281_A1 >>>> Model: Cloud Engines PogoPlug Series 4 >>>> DRAM: 128 MiB >>>> 326263262632626Core: 19 devices, 15 uclasses, devicetree: separate >>>> NAND: 456 >>>> --END LOG-- >>>> >>> >>> I tried this change in drivers/timer/orion-timer.c and it seems to >>> work consistently. >>> >>> -static bool early_init_done __section(".data") = false; >>> +static bool early_init_done = false; >>> >>> I still can't see why it would make a difference. Why does the >>> __section macro not work? does the reallocation timing have anything >>> to do with this variable being of the wrong value? >> >> Hmmm, so we might have a problem with memory being overwritten? You >> should perhaps where the sections (especially data) are located and >> where the stack etc is located. I suggest to also enable DEBUG in >> board_f/c.c to see a bit more of the addresses being used. >> >> Thanks, >> Stefan > > Maybe similar issue as with mbus or atsha? > https://lore.kernel.org/u-boot/20220810124609.5765-1-pali@kernel.org/ > https://lore.kernel.org/u-boot/20220408143015.23163-2-pali@kernel.org/ > > static variables do not work correctly _before_ u-boot relocation. You > should avoid usage global OR static variables in code which may be > called before relocation. And on some boards are all global, static and > bss variables read-only (those which use execute-in-place, e.g. ppc > flash). Thanks for the input. Frankly, I was always a bit hesitant when using early static variables. Also with moving them into the data segment. Even though this seems to work on some platforms AFAICT. I've prepared a patch getting rid of this variable by introducing a function instead. Tested successfully on my Armada XP platform. Tony, could you (and perhaps others as well?) test with this new patch, if everything still works as expected? Thanks, Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-21 9:29 ` Stefan Roese @ 2022-12-21 21:35 ` Tony Dinh 0 siblings, 0 replies; 21+ messages in thread From: Tony Dinh @ 2022-12-21 21:35 UTC (permalink / raw) To: Stefan Roese; +Cc: Pali Rohár, Michael Walle, sjg, u-boot Hi Stefan, On Wed, Dec 21, 2022 at 1:29 AM Stefan Roese <sr@denx.de> wrote: > > Hi Pali, > > On 12/20/22 09:07, Pali Rohár wrote: > > On Tuesday 20 December 2022 07:20:15 Stefan Roese wrote: > >> Hi Tony, > >> > >> On 12/20/22 02:36, Tony Dinh wrote: > >>> Hi Stefan, > >>> > >>> On Mon, Dec 19, 2022 at 4:06 PM Tony Dinh <mibodhi@gmail.com> wrote: > >>>> > >>>> Hi Stefan, > >>>> > >>>> On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh <mibodhi@gmail.com> wrote: > >>>>> > >>>>> Hi Stefan, > >>>>> > >>>>> On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <sr@denx.de> wrote: > >>>>>> > >>>>>> Hi Tony, > >>>>>> > >>>>>> On 12/19/22 07:17, Stefan Roese wrote: > >>>>>> > >>>>>> <snip> > >>>>>> > >>>>>>>> git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 > >>>>>>>> Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for > >>>>>>>> programming LD0 and LD1 eFuse > >>>>>>>> HEAD is now at 37bb396669 timer: orion-timer: Only init timer once > >>>>>>>> > >>>>>>>> This is where the Pogo V4 was frozen during boot. Among the Kirkwood > >>>>>>>> boards that I have and used for testing, it is the only one that has > >>>>>>>> CONFIG_BOOTSTAGE=y. > >>>>>>> > >>>>>>> Thanks for testing and git bi-secting. > >>>>>>> > >>>>>>>> Should I create a new post for would like to continue this topic here > >>>>>>>> in this thread? > >>>>>>> > >>>>>>> Let me check, if I can find the root cause and this problem quickly. If > >>>>>>> not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for > >>>>>>> a short while until we've fixed this issue. > >>>>>> > >>>>>> I fail to spot the problem with this small commit 37bb396669b27a. I can > >>>>>> also not reproduce this on my Armada XP board - it uses SPL though, this > >>>>>> might make a difference. > >>>>>> > >>>>>> Could you perhaps apply this attached debug patch and make sure, that > >>>>>> you have DEBUG_UART enabled in your Pogo v4 config. And boot into the > >>>>>> resulting image. > >>>>> > >>>>> Here is the kwboot log with DEBUG_UART. Note that number 322322 below > >>>>> is part of the log. > >>>>> > >>>>> 322322 > >>>>> > >>>>> U-Boot 2023.01-rc3-00057-g9bd3d354a1-dirty (Dec 19 2022 - 01:29:21 -0800) > >>>>> Pogoplug V4 > >>>>> > >>>>> SoC: Kirkwood 88F6281_A1 > >>>>> Model: Cloud Engines PogoPlug Series 4 > >>>>> DRAM: 128 MiB > >>>>> 322322322Core: 19 devices, 15 uclasses, devicetree: separate > >>>>> NAND: 4 > >>>>> > >>>> > >>>> Going a bit further with your debug patch, I've added more prints. > >>>> > >>>> static void orion_timer_init(void *base, enum input_clock_type type) > >>>> { > >>>> /* Only init the timer once */ > >>>> - if (early_init_done) > >>>> + if (early_init_done) { > >>>> + printch('6'); // test-only > >>>> return; > >>>> + } > >>>> > >>>> And the boot log below shows somehow the early_init_done is already > >>>> true by the time the orion_timer_init is called. Pretty weird, to say > >>>> the least! > >>>> > >>>> --BEGIN LOG-- > >>>> 3262632626 > >>>> > >>>> U-Boot 2023.01-rc4-dirty (Dec 19 2022 - 15:35:26 -0800) > >>>> Pogoplug V4 > >>>> > >>>> SoC: Kirkwood 88F6281_A1 > >>>> Model: Cloud Engines PogoPlug Series 4 > >>>> DRAM: 128 MiB > >>>> 326263262632626Core: 19 devices, 15 uclasses, devicetree: separate > >>>> NAND: 456 > >>>> --END LOG-- > >>>> > >>> > >>> I tried this change in drivers/timer/orion-timer.c and it seems to > >>> work consistently. > >>> > >>> -static bool early_init_done __section(".data") = false; > >>> +static bool early_init_done = false; > >>> > >>> I still can't see why it would make a difference. Why does the > >>> __section macro not work? does the reallocation timing have anything > >>> to do with this variable being of the wrong value? > >> > >> Hmmm, so we might have a problem with memory being overwritten? You > >> should perhaps where the sections (especially data) are located and > >> where the stack etc is located. I suggest to also enable DEBUG in > >> board_f/c.c to see a bit more of the addresses being used. > >> > >> Thanks, > >> Stefan > > > > Maybe similar issue as with mbus or atsha? > > https://lore.kernel.org/u-boot/20220810124609.5765-1-pali@kernel.org/ > > https://lore.kernel.org/u-boot/20220408143015.23163-2-pali@kernel.org/ > > > > static variables do not work correctly _before_ u-boot relocation. You > > should avoid usage global OR static variables in code which may be > > called before relocation. And on some boards are all global, static and > > bss variables read-only (those which use execute-in-place, e.g. ppc > > flash). > > Thanks for the input. Frankly, I was always a bit hesitant when using > early static variables. Also with moving them into the data segment. > Even though this seems to work on some platforms AFAICT. > > I've prepared a patch getting rid of this variable by introducing a > function instead. Tested successfully on my Armada XP platform. > > Tony, could you (and perhaps others as well?) test with this new patch, > if everything still works as expected? Sure, I'll be glad to. Thanks, Tony > > Thanks, > Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Converting to DM SERIAL for Kirkwood boards 2022-12-19 21:22 ` Tony Dinh 2022-12-20 0:06 ` Tony Dinh @ 2022-12-20 6:10 ` Stefan Roese 1 sibling, 0 replies; 21+ messages in thread From: Stefan Roese @ 2022-12-20 6:10 UTC (permalink / raw) To: Tony Dinh; +Cc: Michael Walle, sjg, u-boot, Pali Rohár Hi Tony, On 12/19/22 22:22, Tony Dinh wrote: > Hi Stefan, > > On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese <sr@denx.de> wrote: >> >> Hi Tony, >> >> On 12/19/22 07:17, Stefan Roese wrote: >> >> <snip> >> >>>> git checkout 37bb396669b27aa62fe8bc5eeb6bfde92e09c2d3 >>>> Previous HEAD position was 3b44b3fdf2 arm: mvebu: Add support for >>>> programming LD0 and LD1 eFuse >>>> HEAD is now at 37bb396669 timer: orion-timer: Only init timer once >>>> >>>> This is where the Pogo V4 was frozen during boot. Among the Kirkwood >>>> boards that I have and used for testing, it is the only one that has >>>> CONFIG_BOOTSTAGE=y. >>> >>> Thanks for testing and git bi-secting. >>> >>>> Should I create a new post for would like to continue this topic here >>>> in this thread? >>> >>> Let me check, if I can find the root cause and this problem quickly. If >>> not, then we should probably disable CONFIG_BOOTSTAGE on the Pogo v4 for >>> a short while until we've fixed this issue. >> >> I fail to spot the problem with this small commit 37bb396669b27a. I can >> also not reproduce this on my Armada XP board - it uses SPL though, this >> might make a difference. >> >> Could you perhaps apply this attached debug patch and make sure, that >> you have DEBUG_UART enabled in your Pogo v4 config. And boot into the >> resulting image. > > Here is the kwboot log with DEBUG_UART. Note that number 322322 below > is part of the log. > > 322322 > > U-Boot 2023.01-rc3-00057-g9bd3d354a1-dirty (Dec 19 2022 - 01:29:21 -0800) > Pogoplug V4 > > SoC: Kirkwood 88F6281_A1 > Model: Cloud Engines PogoPlug Series 4 > DRAM: 128 MiB > 322322322Core: 19 devices, 15 uclasses, devicetree: separate > NAND: 4 Ah, I totally forgot that this board did not hang before the first UART output but later after the NAND stage. I added these UART debug infos to debug an early boot problem before any normal UART output. Thanks, Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2022-12-23 6:35 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAJaLiFxnRPEPv83wasDBeuxzV2o39qF=hvSQvkft14irmH=L9A@mail.gmail.com>
2022-12-09 3:55 ` Converting to DM SERIAL for Kirkwood boards Tony Dinh
2022-12-09 6:56 ` Stefan Roese
2022-12-09 20:45 ` Tony Dinh
2022-12-12 9:03 ` Michael Walle
2022-12-13 1:18 ` Tony Dinh
2022-12-16 2:42 ` Tony Dinh
2022-12-16 6:29 ` Stefan Roese
2022-12-23 6:34 ` Tony Dinh
2022-12-16 7:56 ` Pali Rohár
2022-12-16 21:49 ` Tony Dinh
2022-12-19 0:17 ` Tony Dinh
2022-12-19 6:17 ` Stefan Roese
2022-12-19 7:29 ` Stefan Roese
2022-12-19 21:22 ` Tony Dinh
2022-12-20 0:06 ` Tony Dinh
2022-12-20 1:36 ` Tony Dinh
2022-12-20 6:20 ` Stefan Roese
2022-12-20 8:07 ` Pali Rohár
2022-12-21 9:29 ` Stefan Roese
2022-12-21 21:35 ` Tony Dinh
2022-12-20 6:10 ` Stefan Roese
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox