Re: Converting to DM SERIAL for Kirkwood boards
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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).
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
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
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
participants (4)
-
Michael Walle -
Pali Rohár -
Stefan Roese -
Tony Dinh