All of lore.kernel.org
 help / color / mirror / Atom feed
* 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  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-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
* 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-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
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 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.