Re: [PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
Hi all,
On Thu, Feb 2, 2023 at 10:04 AM Pali Rohár wrote:
>
> On Wednesday 01 February 2023 13:13:16 Tony Dinh wrote:
> > Hi all,
> >
> > On Wed, Feb 1, 2023 at 11:05 AM Pali Rohár wrote:
> > >
> > > On Wednesday 01 February 2023 09:17:15 Michael Walle wrote:
> > > > > > > When DM_SERIAL is enabled, the device-tree property dm-pre-reloc
> > > > > > > is
> > > > > > > required to boot over UART with kwboot. Enable this in a Kirkwood
> > > > > > > common u-boot dtsi.
> > > > > >
> > > > > > My (dev) board unfortunately, have a bootloader which can't boot
> > > > > > over
> > > > > > serial.
> > > > >
> > > > > This is feature of Marvell BootROM and does not require any special
> > > > > from
> > > > > Bootloader. So you should be able to boot over UART (if you have
> > > > > accessible pins).
> > > >
> > > > I know, but there are known versions ob the bootrom where uart boot
> > > > isn't supported (correctly).
> > >
> > > I heard about it... maybe it is a bug in client software (kwboot)? I do
> > > not have such board if you are interested in it I could try to send some
> > > details how to debug it.
> >
> > The Kirkwood SoCs came with different BootROM versions. Version 1.1
> > cannot be booted over UART, but version 1.2 can. I think there must
> > be a bug in the BootROM 1.1. The older Kirkwood such as Sheevaplug,
> > Dockstar, iConnect boards come with BootROM 1.1. Later version of
> > Sheevaplug, GoFlex Home, GoFlex Net, Dreamplug, Pogoplug V4, Zyxel
> > NSA310S, NSA320, NSA325 come with BootROM 1.2. So even though it is
> > the same SoC, eg. 6281, they are actually produced at a different time
> > and have different BootROM versions.
>
> There are always multiple revisions of the same SoC. So it is possible
> that something was broken on first revision of 88F6281 and in next
> revision was updated BootROM with some fixes. Revision is written on
> package label and for Armada SoCs it is available also in some register
> (not sure about Kirkwood). It looks like that there is at least revision
> Z0 and revision A0 of some Kirkwood SoC.
>
> If there is a bug in first revisions then it should be documented in
> some Kirkwood Errata document. Unfortunately I have never seen it, it is
> not public, so I have no idea. In any case, if somebody has access to
> Marvell documents, interesting are these document numbers:
>
> * MV-S105223-001 - Differences Between the 88F6192, and 88F6281 Stepping Z0
> and A0
> * MV-S501081-00 - 88F6180, 88F6192, and 88F6281 Functional Errata, Interface
> Guidelines, and Restrictions
> * MV-S501157-U0 - 88F6180, 88F6190, 88F6192, and 88F6281 Functional Errata,
> Interface Guidelines, and Restrictions
>
> One of the option how to investigate or debug this issue without
> documentation is to dump both BootROM versions (1.1, 1.2) and compare
> them. Either there is different UART protocol for booting (which needs
> to be implemented) or UART protocol is buggy and needs some workaround
> or it is completely broken and does not work.
Here is an excerpt from doc/develop/driver-model/serial-howto.rst.
Quote ===
Here are some things you might need to consider:
1. The serial driver itself needs to be present before relocation, so that the
U-Boot banner appears. Make sure it has a u-boot,dm-pre-reloc tag
in the device
tree, so that the serial driver is bound when U-Boot starts.
For example, on iMX8::
lpuart3: serial@5a09 {
compatible = "fsl,imx8qm-lpuart";
...
};
put this in your xxx-u-boot.dtsi file::
&lpuart3 {
u-boot,dm-pre-proper;
};
=== Unquote
So it looks like my understanding was correct. The serial driver is
not bound if there is no u-boot,dm-pre-reloc tag. And does it sound
like it is required for all targets because of this reason?
Thanks,
Tony
[PATCH] arm: kirkwood: sheevaplug: reduce u-boot image size
Sheevaplug board has 512K CONFIG_BOARD_SIZE_LIMIT. Recently, DM_SERIAL has pushed the image size a few hundred bytes over that limit. So explicitly deselect some configs that are unrelated to this board (and gain back a bit over 2K). Signed-off-by: Tony Dinh --- configs/sheevaplug_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/sheevaplug_defconfig b/configs/sheevaplug_defconfig index cb38a3fbd5..40ab16dfa0 100644 --- a/configs/sheevaplug_defconfig +++ b/configs/sheevaplug_defconfig @@ -26,6 +26,11 @@ CONFIG_USE_PREBOOT=y CONFIG_HUSH_PARSER=y CONFIG_SYS_MAXARGS=32 CONFIG_CMD_BOOTZ=y +# CONFIG_BOOTM_PLAN9 is not set +# CONFIG_BOOTM_RTEMS is not set +# CONFIG_BOOTM_VXWORKS is not set +# CONFIG_CMD_IMI is not set +# CONFIG_CMD_XIMG is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_MMC=y CONFIG_CMD_NAND=y -- 2.30.2
Re: [PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
Added Simon to the discussion. On Wed, Feb 1, 2023 at 1:13 PM Tony Dinh wrote: > > Hi all, > > On Wed, Feb 1, 2023 at 11:05 AM Pali Rohár wrote: > > > > On Wednesday 01 February 2023 09:17:15 Michael Walle wrote: > > > > > > When DM_SERIAL is enabled, the device-tree property dm-pre-reloc is > > > > > > required to boot over UART with kwboot. Enable this in a Kirkwood > > > > > > common u-boot dtsi. > > > > > > > > > > My (dev) board unfortunately, have a bootloader which can't boot over > > > > > serial. > > > > > > > > This is feature of Marvell BootROM and does not require any special from > > > > Bootloader. So you should be able to boot over UART (if you have > > > > accessible pins). > > > > > > I know, but there are known versions ob the bootrom where uart boot > > > isn't supported (correctly). > > > > I heard about it... maybe it is a bug in client software (kwboot)? I do > > not have such board if you are interested in it I could try to send some > > details how to debug it. > > The Kirkwood SoCs came with different BootROM versions. Version 1.1 > cannot be booted over UART, but version 1.2 can. I think there must > be a bug in the BootROM 1.1. The older Kirkwood such as Sheevaplug, > Dockstar, iConnect boards come with BootROM 1.1. Later version of > Sheevaplug, GoFlex Home, GoFlex Net, Dreamplug, Pogoplug V4, Zyxel > NSA310S, NSA320, NSA325 come with BootROM 1.2. So even though it is > the same SoC, eg. 6281, they are actually produced at a different time > and have different BootROM versions. > > When I test new u-boot images for boards such as Dockstar or iConnect, > I run kwboot with the GoFlex Home/Net. And they boot fine to a point > that allows me to see that the image is good enough. So in the > development phase, most if not all Kirkwood u-boot images can be > booted over UART. Some with real boards, some with surrogates. > > > > I also have another board which can boot > > > over uart. But thats in daily use ;) > > > > > > > > Could you elaborate that a bit more? Why is this required for > > > > > uart boot? kwboot will talk with the bootrom why does u-boot need > > > > > anything? Or will there just be no output until the uart is > > > > > initialized? > > > > > > > > On mvebu/armada boards this dm-pre-reloc is required to ensure that DT > > > > nodes are present in SPL DTB file. Otherwise build process drop all > > > > non-pre-realoc nodes from SPL version of DTB file. And because SPL use > > > > DM serial, it is required to have uart DT nodes in DTB file. Btw, same > > > > problem is with SPI in SPL. > > > > > > > > But... kirkwood does not use SPL, so I do not know what is reason for > > > > this here. > > > > > > Yes thats what puzzled me, too. > > When u-boot,dm-pre-reloc is not specified in the uart0 DTS node, after > the image was transferred by kwboot, the serial console is silent and > the board is frozen. > > If I understand correctly, it is because before u-boot relocation, if > DM serial is enabled, the serial uclass is present, but it has not > been initialized (I think it is created but not "bind(?)" ). The > dm-preloc property works because it explicitly tells DM to fully > initialize the uclass before relocation. That was just my observation > about DM in general, devices do not get fully initialized until the > first use. So I tried the u-boot,dm-pre-reloc and it works. If my > assumption is incorrect, perhaps somebody can look at the serial > uclass and see if there is a different type of issue there. > > Thanks, > Tony > > > > > > > > > > > > > > > > Signed-off-by: Tony Dinh > > > > > > --- > > > > > > > > > > > > arch/arm/dts/kirkwood-u-boot.dtsi | 7 +++ > > > > > > 1 file changed, 7 insertions(+) > > > > > > create mode 100644 arch/arm/dts/kirkwood-u-boot.dtsi > > > > > > > > > > Is this new? AFAIK only -u-boot.dtsi is included > > > > > automatically. > > > > > > > > It is not new, Tom wrote about it quite ago: > > > > https://lore.kernel.org/u-boot/20220802121113.GG1146598@bill-the-cat/ > > > > > > Thats relatively new for someone not following the u-boot > > > development that closely ;) Thanks for the pointer. > > > > > > -michael > > >
[PATCH v3] arm: mvebu: Add support for Thecus N2350 (Armada 385) board
Thecus N2350 is a NAS based on Marvell Armada 385 SoC.
Specification:
- Processor: Marvel MV88F6820 Dual Core at 1GHz
- 1 GiB DDR4 RAM
- 4MB Macronix mx25l3205d SPI flash
- 512MB Hynix H27U4G8F2DTR-BC NAND flash
- I2C
- 2x USB 3.0
- 1x GBE LAN port (PHY: Marvell 88E1510)
- 2x SATA (hot swap slots)
- 3x buttons
- 10x LEDS
- serial console
Signed-off-by: Tony Dinh
---
Changes in v3:
- Add missing DTS file path in MAINTAINERS file
- Remove "common.h" in board file
- Remove CFG_I2C_MVTWSI_BASE0 in include header file
- Cleanup unecessary comments in include header file
Changes in v2:
- Use node pointers already defined from armada-38x.dtsi in this board DTS
- Remove extra compatible attributes in this board DTS
- Remove unnecessary armada-385-thecus-n2350-u-boot.dtsi
- Remove unnecessary check_board() function in board file
- Remove unnecessary "default false" for DDR4 in arch/arm/mach-mvebu/Kconfig
- Use "rootfs" as partition name for NAND partition
- Various DTS naming convention correction
arch/arm/dts/Makefile| 1 +
arch/arm/dts/armada-385-thecus-n2350.dts | 446 +++
arch/arm/mach-mvebu/Kconfig | 11 +
board/thecus/n2350/MAINTAINERS | 7 +
board/thecus/n2350/Makefile | 6 +
board/thecus/n2350/n2350.c | 126 +++
configs/n2350_defconfig | 93 +
include/configs/n2350.h | 56 +++
8 files changed, 746 insertions(+)
create mode 100644 arch/arm/dts/armada-385-thecus-n2350.dts
create mode 100644 board/thecus/n2350/MAINTAINERS
create mode 100644 board/thecus/n2350/Makefile
create mode 100644 board/thecus/n2350/n2350.c
create mode 100644 configs/n2350_defconfig
create mode 100644 include/configs/n2350.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 3ecd6a86e9..c5d1825a3b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-385-atl-x530.dtb \
armada-385-atl-x530DP.dtb \
armada-385-db-88f6820-amc.dtb \
+ armada-385-thecus-n2350.dtb \
armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts
b/arch/arm/dts/armada-385-thecus-n2350.dts
new file mode 100644
index 00..fc29c4d25a
--- /dev/null
+++ b/arch/arm/dts/armada-385-thecus-n2350.dts
@@ -0,0 +1,446 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Thecus N2350 board
+ *
+ * Copyright (C) 2018-2023 Tony Dinh
+ * Copyright (C) 2018 Manuel Jung
+ */
+
+/dts-v1/;
+#include
+#include
+#include "armada-385.dtsi"
+
+/ {
+ model = "Thecus N2350";
+ compatible = "thecus,n2350", "marvell,armada385";
+
+ aliases {
+ ethernet0 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x4000>; /* 1GB */
+ };
+
+ soc {
+ ranges = ;
+
+ };
+
+ usb3_0_phy: usb3_0_phy {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <&usb3_0_power>;
+ };
+
+ usb3_1_phy: usb3_1_phy {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <&usb3_1_power>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-0 = <&pmx_power_button &pmx_copy_button
&pmx_reset_button>;
+ pinctrl-names = "default";
+
+ button@1 {
+ label = "Power Button";
+ linux,code = ;
+ gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ button@2 {
+ label = "Copy Button";
+ linux,code = ;
+ gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
+ };
+
+ button@3 {
+ label = "Reset Button";
+ linux,code = ;
+ gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&pmx_sata1_white_led
+ &pmx_sata1_red_led
+ &pmx_sata2_white_led
+ &pmx_sata2_red_led
+ &pmx_sys_white_led
+
Re: [PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
Hi all, On Wed, Feb 1, 2023 at 11:05 AM Pali Rohár wrote: > > On Wednesday 01 February 2023 09:17:15 Michael Walle wrote: > > > > > When DM_SERIAL is enabled, the device-tree property dm-pre-reloc is > > > > > required to boot over UART with kwboot. Enable this in a Kirkwood > > > > > common u-boot dtsi. > > > > > > > > My (dev) board unfortunately, have a bootloader which can't boot over > > > > serial. > > > > > > This is feature of Marvell BootROM and does not require any special from > > > Bootloader. So you should be able to boot over UART (if you have > > > accessible pins). > > > > I know, but there are known versions ob the bootrom where uart boot > > isn't supported (correctly). > > I heard about it... maybe it is a bug in client software (kwboot)? I do > not have such board if you are interested in it I could try to send some > details how to debug it. The Kirkwood SoCs came with different BootROM versions. Version 1.1 cannot be booted over UART, but version 1.2 can. I think there must be a bug in the BootROM 1.1. The older Kirkwood such as Sheevaplug, Dockstar, iConnect boards come with BootROM 1.1. Later version of Sheevaplug, GoFlex Home, GoFlex Net, Dreamplug, Pogoplug V4, Zyxel NSA310S, NSA320, NSA325 come with BootROM 1.2. So even though it is the same SoC, eg. 6281, they are actually produced at a different time and have different BootROM versions. When I test new u-boot images for boards such as Dockstar or iConnect, I run kwboot with the GoFlex Home/Net. And they boot fine to a point that allows me to see that the image is good enough. So in the development phase, most if not all Kirkwood u-boot images can be booted over UART. Some with real boards, some with surrogates. > > I also have another board which can boot > > over uart. But thats in daily use ;) > > > > > > Could you elaborate that a bit more? Why is this required for > > > > uart boot? kwboot will talk with the bootrom why does u-boot need > > > > anything? Or will there just be no output until the uart is > > > > initialized? > > > > > > On mvebu/armada boards this dm-pre-reloc is required to ensure that DT > > > nodes are present in SPL DTB file. Otherwise build process drop all > > > non-pre-realoc nodes from SPL version of DTB file. And because SPL use > > > DM serial, it is required to have uart DT nodes in DTB file. Btw, same > > > problem is with SPI in SPL. > > > > > > But... kirkwood does not use SPL, so I do not know what is reason for > > > this here. > > > > Yes thats what puzzled me, too. When u-boot,dm-pre-reloc is not specified in the uart0 DTS node, after the image was transferred by kwboot, the serial console is silent and the board is frozen. If I understand correctly, it is because before u-boot relocation, if DM serial is enabled, the serial uclass is present, but it has not been initialized (I think it is created but not "bind(?)" ). The dm-preloc property works because it explicitly tells DM to fully initialize the uclass before relocation. That was just my observation about DM in general, devices do not get fully initialized until the first use. So I tried the u-boot,dm-pre-reloc and it works. If my assumption is incorrect, perhaps somebody can look at the serial uclass and see if there is a different type of issue there. Thanks, Tony > > > > > > > > > > > > Signed-off-by: Tony Dinh > > > > > --- > > > > > > > > > > arch/arm/dts/kirkwood-u-boot.dtsi | 7 +++ > > > > > 1 file changed, 7 insertions(+) > > > > > create mode 100644 arch/arm/dts/kirkwood-u-boot.dtsi > > > > > > > > Is this new? AFAIK only -u-boot.dtsi is included > > > > automatically. > > > > > > It is not new, Tom wrote about it quite ago: > > > https://lore.kernel.org/u-boot/20220802121113.GG1146598@bill-the-cat/ > > > > Thats relatively new for someone not following the u-boot > > development that closely ;) Thanks for the pointer. > > > > -michael > >
Re: [PATCH v2] arm: mvebu: Add support for Thecus N2350 (Armada 385) board
Hi Stefan,
On Tue, Jan 31, 2023 at 10:48 PM Stefan Roese wrote:
>
> Hi Tony,
>
> On 1/31/23 22:22, Tony Dinh wrote:
> > Thecus N2350 is a NAS based on Marvell Armada 385 SoC.
> >
> > Specification:
> >
> > - Processor: Marvel MV88F6820 Dual Core at 1GHz
> > - 1 GiB DDR4 RAM
> > - 4MB Macronix mx25l3205d SPI flash
> > - 512MB Hynix H27U4G8F2DTR-BC NAND flash
> > - I2C
> > - 2x USB 3.0
> > - 1x GBE LAN port (PHY: Marvell 88E1510)
> > - 2x SATA (hot swap slots)
> > - 3x buttons
> > - 10x LEDS
> > - serial console
> >
> > Signed-off-by: Tony Dinh
> > ---
> >
> > Changes in v2:
> > - Use node pointers already defined from armada-38x.dtsi in this board DTS
> > - Remove extra compatible attributes in this board DTS
> > - Remove unnecessary armada-385-thecus-n2350-u-boot.dtsi
> > - Remove unnecessary check_board() function in board file
> > - Remove unnecessary "default false" for DDR4 in arch/arm/mach-mvebu/Kconfig
> > - Use "rootfs" as partition name for NAND partition
> > - Various DTS naming convention correction
> >
> > arch/arm/dts/Makefile| 1 +
> > arch/arm/dts/armada-385-thecus-n2350.dts | 446 +++
> > arch/arm/mach-mvebu/Kconfig | 11 +
> > board/thecus/n2350/MAINTAINERS | 6 +
> > board/thecus/n2350/Makefile | 6 +
> > board/thecus/n2350/n2350.c | 127 +++
> > configs/n2350_defconfig | 93 +
> > include/configs/n2350.h | 65
> > 8 files changed, 755 insertions(+)
> > create mode 100644 arch/arm/dts/armada-385-thecus-n2350.dts
> > create mode 100644 board/thecus/n2350/MAINTAINERS
> > create mode 100644 board/thecus/n2350/Makefile
> > create mode 100644 board/thecus/n2350/n2350.c
> > create mode 100644 configs/n2350_defconfig
> > create mode 100644 include/configs/n2350.h
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 3ecd6a86e9..c5d1825a3b 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
> > armada-385-atl-x530.dtb \
> > armada-385-atl-x530DP.dtb \
> > armada-385-db-88f6820-amc.dtb \
> > + armada-385-thecus-n2350.dtb \
> > armada-385-turris-omnia.dtb \
> > armada-388-clearfog.dtb \
> > armada-388-gp.dtb \
> > diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts
> > b/arch/arm/dts/armada-385-thecus-n2350.dts
> > new file mode 100644
> > index 00..fc29c4d25a
> > --- /dev/null
> > +++ b/arch/arm/dts/armada-385-thecus-n2350.dts
> > @@ -0,0 +1,446 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Device Tree file for Thecus N2350 board
> > + *
> > + * Copyright (C) 2018-2023 Tony Dinh
> > + * Copyright (C) 2018 Manuel Jung
> > + */
> > +
> > +/dts-v1/;
> > +#include
> > +#include
> > +#include "armada-385.dtsi"
> > +
> > +/ {
> > + model = "Thecus N2350";
> > + compatible = "thecus,n2350", "marvell,armada385";
> > +
> > + aliases {
> > + ethernet0 = ð0;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + memory {
> > + device_type = "memory";
> > + reg = <0x 0x4000>; /* 1GB */
> > + };
> > +
> > + soc {
> > + ranges = > + MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10
> > + MBUS_ID(0x09, 0x19) 0 0xf110 0x1
> > + MBUS_ID(0x09, 0x15) 0 0xf111 0x1
> > + MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
> > +
> > + };
> > +
> > + usb3_0_phy: usb3_0_phy {
> > + compatible = "usb-nop-xceiv";
> > + vcc-supply = <&usb3_0_power>;
> > + };
> > +
> > + usb3_1_phy: usb3_1_phy {
> > + compatible = "usb-nop-xceiv";
> > + vcc-supply = <&usb3_1_power>;
> > + };
> > +
> > + gpio-keys {
> > + compatible = "gpio-k
Re: [PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
Thanks Stefan!
Tony
On Tue, Jan 31, 2023 at 10:30 PM Stefan Roese wrote:
>
> (Added Simon to Cc)
>
> On 2/1/23 02:11, Tony Dinh wrote:
> > When DM_SERIAL is enabled, the device-tree property dm-pre-reloc is
> > required to boot over UART with kwboot. Enable this in a Kirkwood
> > common u-boot dtsi.
> >
> > Signed-off-by: Tony Dinh
>
> Reviewed-by: Stefan Roese
>
> I just wanted to inform you, that Simon is currently busy with migration
> to a new tags. Please see here for more details:
>
> https://lore.kernel.org/u-boot/20230129012652.83432-1-...@chromium.org/
>
> Thanks,
> Stefan
>
> > ---
> >
> > arch/arm/dts/kirkwood-u-boot.dtsi | 7 +++
> > 1 file changed, 7 insertions(+)
> > create mode 100644 arch/arm/dts/kirkwood-u-boot.dtsi
> >
> > diff --git a/arch/arm/dts/kirkwood-u-boot.dtsi
> > b/arch/arm/dts/kirkwood-u-boot.dtsi
> > new file mode 100644
> > index 00..f9e127234c
> > --- /dev/null
> > +++ b/arch/arm/dts/kirkwood-u-boot.dtsi
> > @@ -0,0 +1,7 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2023 Tony Dinh
> > + */
> > +&uart0 {
> > + u-boot,dm-pre-reloc;
> > +};
>
> 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: s...@denx.de
[PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
When DM_SERIAL is enabled, the device-tree property dm-pre-reloc is
required to boot over UART with kwboot. Enable this in a Kirkwood
common u-boot dtsi.
Signed-off-by: Tony Dinh
---
arch/arm/dts/kirkwood-u-boot.dtsi | 7 +++
1 file changed, 7 insertions(+)
create mode 100644 arch/arm/dts/kirkwood-u-boot.dtsi
diff --git a/arch/arm/dts/kirkwood-u-boot.dtsi
b/arch/arm/dts/kirkwood-u-boot.dtsi
new file mode 100644
index 00..f9e127234c
--- /dev/null
+++ b/arch/arm/dts/kirkwood-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Tony Dinh
+ */
+&uart0 {
+ u-boot,dm-pre-reloc;
+};
--
2.30.2
[PATCH] arm: kirkwood: Use CONFIG_SYS_NS16550 with DM_SERIAL for Kirkwood boards
CONFIG_SYS_NS16550 is required when DM_SERIAL is enabled for Kirkwood boards. Signed-off-by: Tony Dinh --- arch/arm/mach-kirkwood/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig index 45cc932636..b19ed2c6b3 100644 --- a/arch/arm/mach-kirkwood/Kconfig +++ b/arch/arm/mach-kirkwood/Kconfig @@ -15,6 +15,7 @@ config SHEEVA_88SV131 config KIRKWOOD_COMMON bool select DM_SERIAL + select SYS_NS16550 config HAS_CUSTOM_SYS_INIT_SP_ADDR bool "Use a custom location for the initial stack pointer address" -- 2.30.2
[PATCH v2] arm: mvebu: Add support for Thecus N2350 (Armada 385) board
Thecus N2350 is a NAS based on Marvell Armada 385 SoC.
Specification:
- Processor: Marvel MV88F6820 Dual Core at 1GHz
- 1 GiB DDR4 RAM
- 4MB Macronix mx25l3205d SPI flash
- 512MB Hynix H27U4G8F2DTR-BC NAND flash
- I2C
- 2x USB 3.0
- 1x GBE LAN port (PHY: Marvell 88E1510)
- 2x SATA (hot swap slots)
- 3x buttons
- 10x LEDS
- serial console
Signed-off-by: Tony Dinh
---
Changes in v2:
- Use node pointers already defined from armada-38x.dtsi in this board DTS
- Remove extra compatible attributes in this board DTS
- Remove unnecessary armada-385-thecus-n2350-u-boot.dtsi
- Remove unnecessary check_board() function in board file
- Remove unnecessary "default false" for DDR4 in arch/arm/mach-mvebu/Kconfig
- Use "rootfs" as partition name for NAND partition
- Various DTS naming convention correction
arch/arm/dts/Makefile| 1 +
arch/arm/dts/armada-385-thecus-n2350.dts | 446 +++
arch/arm/mach-mvebu/Kconfig | 11 +
board/thecus/n2350/MAINTAINERS | 6 +
board/thecus/n2350/Makefile | 6 +
board/thecus/n2350/n2350.c | 127 +++
configs/n2350_defconfig | 93 +
include/configs/n2350.h | 65
8 files changed, 755 insertions(+)
create mode 100644 arch/arm/dts/armada-385-thecus-n2350.dts
create mode 100644 board/thecus/n2350/MAINTAINERS
create mode 100644 board/thecus/n2350/Makefile
create mode 100644 board/thecus/n2350/n2350.c
create mode 100644 configs/n2350_defconfig
create mode 100644 include/configs/n2350.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 3ecd6a86e9..c5d1825a3b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-385-atl-x530.dtb \
armada-385-atl-x530DP.dtb \
armada-385-db-88f6820-amc.dtb \
+ armada-385-thecus-n2350.dtb \
armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts
b/arch/arm/dts/armada-385-thecus-n2350.dts
new file mode 100644
index 00..fc29c4d25a
--- /dev/null
+++ b/arch/arm/dts/armada-385-thecus-n2350.dts
@@ -0,0 +1,446 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Thecus N2350 board
+ *
+ * Copyright (C) 2018-2023 Tony Dinh
+ * Copyright (C) 2018 Manuel Jung
+ */
+
+/dts-v1/;
+#include
+#include
+#include "armada-385.dtsi"
+
+/ {
+ model = "Thecus N2350";
+ compatible = "thecus,n2350", "marvell,armada385";
+
+ aliases {
+ ethernet0 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x4000>; /* 1GB */
+ };
+
+ soc {
+ ranges = ;
+
+ };
+
+ usb3_0_phy: usb3_0_phy {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <&usb3_0_power>;
+ };
+
+ usb3_1_phy: usb3_1_phy {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <&usb3_1_power>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-0 = <&pmx_power_button &pmx_copy_button
&pmx_reset_button>;
+ pinctrl-names = "default";
+
+ button@1 {
+ label = "Power Button";
+ linux,code = ;
+ gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ button@2 {
+ label = "Copy Button";
+ linux,code = ;
+ gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
+ };
+
+ button@3 {
+ label = "Reset Button";
+ linux,code = ;
+ gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&pmx_sata1_white_led
+ &pmx_sata1_red_led
+ &pmx_sata2_white_led
+ &pmx_sata2_red_led
+ &pmx_sys_white_led
+ &pmx_sys_red_led
+ &pmx_pwr_blue_led
+ &pmx_pwr_red_led
+ &pmx_usb_white_led
+
Re: [PATCH] arm: kirkwood: Add nas440 board, Marvell 88SE6121 AHCI
Hi Pali, On Mon, Jan 30, 2023 at 12:11 PM Pali Rohár wrote: > > On Monday 28 March 2022 09:57:41 Hajo Noerenberg wrote: > > Hi Tony, > > > > thank you very much for your help. I will integrate the changes and > > resubmit the patch when Tom's work on CONFIG_RESET_PHY_R is done. If you or > > others have further improvements in the meantime, please let me know. > > Hello! I would like to ask, is there any progress on this? > Or is nas440 board already ready for merging? I have not heard from Hajo since then. Tony > > I wonder if it would be a good idea to submit adding the PCI-ids for the > > 88SE6121 controller (drivers/ata/ahci-pci.c) as a separate patch. The > > controller is not specific to the NAS440, to my knowledge it is also used > > on the Iomega ix4-200d for example. > > > > Thanks, > > Hajo > > > > > > Am 26.03.2022 um 02:33 schrieb Tony Dinh: > > > Hi Hajo, > > > > > > General comments: > > > > > > - You're missing a file in this patch set: arch/arm/mach-kirkwood/Kconfig. > > > - There are numerous style problems. You should run > > > scripts/checkpatch.pl on each file to cleanup. Also look into using > > > patman to create patches, and possibly sending patches too. It takes a > > > bit of getting used to, but patman is very useful. Especially sending > > > patch series and revisions. > > > - Please use the canonical form for nas440_defconfig. > > > make nas440_deconfig > > > make savedefconfig > > > mv defconfig configs/nas440_defconfig > > > > > > - This is a board that is not yet supported in mainline Linux (i.e. > > > there is no legacy dependency). Thus, we don't want to use ATAGS. > > > Remove: > > >>>> +CONFIG_SUPPORT_PASSING_ATAGS=y > > >>>> +CONFIG_CMDLINE_TAG=y > > >>>> +CONFIG_INITRD_TAG=y > > > - This patch will need a revision after Tom's patch is merged to master. > > > See: > > > https://lists.denx.de/pipermail/u-boot/2022-March/478823.html > > > > > > Thanks, > > > Tony > > > > > > On Thu, Mar 24, 2022 at 3:04 PM Tony Dinh wrote: > > >> > > >> Hi Hajo, > > >> > > >> I've added Stefan. > > >> > > >> When you send patches for Kirkwood or other Marvell boards, please > > >> also send it directly to Stefan (Stefan is the maintainer of Marvell > > >> u-boots). > > >> > > >> Tony > > >> > > >> On Thu, Mar 24, 2022 at 3:11 AM Pali Rohár wrote: > > >>> > > >>> Hello! > > >>> > > >>> On Thursday 24 March 2022 10:55:38 Hajo Noerenberg wrote: > > >>>> This adds support for the Seagate Blackarmor NAS440 (4-bay Kirkwood > > >>>> NAS box). > > >>>> > > >>>> Does it make sense to include support for a 10+ year old device? > > >>> > > >>> If these old devices are still in use and you would like to maintain > > >>> this support then I think that there is no issue with it. > > >>> > > >>>> If yes, I would be willing to discuss and finalize this patch. If no, > > >>>> it will be archived here for the public, which is fine with me. > > >>>> > > >>>> For the NAS440 is the something special that hard disk drives 1 and 2 > > >>>> are connected to a 88SE6121 SATA-II controller, which is connected via > > >>>> PCIe. Hard disk drives 3 and 4 are directly connected to the 88F6281 > > >>>> SoC. > > >>>> > > >>>> - Add NAS440 dtb and associated files/configs > > >>>> * Includes support for HD44780 front LCD > > >>>> * Includes support for device LEDs (via 74AHC164 shift register) > > >>>> - Add Marvell 88SE6121 AHCI support. Thanks to Pali Rohár for recently > > >>>> adding the necessary Kirkwood PCIe driver. It works :) > > >>> > > >>> Perfect! > > >>> > > >>>> - Tested with my NAS440 hardware: ETH/USB/SATA/AHCI-SCSI/GPIO/LCD/LEDs > > >>>> ok > > >>>> > > >>>> As far as I can see this fully implements the support for this board > > >>>> within U-Boot. With the Linux kernel however there are problems, the > > >>>> kernel AHCI driver fails with "failed
Re: [PATCH] arm: mvebu: Add support for Thecus N2350 (Armada 385) board
Hi Pali, On Sun, Jan 29, 2023 at 3:20 AM Pali Rohár wrote: > > On Saturday 28 January 2023 18:07:29 Tony Dinh wrote: > > > > > > +#define BOOT_TARGET_DEVICES(func) \ > > > > > > + func(SCSI, scsi, 0) \ > > > > > > + func(USB, usb, 0) \ > > > > > > + func(PXE, pxe, na) \ > > > > > > + func(DHCP, dhcp, na) > > > > > > > > > > I see that you have also NAND with UBIFS in DTS file. What is stored > > > > > on > > > > > NAND? Does not it have bootable system and should be in default boot > > > > > target list? > > > > > > > > The UBIFS in stock FW was the rootfs. But it is not bootable any more > > > > with the new u-boot. > > > > > > Hm... Why it is not bootable by new u-boot? Is there some unknown issue > > > that it suddenly stopped working? Because u-boot as a bootloader is > > > there for booting system and it is its primary functionality. And if new > > > version cannot boot something which old version was able then it is a > > > bug on which u-boot should focus. If you have more details about this > > > issue, I can look at it. > > > > IMO, I don't think we need to waste time with stock FW on these NAS > > boards. They are no longer supported by the manufacturers for a while, > > and therefore have some inherent security problems (most if not all > > Kirkwood boards suffer the same fate). Usually people just modernize > > these boxes with a new u-boot and boot them with a modern Linux > > distro. It's a great thing that modern boards like Turris Omnia are > > supported by the manufacturer and other FOSS contributors. With > > Thecus, Netgear, Seagate... even a lot of Synology boxes, people just > > run really old kernel and rootfs and never see an update. > > Well, my point here is that this is ubifs stuff and I have one arm > device on which u-boot ubifs code is unable to parse and read data from > it. I thought that ubifs is completely broken in u-boot but then I > enabled ubifs on another powerpc device and it worked perfectly. I had a similar experience on a few ARM devices. But when I wiped the partition and created a brand new UBIFS on the same devices with the latest u-boot code, it worked perfectly too. So perhaps it was something in the old filesystem in stock FW that caused the problem. I have on these ARM boards the latest u-boot (2017-2023). So if you would like me to help testing some ideas or some problems, I'd be glad to do what I can. Perhaps we can do it on a different thread, I might be able to find my backup mtd dumps for an old device such as Pogo V4 and try mounting its partition with the new u-boot. Thanks, Tony > I tried to debug that issue on arm device without any success. > Having broken code is u-boot is not something which should be present in > project and I wanted to fix it...
Re: [PATCH] arm: mvebu: Add support for Thecus N2350 (Armada 385) board
Hi Pali, On Sat, Jan 28, 2023 at 5:36 PM Pali Rohár wrote: > > Hello! > > On Saturday 28 January 2023 16:17:32 Tony Dinh wrote: > > Hi Pali, > > > > On Sat, Jan 28, 2023 at 5:00 AM Pali Rohár wrote: > > > > > > Hello! It is nice to see support for another A385 board! > > > I have few comments, see below... > > > > > > On Friday 27 January 2023 20:47:10 Tony Dinh wrote: > > > > Thecus N2350 is a NAS based on Marvell Armada 385 SoC. > > > > > > > > Specification: > > > > > > > > - Processor: Marvel MV88F6820 Dual Core at 1GHz > > > > - 1 GiB DDR4 RAM > > > > - 4MB Macronix mx25l3205d SPI flash > > > > - 512MB Hynix H27U4G8F2DTR-BC NAND flash > > > > - I2C > > > > - 2x USB 3.0 > > > > - 1x GBE LAN port (PHY: Marvell 88E1510) > > > > - 2x SATA (hot swap slots) > > > > - 3x buttons > > > > - 10x LEDS > > > > - serial console > > > > > > > > Signed-off-by: Tony Dinh > > > > --- > > > > > > > > arch/arm/dts/Makefile | 1 + > > > > .../dts/armada-385-thecus-n2350-u-boot.dtsi | 5 + > > > > arch/arm/dts/armada-385-thecus-n2350.dts | 451 ++ > > > > arch/arm/mach-mvebu/Kconfig | 12 + > > > > board/thecus/n2350/MAINTAINERS| 6 + > > > > board/thecus/n2350/Makefile | 6 + > > > > board/thecus/n2350/n2350.c| 134 ++ > > > > configs/n2350_defconfig | 93 > > > > include/configs/n2350.h | 65 +++ > > > > 9 files changed, 773 insertions(+) > > > > create mode 100644 arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi > > > > create mode 100644 arch/arm/dts/armada-385-thecus-n2350.dts > > > > create mode 100644 board/thecus/n2350/MAINTAINERS > > > > create mode 100644 board/thecus/n2350/Makefile > > > > create mode 100644 board/thecus/n2350/n2350.c > > > > create mode 100644 configs/n2350_defconfig > > > > create mode 100644 include/configs/n2350.h > > > > > > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > > > > index 3ecd6a86e9..c5d1825a3b 100644 > > > > --- a/arch/arm/dts/Makefile > > > > +++ b/arch/arm/dts/Makefile > > > > @@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += \ > > > > armada-385-atl-x530.dtb \ > > > > armada-385-atl-x530DP.dtb \ > > > > armada-385-db-88f6820-amc.dtb \ > > > > + armada-385-thecus-n2350.dtb \ > > > > armada-385-turris-omnia.dtb \ > > > > armada-388-clearfog.dtb \ > > > > armada-388-gp.dtb \ > > > > diff --git a/arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi > > > > b/arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi > > > > new file mode 100644 > > > > index 00..0b818705cf > > > > --- /dev/null > > > > +++ b/arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi > > > > @@ -0,0 +1,5 @@ > > > > +// SPDX-License-Identifier: GPL-2.0+ > > > > +/* > > > > + * Copyright (C) 2023 Tony Dinh > > > > + */ > > > > +#include "mvebu-u-boot.dtsi" > > > > > > If you have only #include "mvebu-u-boot.dtsi" line in your -u-boot.dtsi > > > file then this -u-boot.dtsi file should not be needed at all. Because > > > U-Boot build process include it automatically when board -u-boot.dtsi > > > does not exits. > > > > I see. So that must be part of a Make file somewhere? > > Yes, Tom mentioned it in past, see email discussion: > https://lore.kernel.org/u-boot/20220802121113.GG1146598@bill-the-cat/ > > > I have another > > patch for Kirkwood boards -uboot.dtsi coming and I'm thinking about > > making it automatic, too, if possible. > > I think that kirkwood soc would use kirkwood-u-boot.dtsi. file... But it > needs to be checked. > > > > > diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts > > > > b/arch/arm/dts/armada-385-thecus-n2350.dts > > > > new file mode 100644 > > > > index 00..5632d82510 > > > > --- /dev/null > > > > +++ b/arch/arm/dts/arm
Re: [PATCH] arm: mvebu: Add support for Thecus N2350 (Armada 385) board
Hi Pali,
On Sat, Jan 28, 2023 at 5:00 AM Pali Rohár wrote:
>
> Hello! It is nice to see support for another A385 board!
> I have few comments, see below...
>
> On Friday 27 January 2023 20:47:10 Tony Dinh wrote:
> > Thecus N2350 is a NAS based on Marvell Armada 385 SoC.
> >
> > Specification:
> >
> > - Processor: Marvel MV88F6820 Dual Core at 1GHz
> > - 1 GiB DDR4 RAM
> > - 4MB Macronix mx25l3205d SPI flash
> > - 512MB Hynix H27U4G8F2DTR-BC NAND flash
> > - I2C
> > - 2x USB 3.0
> > - 1x GBE LAN port (PHY: Marvell 88E1510)
> > - 2x SATA (hot swap slots)
> > - 3x buttons
> > - 10x LEDS
> > - serial console
> >
> > Signed-off-by: Tony Dinh
> > ---
> >
> > arch/arm/dts/Makefile | 1 +
> > .../dts/armada-385-thecus-n2350-u-boot.dtsi | 5 +
> > arch/arm/dts/armada-385-thecus-n2350.dts | 451 ++
> > arch/arm/mach-mvebu/Kconfig | 12 +
> > board/thecus/n2350/MAINTAINERS| 6 +
> > board/thecus/n2350/Makefile | 6 +
> > board/thecus/n2350/n2350.c| 134 ++
> > configs/n2350_defconfig | 93
> > include/configs/n2350.h | 65 +++
> > 9 files changed, 773 insertions(+)
> > create mode 100644 arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi
> > create mode 100644 arch/arm/dts/armada-385-thecus-n2350.dts
> > create mode 100644 board/thecus/n2350/MAINTAINERS
> > create mode 100644 board/thecus/n2350/Makefile
> > create mode 100644 board/thecus/n2350/n2350.c
> > create mode 100644 configs/n2350_defconfig
> > create mode 100644 include/configs/n2350.h
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 3ecd6a86e9..c5d1825a3b 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
> > armada-385-atl-x530.dtb \
> > armada-385-atl-x530DP.dtb \
> > armada-385-db-88f6820-amc.dtb \
> > + armada-385-thecus-n2350.dtb \
> > armada-385-turris-omnia.dtb \
> > armada-388-clearfog.dtb \
> > armada-388-gp.dtb \
> > diff --git a/arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi
> > b/arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi
> > new file mode 100644
> > index 00..0b818705cf
> > --- /dev/null
> > +++ b/arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi
> > @@ -0,0 +1,5 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2023 Tony Dinh
> > + */
> > +#include "mvebu-u-boot.dtsi"
>
> If you have only #include "mvebu-u-boot.dtsi" line in your -u-boot.dtsi
> file then this -u-boot.dtsi file should not be needed at all. Because
> U-Boot build process include it automatically when board -u-boot.dtsi
> does not exits.
I see. So that must be part of a Make file somewhere? I have another
patch for Kirkwood boards -uboot.dtsi coming and I'm thinking about
making it automatic, too, if possible.
> > diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts
> > b/arch/arm/dts/armada-385-thecus-n2350.dts
> > new file mode 100644
> > index 00..5632d82510
> > --- /dev/null
> > +++ b/arch/arm/dts/armada-385-thecus-n2350.dts
>
> Could you send DTS file also into Linux kernel?
Yes, as soon as this board gets merged here, I will send the DTS to
Linux kernel.
>
> > @@ -0,0 +1,451 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Device Tree file for Thecus N2350 board
> > + *
> > + * Copyright (C) 2018-2023 Tony Dinh
> > + * Copyright (C) 2018 Manuel Jung
> > + */
> > +
> > +/dts-v1/;
> > +#include
> > +#include
> > +#include "armada-385.dtsi"
> > +
> > +/ {
> > + model = "Thecus N2350";
> > + compatible = "thecus,n2350", "marvell,a385-db", "marvell,armada388",
> > + "marvell,armada385", "marvell,armada380";
>
> As it is Armada 385 board, you should not have there "marvell,armada388"
> and also you should not have there "marvell,a385-db" which refers to the
> Marvell Development Board (different one).
OK.
> > +
> > + aliases {
> > + ethernet0 = ð0;
> > + };
> > +
> > + chosen {
> >
[PATCH] arm: mvebu: Add support for Thecus N2350 (Armada 385) board
Thecus N2350 is a NAS based on Marvell Armada 385 SoC.
Specification:
- Processor: Marvel MV88F6820 Dual Core at 1GHz
- 1 GiB DDR4 RAM
- 4MB Macronix mx25l3205d SPI flash
- 512MB Hynix H27U4G8F2DTR-BC NAND flash
- I2C
- 2x USB 3.0
- 1x GBE LAN port (PHY: Marvell 88E1510)
- 2x SATA (hot swap slots)
- 3x buttons
- 10x LEDS
- serial console
Signed-off-by: Tony Dinh
---
arch/arm/dts/Makefile | 1 +
.../dts/armada-385-thecus-n2350-u-boot.dtsi | 5 +
arch/arm/dts/armada-385-thecus-n2350.dts | 451 ++
arch/arm/mach-mvebu/Kconfig | 12 +
board/thecus/n2350/MAINTAINERS| 6 +
board/thecus/n2350/Makefile | 6 +
board/thecus/n2350/n2350.c| 134 ++
configs/n2350_defconfig | 93
include/configs/n2350.h | 65 +++
9 files changed, 773 insertions(+)
create mode 100644 arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi
create mode 100644 arch/arm/dts/armada-385-thecus-n2350.dts
create mode 100644 board/thecus/n2350/MAINTAINERS
create mode 100644 board/thecus/n2350/Makefile
create mode 100644 board/thecus/n2350/n2350.c
create mode 100644 configs/n2350_defconfig
create mode 100644 include/configs/n2350.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 3ecd6a86e9..c5d1825a3b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-385-atl-x530.dtb \
armada-385-atl-x530DP.dtb \
armada-385-db-88f6820-amc.dtb \
+ armada-385-thecus-n2350.dtb \
armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi
b/arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi
new file mode 100644
index 00..0b818705cf
--- /dev/null
+++ b/arch/arm/dts/armada-385-thecus-n2350-u-boot.dtsi
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Tony Dinh
+ */
+#include "mvebu-u-boot.dtsi"
diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts
b/arch/arm/dts/armada-385-thecus-n2350.dts
new file mode 100644
index 00..5632d82510
--- /dev/null
+++ b/arch/arm/dts/armada-385-thecus-n2350.dts
@@ -0,0 +1,451 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Thecus N2350 board
+ *
+ * Copyright (C) 2018-2023 Tony Dinh
+ * Copyright (C) 2018 Manuel Jung
+ */
+
+/dts-v1/;
+#include
+#include
+#include "armada-385.dtsi"
+
+/ {
+ model = "Thecus N2350";
+ compatible = "thecus,n2350", "marvell,a385-db", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ aliases {
+ ethernet0 = ð0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x4000>; /* 1GB */
+ };
+
+ soc {
+ ranges = ;
+
+ internal-regs {
+ i2c@11000 {
+ status = "okay";
+ clock-frequency = <10>;
+ };
+
+ i2c@11100 {
+ status = "okay";
+ clock-frequency = <10>;
+ };
+
+ serial@12000 {
+ status = "okay";
+ };
+
+ usb@58000 {
+ status = "ok";
+ };
+
+ ethernet@7 {
+ status = "okay";
+ phy = <&phy0>;
+ phy-mode = "sgmii";
+ buffer-manager = <&bm>;
+ bm,pool-long = <0>;
+ bm,pool-short = <1>;
+ };
+
+ mdio@72004 {
+ phy0: ethernet-phy@0 {
+ reg = <1>;
+ };
+ };
+
+ sata@a8000 {
+ status = "okay";
+ };
+
+ bm@c8000 {
+ status = "okay";
+ };
+
+ pinctrl@18000 {
+ pinctrl-names = "default";
+
+ pmx_po
Re: DM_SERIAL is broken for Kirkwood boards
Hi Tom,
On Fri, Jan 27, 2023 at 2:06 PM Tom Rini wrote:
>
> On Fri, Jan 27, 2023 at 01:56:34PM -0800, Tony Dinh wrote:
> > Hi Tom,
> >
> > On Fri, Jan 27, 2023 at 5:39 AM Tom Rini wrote:
> > >
> > > On Fri, Jan 27, 2023 at 01:31:06PM +0100, Stefan Roese wrote:
> > > > Hi Tony,
> > > >
> > > > On 1/27/23 07:13, Tony Dinh wrote:
> > > > > Hi all,
> > > > >
> > > > > On Thu, Jan 26, 2023 at 3:38 PM Tony Dinh wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I ran some tests today (Pogo V4 and NSA310S boards) with the latest
> > > > > > master branch and saw the same behavior we've seen before. The
> > > > > > boards
> > > > > > hung, and the serial console was silent after kwboot finished
> > > > > > transferring the u-boot image. I'm running with this DTSI patch
> > > > > > below
> > > > > > (to enable dm-pre-reloc for uart0).
> > > > > >
> > > > > > If I deselected DM_SERIAL then both boards booted OK with kwboot.
> > > > > >
> > > > > > diff --git a/arch/arm/dts/kirkwood-nsa310s.dts
> > > > > > b/arch/arm/dts/kirkwood-nsa310s.dts
> > > > > > index 09ee76c2a2..6c5a991fde 100644
> > > > > > --- a/arch/arm/dts/kirkwood-nsa310s.dts
> > > > > > +++ b/arch/arm/dts/kirkwood-nsa310s.dts
> > > > > > @@ -317,3 +317,8 @@
> > > > > > &pcie0 {
> > > > > > status = "okay";
> > > > > > };
> > > > > > +
> > > > > > +&uart0 {
> > > > > > +u-boot,dm-pre-reloc;
> > > > > > +status = "okay";
> > > > > > +};
> > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > > > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > > > > > index 5aa4669ae2..ef495d69f5 100644
> > > > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > > > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > > > > > @@ -98,6 +98,7 @@
> > > > > > };
> > > > > >
> > > > > > &uart0 {
> > > > > > + u-boot,dm-pre-reloc;
> > > > > > status = "okay";
> > > > > > };
> > > > > >
> > > > > > @Michael, it would be great if you could try with your Buffalo
> > > > > > board,
> > > > > > and see if you will experience the same behavior.
> > > > >
> > > > > Looks like this commit was the indirect cause of the problem.
> > > > >
> > > > > Convert CONFIG_SYS_NS16550_MEM32 et al to Kconfig
> > > > > https://github.com/u-boot/u-boot/commit/9591b63531fa5a34698ee7bb3800af6c4ea6ba2f
> > > > >
> > > > > -CONFIG_SYS_NS16550=y
> > > > > +CONFIG_SYS_NS16550_SERIAL=y
> > > > > +CONFIG_SYS_NS16550_REG_SIZE=-4
> > > >
> > > > Thanks for digging into this. Could you perhaps prepare a patch like
> > > > this:
> > > >
> > > > diff --git a/arch/arm/mach-kirkwood/Kconfig
> > > > b/arch/arm/mach-kirkwood/Kconfig
> > > > index 45cc9326368c..438f86922310 100644
> > > > --- a/arch/arm/mach-kirkwood/Kconfig
> > > > +++ b/arch/arm/mach-kirkwood/Kconfig
> > > > @@ -15,6 +15,7 @@ config SHEEVA_88SV131
> > > > config KIRKWOOD_COMMON
> > > > bool
> > > > select DM_SERIAL
> > > > + select SYS_NS16550_SERIAL
> > > >
> > > > config HAS_CUSTOM_SYS_INIT_SP_ADDR
> > > > bool "Use a custom location for the initial stack pointer
> > > > address"
> > > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> > > > index bb5083201b38..7b575295746b 100644
> > > > --- a/drivers/serial/Kconfig
> > > > +++ b/drivers/serial/Kconfig
> > > > @@ -773,7 +773,7 @@ config SYS_NS16550_REG_SIZE
> > > > int "ns16550 register width and endianness"
> > > > depends on SYS_NS16550_SERIAL || SPL_SYS_NS16550_SERIAL
> > > > range -4 4
> > > > - defaul
Re: DM_SERIAL is broken for Kirkwood boards
Hi Tom,
On Fri, Jan 27, 2023 at 5:39 AM Tom Rini wrote:
>
> On Fri, Jan 27, 2023 at 01:31:06PM +0100, Stefan Roese wrote:
> > Hi Tony,
> >
> > On 1/27/23 07:13, Tony Dinh wrote:
> > > Hi all,
> > >
> > > On Thu, Jan 26, 2023 at 3:38 PM Tony Dinh wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I ran some tests today (Pogo V4 and NSA310S boards) with the latest
> > > > master branch and saw the same behavior we've seen before. The boards
> > > > hung, and the serial console was silent after kwboot finished
> > > > transferring the u-boot image. I'm running with this DTSI patch below
> > > > (to enable dm-pre-reloc for uart0).
> > > >
> > > > If I deselected DM_SERIAL then both boards booted OK with kwboot.
> > > >
> > > > diff --git a/arch/arm/dts/kirkwood-nsa310s.dts
> > > > b/arch/arm/dts/kirkwood-nsa310s.dts
> > > > index 09ee76c2a2..6c5a991fde 100644
> > > > --- a/arch/arm/dts/kirkwood-nsa310s.dts
> > > > +++ b/arch/arm/dts/kirkwood-nsa310s.dts
> > > > @@ -317,3 +317,8 @@
> > > > &pcie0 {
> > > > status = "okay";
> > > > };
> > > > +
> > > > +&uart0 {
> > > > +u-boot,dm-pre-reloc;
> > > > +status = "okay";
> > > > +};
> > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > > > index 5aa4669ae2..ef495d69f5 100644
> > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > > > @@ -98,6 +98,7 @@
> > > > };
> > > >
> > > > &uart0 {
> > > > + u-boot,dm-pre-reloc;
> > > > status = "okay";
> > > > };
> > > >
> > > > @Michael, it would be great if you could try with your Buffalo board,
> > > > and see if you will experience the same behavior.
> > >
> > > Looks like this commit was the indirect cause of the problem.
> > >
> > > Convert CONFIG_SYS_NS16550_MEM32 et al to Kconfig
> > > https://github.com/u-boot/u-boot/commit/9591b63531fa5a34698ee7bb3800af6c4ea6ba2f
> > >
> > > -CONFIG_SYS_NS16550=y
> > > +CONFIG_SYS_NS16550_SERIAL=y
> > > +CONFIG_SYS_NS16550_REG_SIZE=-4
> >
> > Thanks for digging into this. Could you perhaps prepare a patch like
> > this:
> >
> > diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
> > index 45cc9326368c..438f86922310 100644
> > --- a/arch/arm/mach-kirkwood/Kconfig
> > +++ b/arch/arm/mach-kirkwood/Kconfig
> > @@ -15,6 +15,7 @@ config SHEEVA_88SV131
> > config KIRKWOOD_COMMON
> > bool
> > select DM_SERIAL
> > + select SYS_NS16550_SERIAL
> >
> > config HAS_CUSTOM_SYS_INIT_SP_ADDR
> > bool "Use a custom location for the initial stack pointer address"
> > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> > index bb5083201b38..7b575295746b 100644
> > --- a/drivers/serial/Kconfig
> > +++ b/drivers/serial/Kconfig
> > @@ -773,7 +773,7 @@ config SYS_NS16550_REG_SIZE
> > int "ns16550 register width and endianness"
> > depends on SYS_NS16550_SERIAL || SPL_SYS_NS16550_SERIAL
> > range -4 4
> > - default -4 if ARCH_OMAP2PLUS || ARCH_SUNXI
> > + default -4 if ARCH_OMAP2PLUS || ARCH_SUNXI || ARCH_KIRKWOOD
> > default 1
> > help
> > Indicates register width and also endianness. If positive,
> > big-endian
> >
> > Does this work for you?
>
> Wait, when do you need serial and what are you select'ing for, exactly?
> The ns16550 driver stuff is indeed a bit of a mess, option wise, but
> SYS_NS16550 and SYS_NS16550_SERIAL are not the same. Are you having
> problems in a stage with, or without DM_SERIAL enabled?
The problem was described in the initial email above.
"I ran some tests today (Pogo V4 and NSA310S boards) with the latest
master branch and saw the same behavior we've seen before. The boards
hung, and the serial console was silent after kwboot finished
transferring the u-boot image. I'm running with this DTSI patch below
(to enable dm-pre-reloc for uart0).
If I deselected DM_SERIAL then both boards booted OK with kwboot."
So the problem is seen with DM_SERIAL enabled, and occurs immediately
when u-boot starts.
If I understand correctly, it looks like we just need to select
SYS_NS16550 then the driver can be found by DM serial uclass. And that
worked!
Stefan patch proposes that we make SYS_NS16550_SERIAL available for
ARCH_KIRKWOOD, but I think there is more change is needed with this
approach because:
drivers/serial/Kconfig
config SYS_NS16550_SERIAL
bool "NS16550 UART or compatible legacy driver"
depends on !DM_SERIAL
select SYS_NS16550
Thanks,
Tony
>
> --
> Tom
Re: DM_SERIAL is broken for Kirkwood boards
Hi all,
On Thu, Jan 26, 2023 at 3:38 PM Tony Dinh wrote:
>
> Hi all,
>
> I ran some tests today (Pogo V4 and NSA310S boards) with the latest
> master branch and saw the same behavior we've seen before. The boards
> hung, and the serial console was silent after kwboot finished
> transferring the u-boot image. I'm running with this DTSI patch below
> (to enable dm-pre-reloc for uart0).
>
> If I deselected DM_SERIAL then both boards booted OK with kwboot.
>
> diff --git a/arch/arm/dts/kirkwood-nsa310s.dts
> b/arch/arm/dts/kirkwood-nsa310s.dts
> index 09ee76c2a2..6c5a991fde 100644
> --- a/arch/arm/dts/kirkwood-nsa310s.dts
> +++ b/arch/arm/dts/kirkwood-nsa310s.dts
> @@ -317,3 +317,8 @@
> &pcie0 {
> status = "okay";
> };
> +
> +&uart0 {
> +u-boot,dm-pre-reloc;
> +status = "okay";
> +};
> diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> index 5aa4669ae2..ef495d69f5 100644
> --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> @@ -98,6 +98,7 @@
> };
>
> &uart0 {
> + u-boot,dm-pre-reloc;
> status = "okay";
> };
>
> @Michael, it would be great if you could try with your Buffalo board,
> and see if you will experience the same behavior.
Looks like this commit was the indirect cause of the problem.
Convert CONFIG_SYS_NS16550_MEM32 et al to Kconfig
https://github.com/u-boot/u-boot/commit/9591b63531fa5a34698ee7bb3800af6c4ea6ba2f
-CONFIG_SYS_NS16550=y
+CONFIG_SYS_NS16550_SERIAL=y
+CONFIG_SYS_NS16550_REG_SIZE=-4
Later, when we enabled DM_SERIAL, CONFIG_SYS_NS16550_SERIAL and
CONFIG_SYS_NS16550_REG_SIZE got deselected. But CONFIG_SYS_NS16550 is
needed again. So bring it back and it will work.
diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig
index 3860ad30d3..f98e6cdc6e 100644
--- a/configs/pogo_v4_defconfig
+++ b/configs/pogo_v4_defconfig
@@ -70,8 +70,7 @@ CONFIG_PCI=y
CONFIG_PCI_MVEBU=y
CONFIG_DM_RTC=y
CONFIG_RTC_EMULATION=y
-CONFIG_SYS_NS16550_SERIAL=y
-CONFIG_SYS_NS16550_REG_SIZE=-4
+CONFIG_SYS_NS16550=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=y
All the best,
Tony
Re: [PATCH v3] ddr: marvell: a38x: Add support for DDR4 from Marvell mv-ddr-marvell repository
Hi Pali, On Thu, Jan 26, 2023 at 1:26 AM Stefan Roese wrote: > > On 1/19/23 04:03, Tony Dinh wrote: > > This syncs drivers/ddr/marvell/a38x/ with the master branch of repository > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git > > > > up to the commit "mv_ddr: a3700: Use the right size for memset to not > > overflow" > > d5acc10c287e40cc2feeb28710b92e45c93c702c > > > > This patch was created by following steps: > > > > 1. Replace all a38x files in U-Boot tree by files from upstream github > > Marvell mv-ddr-marvell repository. > > > > 2. Run following command to omit portions not relevant for a38x, > > ddr3, and ddr4: > > > > files=drivers/ddr/marvell/a38x/* > > unifdef -m -UMV_DDR -UMV_DDR_ATF -UCONFIG_APN806 \ > > -UCONFIG_MC_STATIC -UCONFIG_MC_STATIC_PRINT > > -UCONFIG_PHY_STATIC \ > > -UCONFIG_PHY_STATIC_PRINT -UCONFIG_CUSTOMER_BOARD_SUPPORT \ > > -UCONFIG_A3700 -UA3900 -UA80X0 -UA70X0 -DCONFIG_ARMADA_38X > > -UCONFIG_ARMADA_39X \ > > -UCONFIG_64BIT $files > > > > 3. Manually change license to SPDX-License-Identifier > > (upstream license in upstream github repository contains long license > > texts and U-Boot is using just SPDX-License-Identifier. > > > > After applying this patch, a38x, ddr3, and ddr4 code in upstream Marvell > > github > > repository and in U-Boot would be fully identical. So in future applying > > above steps could be used to sync code again. > > > > The only change in this patch are: > > 1. Some fixes with include files. > > 2. Some function return and basic type defines changes in > > mv_ddr_plat.c (to correct Marvell bug). > > 3. Remove of dead code in newly copied files (as a result of the > > filter script stripping out everything other than a38x, dd3, and > > ddr4). > > > > Reference: > > "ddr: marvell: a38x: Sync code with Marvell mv-ddr-marvell repository" > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > Signed-off-by: Tony Dinh > > Applied to u-boot-marvell/master > > Thanks, > Stefan Looking at the history of the work we've done to sync u-boot code back to the mv-ddr-marvell repo, I think I should follow the same approach. So I've pushed 2 commits to my GitHub repo. https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/compare/master...mibodhi:mv-ddr-marvell:u-boot-ddr4-2023.01-fix Please review these 2 commits and create a pull request to Marvell, like you did for others last year during DDR3 code sync. Thanks, Tony
DM_SERIAL is broken for Kirkwood boards
Hi all,
I ran some tests today (Pogo V4 and NSA310S boards) with the latest
master branch and saw the same behavior we've seen before. The boards
hung, and the serial console was silent after kwboot finished
transferring the u-boot image. I'm running with this DTSI patch below
(to enable dm-pre-reloc for uart0).
If I deselected DM_SERIAL then both boards booted OK with kwboot.
diff --git a/arch/arm/dts/kirkwood-nsa310s.dts
b/arch/arm/dts/kirkwood-nsa310s.dts
index 09ee76c2a2..6c5a991fde 100644
--- a/arch/arm/dts/kirkwood-nsa310s.dts
+++ b/arch/arm/dts/kirkwood-nsa310s.dts
@@ -317,3 +317,8 @@
&pcie0 {
status = "okay";
};
+
+&uart0 {
+u-boot,dm-pre-reloc;
+status = "okay";
+};
diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
index 5aa4669ae2..ef495d69f5 100644
--- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
+++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
@@ -98,6 +98,7 @@
};
&uart0 {
+ u-boot,dm-pre-reloc;
status = "okay";
};
@Michael, it would be great if you could try with your Buffalo board,
and see if you will experience the same behavior.
Thanks,
Tony
[PATCH] arm: kirkwood: Use Kirkwood common early malloc area for various Kirkwood boards
For Kirkwood boards, it is necessary to have early malloc in DRAM area
when Driver Model for Serial is enabled. This patch removes individual
board settings for early malloc in various Kirkwood boards, and uses the
Kirkwood commonly defined settings in arch/arm/mach-kirkwood/Kconfig.
Signed-off-by: Tony Dinh
---
configs/dockstar_defconfig | 3 ---
configs/dreamplug_defconfig | 3 ---
configs/goflexhome_defconfig | 3 ---
configs/iconnect_defconfig | 3 ---
configs/nsa310s_defconfig| 3 ---
configs/pogo_e02_defconfig | 3 ---
configs/pogo_v4_defconfig| 3 ---
configs/sheevaplug_defconfig | 3 ---
8 files changed, 24 deletions(-)
diff --git a/configs/dockstar_defconfig b/configs/dockstar_defconfig
index a17d01f3fd..d08182d270 100644
--- a/configs/dockstar_defconfig
+++ b/configs/dockstar_defconfig
@@ -17,9 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="kirkwood-dockstar"
CONFIG_SYS_PROMPT="DockStar> "
CONFIG_IDENT_STRING="\nSeagate FreeAgent DockStar"
CONFIG_SYS_LOAD_ADDR=0x80
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
-# CONFIG_SYS_MALLOC_F is not set
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="setenv bootargs ${console} ${mtdparts} ${bootargs_root};
ubi part root; ubifsmount ubi:root; ubifsload 0x80 ${kernel}; ubifsload
0x110 ${initrd}; bootm 0x80 0x110"
diff --git a/configs/dreamplug_defconfig b/configs/dreamplug_defconfig
index 6deb05575c..3cff5034b9 100644
--- a/configs/dreamplug_defconfig
+++ b/configs/dreamplug_defconfig
@@ -17,9 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="kirkwood-dreamplug"
CONFIG_IDENT_STRING="\nMarvell-DreamPlug"
CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_ENV_ADDR=0x10
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
-# CONFIG_SYS_MALLOC_F is not set
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="setenv ethact ethernet-controller@72000;
${x_bootcmd_ethernet}; setenv ethact ethernet-controller@76000;
${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel}; setenv bootargs
${x_bootargs} ${x_bootargs_root}; bootm 0x640;"
diff --git a/configs/goflexhome_defconfig b/configs/goflexhome_defconfig
index 8ee1183309..8dc285241b 100644
--- a/configs/goflexhome_defconfig
+++ b/configs/goflexhome_defconfig
@@ -17,9 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="kirkwood-goflexnet"
CONFIG_SYS_PROMPT="GoFlexHome> "
CONFIG_IDENT_STRING="\nSeagate GoFlex Home"
CONFIG_SYS_LOAD_ADDR=0x80
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
-# CONFIG_SYS_MALLOC_F is not set
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="setenv bootargs ${console} ${mtdparts} ${bootargs_root};
ubi part root; ubifsmount ubi:root; ubifsload 0x80 ${kernel}; bootm
0x80"
diff --git a/configs/iconnect_defconfig b/configs/iconnect_defconfig
index f536dd3bcb..94f4ee2772 100644
--- a/configs/iconnect_defconfig
+++ b/configs/iconnect_defconfig
@@ -17,9 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="kirkwood-iconnect"
CONFIG_SYS_PROMPT="iConnect> "
CONFIG_IDENT_STRING=" Iomega iConnect"
CONFIG_SYS_LOAD_ADDR=0x80
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
-# CONFIG_SYS_MALLOC_F is not set
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="setenv bootargs ${console} ${mtdparts} ${bootargs_root};
ubi part rootfs; ubifsmount ubi:rootfs; ubifsload 0x80 ${kernel}; bootm
0x80"
diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig
index e7d6ffd925..ab896ff54e 100644
--- a/configs/nsa310s_defconfig
+++ b/configs/nsa310s_defconfig
@@ -9,7 +9,6 @@ CONFIG_CMDLINE_TAG=y
CONFIG_INITRD_TAG=y
CONFIG_SYS_KWD_CONFIG="board/zyxel/nsa310s/kwbimage.cfg"
CONFIG_TEXT_BASE=0x60
-CONFIG_SYS_MALLOC_F_LEN=0x400
CONFIG_NR_DRAM_BANKS=2
CONFIG_TARGET_NSA310S=y
CONFIG_ENV_SIZE=0x2
@@ -19,8 +18,6 @@ CONFIG_SYS_PROMPT="NSA310s> "
CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server"
CONFIG_SYS_LOAD_ADDR=0x80
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
CONFIG_BOOTDELAY=3
CONFIG_USE_PREBOOT=y
# CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/configs/pogo_e02_defconfig b/configs/pogo_e02_defconfig
index 116e5d0ed3..067fb9e13b 100644
--- a/configs/pogo_e02_defconfig
+++ b/configs/pogo_e02_defconfig
@@ -17,9 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="kirkwood-pogo_e02"
CONFIG_SYS_PROMPT="PogoE02> "
CONFIG_IDENT_STRING="\nPogo E02"
CONFIG_SYS_LOAD_ADDR=0x80
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
-# CONFIG_SYS_MALLOC_F is not set
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTCOMMAND=y
CONFIG_BOOTCOMMAND="setenv bootargs $(bo
Re: [PATCH v3] ddr: marvell: a38x: Add support for DDR4 from Marvell mv-ddr-marvell repository
Hi Pali, On Thu, Jan 19, 2023 at 10:05 AM Pali Rohár wrote: > > Hello! If I read the whole change correctly then all changes are done > under ifdef CONFIG_DDR4. So for existing (ddr3) boards this is noop. > > Reviewed-by: Pali Rohár > > The reaming part is the changes which you done on top of the Marvell > code to make it compile under u-boot (floating point, basic types). > Please either open a pull request to Marvell github with those changes > or send me diff/patch and I will do it. So doing resync again from > Marvell repo does not remove those your fixes. Thanks for the review Palii. I will open a pull request and let you know so you can comment on it at Marvell repo. All the best, Tony > > On Wednesday 18 January 2023 19:03:04 Tony Dinh wrote: > > This syncs drivers/ddr/marvell/a38x/ with the master branch of repository > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git > > > > up to the commit "mv_ddr: a3700: Use the right size for memset to not > > overflow" > > d5acc10c287e40cc2feeb28710b92e45c93c702c > > > > This patch was created by following steps: > > > > 1. Replace all a38x files in U-Boot tree by files from upstream github > > Marvell mv-ddr-marvell repository. > > > > 2. Run following command to omit portions not relevant for a38x, > > ddr3, and ddr4: > > > > files=drivers/ddr/marvell/a38x/* > > unifdef -m -UMV_DDR -UMV_DDR_ATF -UCONFIG_APN806 \ > > -UCONFIG_MC_STATIC -UCONFIG_MC_STATIC_PRINT > > -UCONFIG_PHY_STATIC \ > > -UCONFIG_PHY_STATIC_PRINT -UCONFIG_CUSTOMER_BOARD_SUPPORT \ > > -UCONFIG_A3700 -UA3900 -UA80X0 -UA70X0 -DCONFIG_ARMADA_38X > > -UCONFIG_ARMADA_39X \ > > -UCONFIG_64BIT $files > > > > 3. Manually change license to SPDX-License-Identifier > > (upstream license in upstream github repository contains long license > > texts and U-Boot is using just SPDX-License-Identifier. > > > > After applying this patch, a38x, ddr3, and ddr4 code in upstream Marvell > > github > > repository and in U-Boot would be fully identical. So in future applying > > above steps could be used to sync code again. > > > > The only change in this patch are: > > 1. Some fixes with include files. > > 2. Some function return and basic type defines changes in > > mv_ddr_plat.c (to correct Marvell bug). > > 3. Remove of dead code in newly copied files (as a result of the > > filter script stripping out everything other than a38x, dd3, and > > ddr4). > > > > Reference: > > "ddr: marvell: a38x: Sync code with Marvell mv-ddr-marvell repository" > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > Signed-off-by: Tony Dinh > > --- > > > > Changes in v3: > > - Some function return and basic type defines changes in mv_ddr_plat.c > > (to fix Marvell repo code bugs). > > - Restore existing u-boot file. Existing u-boot files that become dead code > > will be > > removed in a future follow-up patch. > > - Update commit description with the latest filter script. > > - Fix indentation in commit description to be more readable. > > > > Changes in v2: > > - Modified the filter scrip to explicitly include ARMADA_38X code > > and exclude ARMADA_39X code; also remove 64BIT code. Reran it on > > drivers/ddr/marvell/a38x/ > > - Updated script > > files=drivers/ddr/marvell/a38x/* > > sed 's/#if defined(CONFIG_ARMADA_38X) || defined(CONFIG_ARMADA_39X)/#ifdef > > TRUE/' -i $files > > unifdef -m -UMV_DDR -UMV_DDR_ATF -UCONFIG_APN806 \ > > -UCONFIG_MC_STATIC -UCONFIG_MC_STATIC_PRINT > > -UCONFIG_PHY_STATIC \ > > -UCONFIG_PHY_STATIC_PRINT -UCONFIG_CUSTOMER_BOARD_SUPPORT \ > > -UCONFIG_A3700 -UA3900 -UA80X0 -UA70X0 -DCONFIG_ARMADA_38X > > -UCONFIG_ARMADA_39X \ > > -UCONFIG_64BIT $files > > - Remove more dead code files > > - Correct SPDX license header > > > > drivers/ddr/marvell/a38x/Makefile |8 + > > drivers/ddr/marvell/a38x/ddr3_debug.c | 120 + > > drivers/ddr/marvell/a38x/ddr3_init.c | 25 + > > drivers/ddr/marvell/a38x/ddr3_init.h | 14 + > > drivers/ddr/marvell/a38x/ddr3_logging_def.h | 27 + > > drivers/ddr/marvell/a38x/ddr3_training.c | 131 + > > drivers/ddr/marvell/a38x/ddr3_training_bist.c | 12 + > &g
Re: [PATCH v2] ddr: marvell: a38x: Add support for DDR4 from Marvell mv-ddr-marvell repository
On Wed, Jan 18, 2023 at 10:30 AM Pali Rohár wrote: > > On Tuesday 17 January 2023 17:18:43 Tony Dinh wrote: > > Hi Pali, > > > > On Tue, Jan 17, 2023 at 1:25 PM Pali Rohár wrote: > > > > > > Hello! > > > > > > On Tuesday 17 January 2023 13:02:46 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > On Tue, Jan 17, 2023 at 12:35 AM Pali Rohár wrote: > > > > > > > > > > Hello! Thank you for update. It is much better. > > > > > > > > > > On Monday 16 January 2023 21:34:39 Tony Dinh wrote: > > > > > > This syncs drivers/ddr/marvell/a38x/ with the master branch of > > > > > > repository > > > > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git > > > > > > > > > > > > up to the commit "mv_ddr: a3700: Use the right size for memset > > > > > > to not overflow" > > > > > > d5acc10c287e40cc2feeb28710b92e45c93c702c > > > > > > > > > > > > This patch was created by following steps: > > > > > > > > > > > > 1. Replace all a38x files in U-Boot tree by files from upstream > > > > > > github > > > > > >Marvell mv-ddr-marvell repository. > > > > > > > > > > > > 2. Run following command to omit portions not relevant for > > > > > > a38x, ddr3, and ddr4: > > > > > > > > > > > > files=drivers/ddr/marvell/a38x/* > > > > > > sed 's/#if defined(CONFIG_ARMADA_38X) || > > > > > > defined(CONFIG_ARMADA_39X)/#ifdef TRUE/' -i $files > > > > > > unifdef -m -UMV_DDR -UMV_DDR_ATF -UCONFIG_APN806 \ > > > > > > -UCONFIG_MC_STATIC -UCONFIG_MC_STATIC_PRINT > > > > > > -UCONFIG_PHY_STATIC \ > > > > > > -UCONFIG_PHY_STATIC_PRINT > > > > > > -UCONFIG_CUSTOMER_BOARD_SUPPORT \ > > > > > > -UCONFIG_A3700 -UA3900 -UA80X0 -UA70X0 -DTRUE $files > > > > > > > > > > Do not forget to also update commit message. > > > > > > > > Yes, patman extracts and creates the patch description from the commit. > > > > > > My reaction was just because you forgot to update undef for a39x. > > > > I see. Yes, I did miss that! I only described the changes in v2 description. > > > > > > > > > > > > And btw, commit messages has on each line some leading spaces which is > > > > > not probably intended. > > > > > > > > That was intentional to make the commit description (and patch > > > > description) more readable. Is it not recommended? > > > > > > I'm not sure if we are talking about the same thing. When I read this > > > your patch I saw that every time, even the first one "This sync > > > drivers/..." > > > has 4 spaces before word "This". And I'm not sure if this is just my > > > email client or not and there is some reason for it. Look at indentation > > > of line "Signed-off-by:" and line "Reference:". Should not be those two > > > lines at same indentation level? Or I did not understand it? :D > > > > > > I agree that adding indentation inside of 1. 2. 3. parts is fully > > > recommended as it makes text more readable. > > > > When I do git log I also see an extra 4 or 8 spaces on each line:) so > > not sure what we are seeing here. But yes it seems some of the > > indentation is inconsistent. Will fix that. > > > > > > > > > > > > > > > > 3. Manually change license to SPDX-License-Identifier > > > > > > (upstream license in upstream github repository contains > > > > > > long license > > > > > >texts and U-Boot is using just SPDX-License-Identifier. > > > > > > > > > > > > After applying this patch, a38x ddr3 ddr4 code in upstream > > > > > > Marvell github > > > > > > repository and in U-Boot would be fully identical. So in future > > > > > > applying > > > > > > above steps could be used to sync code again. > > > > > > > > > > > > The only change in this patch are: > > > > > &g
Re: [PATCH v2] ddr: marvell: a38x: Add support for DDR4 from Marvell mv-ddr-marvell repository
Hi Pali, On Tue, Jan 17, 2023 at 1:25 PM Pali Rohár wrote: > > Hello! > > On Tuesday 17 January 2023 13:02:46 Tony Dinh wrote: > > Hi Pali, > > > > On Tue, Jan 17, 2023 at 12:35 AM Pali Rohár wrote: > > > > > > Hello! Thank you for update. It is much better. > > > > > > On Monday 16 January 2023 21:34:39 Tony Dinh wrote: > > > > This syncs drivers/ddr/marvell/a38x/ with the master branch of > > > > repository > > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git > > > > > > > > up to the commit "mv_ddr: a3700: Use the right size for memset to > > > > not overflow" > > > > d5acc10c287e40cc2feeb28710b92e45c93c702c > > > > > > > > This patch was created by following steps: > > > > > > > > 1. Replace all a38x files in U-Boot tree by files from upstream > > > > github > > > >Marvell mv-ddr-marvell repository. > > > > > > > > 2. Run following command to omit portions not relevant for a38x, > > > > ddr3, and ddr4: > > > > > > > > files=drivers/ddr/marvell/a38x/* > > > > sed 's/#if defined(CONFIG_ARMADA_38X) || > > > > defined(CONFIG_ARMADA_39X)/#ifdef TRUE/' -i $files > > > > unifdef -m -UMV_DDR -UMV_DDR_ATF -UCONFIG_APN806 \ > > > > -UCONFIG_MC_STATIC -UCONFIG_MC_STATIC_PRINT > > > > -UCONFIG_PHY_STATIC \ > > > > -UCONFIG_PHY_STATIC_PRINT -UCONFIG_CUSTOMER_BOARD_SUPPORT \ > > > > -UCONFIG_A3700 -UA3900 -UA80X0 -UA70X0 -DTRUE $files > > > > > > Do not forget to also update commit message. > > > > Yes, patman extracts and creates the patch description from the commit. > > My reaction was just because you forgot to update undef for a39x. I see. Yes, I did miss that! I only described the changes in v2 description. > > > > > > And btw, commit messages has on each line some leading spaces which is > > > not probably intended. > > > > That was intentional to make the commit description (and patch > > description) more readable. Is it not recommended? > > I'm not sure if we are talking about the same thing. When I read this > your patch I saw that every time, even the first one "This sync drivers/..." > has 4 spaces before word "This". And I'm not sure if this is just my > email client or not and there is some reason for it. Look at indentation > of line "Signed-off-by:" and line "Reference:". Should not be those two > lines at same indentation level? Or I did not understand it? :D > > I agree that adding indentation inside of 1. 2. 3. parts is fully > recommended as it makes text more readable. When I do git log I also see an extra 4 or 8 spaces on each line:) so not sure what we are seeing here. But yes it seems some of the indentation is inconsistent. Will fix that. > > > > > > > > 3. Manually change license to SPDX-License-Identifier > > > >(upstream license in upstream github repository contains long > > > > license > > > >texts and U-Boot is using just SPDX-License-Identifier. > > > > > > > > After applying this patch, a38x ddr3 ddr4 code in upstream Marvell > > > > github > > > > repository and in U-Boot would be fully identical. So in future > > > > applying > > > > above steps could be used to sync code again. > > > > > > > > The only change in this patch are: > > > > - Removal of common board_topology_map code using ifdefs in > > > > mv_ddr_brd.c > > > > - Some fixes with include files. > > > > - Some basic type defines (original from ATF headers) in > > > > mv_ddr_plat.c > > > > > > > > Reference: > > > > "ddr: marvell: a38x: Sync code with Marvell mv-ddr-marvell > > > > repository" > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > > Signed-off-by: Tony Dinh > > > > --- > > > > > > > > Changes in v2: > > > > - Modified the filter scrip to explicitly include ARMADA_38X code > > > > and exclude ARMADA_39X code; also remove 64BIT code. Reran it on > > > > drivers/ddr/marvell/a38x/ > > > > - Updated script > >
Re: [PATCH v2] ddr: marvell: a38x: Add support for DDR4 from Marvell mv-ddr-marvell repository
Hi Pali, On Tue, Jan 17, 2023 at 12:35 AM Pali Rohár wrote: > > Hello! Thank you for update. It is much better. > > On Monday 16 January 2023 21:34:39 Tony Dinh wrote: > > This syncs drivers/ddr/marvell/a38x/ with the master branch of > > repository > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git > > > > up to the commit "mv_ddr: a3700: Use the right size for memset to not > > overflow" > > d5acc10c287e40cc2feeb28710b92e45c93c702c > > > > This patch was created by following steps: > > > > 1. Replace all a38x files in U-Boot tree by files from upstream github > >Marvell mv-ddr-marvell repository. > > > > 2. Run following command to omit portions not relevant for a38x, ddr3, > > and ddr4: > > > > files=drivers/ddr/marvell/a38x/* > > sed 's/#if defined(CONFIG_ARMADA_38X) || > > defined(CONFIG_ARMADA_39X)/#ifdef TRUE/' -i $files > > unifdef -m -UMV_DDR -UMV_DDR_ATF -UCONFIG_APN806 \ > > -UCONFIG_MC_STATIC -UCONFIG_MC_STATIC_PRINT -UCONFIG_PHY_STATIC > > \ > > -UCONFIG_PHY_STATIC_PRINT -UCONFIG_CUSTOMER_BOARD_SUPPORT \ > > -UCONFIG_A3700 -UA3900 -UA80X0 -UA70X0 -DTRUE $files > > Do not forget to also update commit message. Yes, patman extracts and creates the patch description from the commit. > > And btw, commit messages has on each line some leading spaces which is > not probably intended. That was intentional to make the commit description (and patch description) more readable. Is it not recommended? > > > 3. Manually change license to SPDX-License-Identifier > >(upstream license in upstream github repository contains long > > license > >texts and U-Boot is using just SPDX-License-Identifier. > > > > After applying this patch, a38x ddr3 ddr4 code in upstream Marvell > > github > > repository and in U-Boot would be fully identical. So in future applying > > above steps could be used to sync code again. > > > > The only change in this patch are: > > - Removal of common board_topology_map code using ifdefs in mv_ddr_brd.c > > - Some fixes with include files. > > - Some basic type defines (original from ATF headers) in mv_ddr_plat.c > > > > Reference: > > "ddr: marvell: a38x: Sync code with Marvell mv-ddr-marvell repository" > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > Signed-off-by: Tony Dinh > > --- > > > > Changes in v2: > > - Modified the filter scrip to explicitly include ARMADA_38X code > > and exclude ARMADA_39X code; also remove 64BIT code. Reran it on > > drivers/ddr/marvell/a38x/ > > - Updated script > > files=drivers/ddr/marvell/a38x/* > > sed 's/#if defined(CONFIG_ARMADA_38X) || defined(CONFIG_ARMADA_39X)/#ifdef > > TRUE/' -i $files > > You do not need this sed anymore. CONFIG_ARMADA_39X is explicitly > removed and CONFIG_ARMADA_38X already handled by unifdef. Thanks, I was not sure if unifdef works in that "OR" condition. I will update the commit message. > > > unifdef -m -UMV_DDR -UMV_DDR_ATF -UCONFIG_APN806 \ > > -UCONFIG_MC_STATIC -UCONFIG_MC_STATIC_PRINT > > -UCONFIG_PHY_STATIC \ > > -UCONFIG_PHY_STATIC_PRINT -UCONFIG_CUSTOMER_BOARD_SUPPORT \ > > -UCONFIG_A3700 -UA3900 -UA80X0 -UA70X0 -DCONFIG_ARMADA_38X > > -UCONFIG_ARMADA_39X \ > > -UCONFIG_64BIT $files > > - Remove more dead code files > > - Correct SPDX license header > > > > drivers/ddr/marvell/a38x/Makefile |8 + > > drivers/ddr/marvell/a38x/ddr3_debug.c | 120 + > > drivers/ddr/marvell/a38x/ddr3_init.c | 25 + > > drivers/ddr/marvell/a38x/ddr3_init.h | 14 + > > drivers/ddr/marvell/a38x/ddr3_logging_def.h | 27 + > > drivers/ddr/marvell/a38x/ddr3_training.c | 131 + > > drivers/ddr/marvell/a38x/ddr3_training_bist.c | 12 + > > .../a38x/ddr3_training_centralization.c |4 + > > drivers/ddr/marvell/a38x/ddr3_training_db.c | 212 ++ > > drivers/ddr/marvell/a38x/ddr3_training_ip.h | 17 + > > .../ddr/marvell/a38x/ddr3_training_ip_db.h| 61 + > > .../marvell/a38x/ddr3_training_ip_engine.c| 145 + > > .../ddr/marvell/a38x/ddr3_training_ip_flow.h |5 + > > .../ddr/marvell/a38x/ddr3_training_leveling.c | 135 + > > drivers/ddr/marvell/a38x/dram_if.h|
Re: [PATCH] ddr: marvell: a38x: Add support for DDR4 from Marvell mv-ddr-marvell repository
On Mon, Jan 16, 2023 at 4:33 PM Tony Dinh wrote:
>
> Hi all,
>
> On Sat, Jan 14, 2023 at 1:45 PM Tony Dinh wrote:
> >
> > Hi Pali & Tom,
> >
> > On Sat, Jan 14, 2023 at 12:06 PM Pali Rohár wrote:
> > >
> > > On Saturday 14 January 2023 15:03:41 Tom Rini wrote:
> > > > On Sat, Jan 14, 2023 at 07:51:00PM +0100, Pali Rohár wrote:
> > > > > On Friday 13 January 2023 21:00:21 Tom Rini wrote:
> > > > > > On Sat, Jan 14, 2023 at 02:41:32AM +0100, Pali Rohár wrote:
> > > > > > > On Friday 13 January 2023 16:38:55 Tony Dinh wrote:
> > > > > > > > @@ -16,4 +19,9 @@ obj-$(CONFIG_SPL_BUILD) +=
> > > > > > > > mv_ddr_build_message.o
> > > > > > > > obj-$(CONFIG_SPL_BUILD) += mv_ddr_common.o
> > > > > > > > obj-$(CONFIG_SPL_BUILD) += mv_ddr_spd.o
> > > > > > > > obj-$(CONFIG_SPL_BUILD) += mv_ddr_topology.o
> > > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_mpr_pda_if.o
> > > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training.o
> > > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training_calibration.o
> > > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training_db.o
> > > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training_leveling.o
> > > > > > > > obj-$(CONFIG_SPL_BUILD) += xor.o
> > > > > > >
> > > > > > > And all these new files are ddr4 specific, so should be wrapped
> > > > > > > in makefile section:
> > > > > > > ifdef CONFIG_DDR4
> > > > > >
> > > > > > Looking at the Makefile in question, I think we might want to make
> > > > > > the
> > > > > > whole thing ifdef CONFIG_SPL_BUILD ... endif and then more finely
> > > > > > control building of what objects are built. Perhaps:
> > > > > > drivers/Makefile:obj-$(CONFIG_ARMADA_38X) += ddr/marvell/a38x/
> > > > > > should only be for SPL instead, even?
> > > > >
> > > > > Some cleanup like this can be done. But it is related to DDR4 support
> > > > > and is mostly independent of it. So lets do it after having DDR4
> > > > > there.
> > > >
> > > > We're going to also want to not build the DDR3 code on the DDR4
> > > > platforms, right? A little clean up would make adding the DDR4 code a
> > > > bit cleaner for both cases. It's not a hard no, if someone really wants
> > > > to do the clean-up after.
> > >
> > > I can look at it _after_ all other stuff is done and merged.
> >
> > Thanks for the review and comments! and thanks Pali in advance for the
> > Makefile improvement after. I will submit the V2 patches to fix the
> > dead code and other editorial issues per Pali's review.
>
> Am I correct in assuming that the preferred license header is
> // SPDX-License-Identifier: GPL-2.0
>
> and _not_
> /* SPDX-License-Identifier: GPL-2.0 */
>
> Or does it not matter which form we use as long as it is consistent in an
> area?
NVM, I was scratching my head why patman kept warning me for using one
form or the others!
/Licenses/README
The SPDX license identifier is added in the form of a comment. The comment
style depends on the file type::
C source: // SPDX-License-Identifier:
C header: /* SPDX-License-Identifier: */
ASM: /* SPDX-License-Identifier: */
scripts: # SPDX-License-Identifier:
.rst: .. SPDX-License-Identifier:
.dts{i}: // SPDX-License-Identifier:
All the best,
Tony
Re: [PATCH] ddr: marvell: a38x: Add support for DDR4 from Marvell mv-ddr-marvell repository
Hi all, On Sat, Jan 14, 2023 at 1:45 PM Tony Dinh wrote: > > Hi Pali & Tom, > > On Sat, Jan 14, 2023 at 12:06 PM Pali Rohár wrote: > > > > On Saturday 14 January 2023 15:03:41 Tom Rini wrote: > > > On Sat, Jan 14, 2023 at 07:51:00PM +0100, Pali Rohár wrote: > > > > On Friday 13 January 2023 21:00:21 Tom Rini wrote: > > > > > On Sat, Jan 14, 2023 at 02:41:32AM +0100, Pali Rohár wrote: > > > > > > On Friday 13 January 2023 16:38:55 Tony Dinh wrote: > > > > > > > @@ -16,4 +19,9 @@ obj-$(CONFIG_SPL_BUILD) += > > > > > > > mv_ddr_build_message.o > > > > > > > obj-$(CONFIG_SPL_BUILD) += mv_ddr_common.o > > > > > > > obj-$(CONFIG_SPL_BUILD) += mv_ddr_spd.o > > > > > > > obj-$(CONFIG_SPL_BUILD) += mv_ddr_topology.o > > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_mpr_pda_if.o > > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training.o > > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training_calibration.o > > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training_db.o > > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training_leveling.o > > > > > > > obj-$(CONFIG_SPL_BUILD) += xor.o > > > > > > > > > > > > And all these new files are ddr4 specific, so should be wrapped in > > > > > > makefile section: > > > > > > ifdef CONFIG_DDR4 > > > > > > > > > > Looking at the Makefile in question, I think we might want to make the > > > > > whole thing ifdef CONFIG_SPL_BUILD ... endif and then more finely > > > > > control building of what objects are built. Perhaps: > > > > > drivers/Makefile:obj-$(CONFIG_ARMADA_38X) += ddr/marvell/a38x/ > > > > > should only be for SPL instead, even? > > > > > > > > Some cleanup like this can be done. But it is related to DDR4 support > > > > and is mostly independent of it. So lets do it after having DDR4 there. > > > > > > We're going to also want to not build the DDR3 code on the DDR4 > > > platforms, right? A little clean up would make adding the DDR4 code a > > > bit cleaner for both cases. It's not a hard no, if someone really wants > > > to do the clean-up after. > > > > I can look at it _after_ all other stuff is done and merged. > > Thanks for the review and comments! and thanks Pali in advance for the > Makefile improvement after. I will submit the V2 patches to fix the > dead code and other editorial issues per Pali's review. Am I correct in assuming that the preferred license header is // SPDX-License-Identifier: GPL-2.0 and _not_ /* SPDX-License-Identifier: GPL-2.0 */ Or does it not matter which form we use as long as it is consistent in an area? Thanks, Tony
Re: [bug] timer: orion-timer: static variable patch breaks armada-388-clearfog boot
Hi Martin, On Sat, Jan 14, 2023 at 9:31 PM Martin Rowe wrote: > > Hi, > > Commit 5387b093 was a fix for early_init_done causing issues on Pogo > v4 [1]. The fix breaks armada-388-clearfog because the boot hangs > indefinitely. > > It appears that the cause is an infinite loop in __udelay due to > get_ticks() always returning 0. After adding some printf statements it > became apparent that the timer was never getting initialised. > > git-blame identified the "timer: orion-timer: Fix problem with early > static variable" patch as a likely issue. Reverting the commit > restores boot for armada-388-clearfog. Did you build this clearfog board as is? i.e. did you make any change in the clearfog_defconfig? Thanks, Tony Tony > > Patching the issue is a bit beyond me without understanding the Pogo > v4 issue, but I'm happy to test any patches that are developed. > > Regards > > Martin > > [1] https://lore.kernel.org/u-boot/20221221091849.1018783-1...@denx.de/
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
On Sat, Jan 14, 2023 at 2:53 PM Pali Rohár wrote: > > On Saturday 14 January 2023 14:48:28 Tony Dinh wrote: > > Hi Pali, > > > > On Sat, Jan 14, 2023 at 2:12 PM Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > On Sat, Jan 14, 2023 at 1:44 PM Pali Rohár wrote: > > > > > > > > On Saturday 14 January 2023 13:35:08 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > On Fri, Jan 13, 2023 at 5:32 PM Pali Rohár wrote: > > > > > > > > > > > > On Wednesday 11 January 2023 21:56:41 Pali Rohár wrote: > > > > > > > On Wednesday 11 January 2023 12:44:45 Tony Dinh wrote: > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > On Wed, Jan 11, 2023 at 12:04 AM Pali Rohár > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Tuesday 10 January 2023 21:07:45 Tony Dinh wrote: > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > > > > > I got burned for being lazy :) it turned out that the mix > > > > > > > > > > of #ifdef > > > > > > > > > > and #if defined was the problem. Just stepped away and came > > > > > > > > > > back for a > > > > > > > > > > few minutes and I can see that I just need to define the > > > > > > > > > > CONFIG_DDR4 > > > > > > > > > > properly in arch/arm/mach-mvebu/Kconfig and build it to > > > > > > > > > > pass the > > > > > > > > > > CONFIG_DDR4 stuff. > > > > > > > > > > > > > > > > > > > > One more small hurdle after that was > > > > > > > > > > CONFIG_USE_PRIVATE_LIBGCC must be > > > > > > > > > > undefined for it to build (so I am using > > > > > > > > > > /usr/lib/gcc/arm-linux-gnueabi/10/libgcc.a, and not using > > > > > > > > > > arch/arm/lib/lib.a) > > > > > > > > > > > > > > > > > > Hello! It is normally a good idea to unset > > > > > > > > > CONFIG_USE_PRIVATE_LIBGCC > > > > > > > > > unless you have compiled gcc for target CPU. > > > > > > > > > > > > > > > > CONFIG_USE_PRIVATE_LIBGCC was set as a default for ARM target, > > > > > > > > since > > > > > > > > u-boot has arch/arm/lib/lib.a. But using arch/arm/lib/lib.a I > > > > > > > > got > > > > > > > > several build errors like these: > > > > > > > > > > > > > > > > ld.bfd: > > > > > > > > drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.o: in > > > > > > > > function `mv_ddr4_copt_get': > > > > > > > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: > > > > > > > > undefined reference to `__aeabi_i2d' > > > > > > > > ld.bfd: > > > > > > > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: > > > > > > > > undefined reference to `__aeabi_dmul' > > > > > > > > ld.bfd: > > > > > > > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: > > > > > > > > undefined reference to `__aeabi_d2uiz' > > > > > > > > > > > > > > This looks like a bug in that training code. I would need to see > > > > > > > source > > > > > > > code, so I can figure out how to fix it. > > > > > > > > > > > > Have you solved this issue? Or if not, can you show what you had on > > > > > > that > > > > > > problematic line 809? > > > > > > > > > > No, I have not and actually have no idea what that code does! And I > > > > > thought you recognized the error, so I submitted the DDR4 patch so you > > > > > can compile and see the error. Here is the code snipet, the error is > > > > > now at 717. > > > > > > > > &g
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hi Pali,
On Sat, Jan 14, 2023 at 2:12 PM Tony Dinh wrote:
>
> Hi Pali,
>
> On Sat, Jan 14, 2023 at 1:44 PM Pali Rohár wrote:
> >
> > On Saturday 14 January 2023 13:35:08 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Fri, Jan 13, 2023 at 5:32 PM Pali Rohár wrote:
> > > >
> > > > On Wednesday 11 January 2023 21:56:41 Pali Rohár wrote:
> > > > > On Wednesday 11 January 2023 12:44:45 Tony Dinh wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > On Wed, Jan 11, 2023 at 12:04 AM Pali Rohár wrote:
> > > > > > >
> > > > > > > On Tuesday 10 January 2023 21:07:45 Tony Dinh wrote:
> > > > > > > > Hi Pali,
> > > > > > > >
> > > > > > > > I got burned for being lazy :) it turned out that the mix of
> > > > > > > > #ifdef
> > > > > > > > and #if defined was the problem. Just stepped away and came
> > > > > > > > back for a
> > > > > > > > few minutes and I can see that I just need to define the
> > > > > > > > CONFIG_DDR4
> > > > > > > > properly in arch/arm/mach-mvebu/Kconfig and build it to pass the
> > > > > > > > CONFIG_DDR4 stuff.
> > > > > > > >
> > > > > > > > One more small hurdle after that was CONFIG_USE_PRIVATE_LIBGCC
> > > > > > > > must be
> > > > > > > > undefined for it to build (so I am using
> > > > > > > > /usr/lib/gcc/arm-linux-gnueabi/10/libgcc.a, and not using
> > > > > > > > arch/arm/lib/lib.a)
> > > > > > >
> > > > > > > Hello! It is normally a good idea to unset
> > > > > > > CONFIG_USE_PRIVATE_LIBGCC
> > > > > > > unless you have compiled gcc for target CPU.
> > > > > >
> > > > > > CONFIG_USE_PRIVATE_LIBGCC was set as a default for ARM target, since
> > > > > > u-boot has arch/arm/lib/lib.a. But using arch/arm/lib/lib.a I got
> > > > > > several build errors like these:
> > > > > >
> > > > > > ld.bfd: drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.o: in
> > > > > > function `mv_ddr4_copt_get':
> > > > > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809:
> > > > > > undefined reference to `__aeabi_i2d'
> > > > > > ld.bfd:
> > > > > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809:
> > > > > > undefined reference to `__aeabi_dmul'
> > > > > > ld.bfd:
> > > > > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809:
> > > > > > undefined reference to `__aeabi_d2uiz'
> > > > >
> > > > > This looks like a bug in that training code. I would need to see
> > > > > source
> > > > > code, so I can figure out how to fix it.
> > > >
> > > > Have you solved this issue? Or if not, can you show what you had on that
> > > > problematic line 809?
> > >
> > > No, I have not and actually have no idea what that code does! And I
> > > thought you recognized the error, so I submitted the DDR4 patch so you
> > > can compile and see the error. Here is the code snipet, the error is
> > > now at 717.
> > >
> > > # grep -n10 PBS_VALUE_FACTOR
> > > /usr/src/u-boot-master/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c
> > > 704- u8 copt_val;
> > > 705- u8 dq_idx;
> > > 706- u8 center_zone_max_low = 0;
> > > 707- u8 center_zone_min_high = 128;
> > > 708- u8 vw_zone_max_low = 0;
> > > 709- u8 vw_zone_min_high = 128;
> > > 710- u8 min_vw = 63; /* minimum valid window between all bits */
> > > 711- u8 center_low_el;
> > > 712- u8 center_high_el;
> > > 713-
> > > 714: /* lambda calculated as D * PBS_VALUE_FACTOR / d */
> > > 715- //printf("Copt::Debug::\t");
> > > 716- for (dq_idx = 0; dq_idx < 8; dq_idx++) {
> > > 717- center_per_dq[dq_idx] = 0.5 * (vw_h[dq_idx] + vw_l[dq_idx]);
> > > 718- vw_per_dq[dq_idx] = 1 + (vw_h[dq_idx] - vw_l[dq_idx]);
> > > 719- if (min_vw > vw_per_dq[dq_idx])
> > > 720- min_vw = vw_per_dq[dq_idx];
> > > 721- }
> > &g
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hi Pali,
On Sat, Jan 14, 2023 at 1:44 PM Pali Rohár wrote:
>
> On Saturday 14 January 2023 13:35:08 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Fri, Jan 13, 2023 at 5:32 PM Pali Rohár wrote:
> > >
> > > On Wednesday 11 January 2023 21:56:41 Pali Rohár wrote:
> > > > On Wednesday 11 January 2023 12:44:45 Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Wed, Jan 11, 2023 at 12:04 AM Pali Rohár wrote:
> > > > > >
> > > > > > On Tuesday 10 January 2023 21:07:45 Tony Dinh wrote:
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > I got burned for being lazy :) it turned out that the mix of
> > > > > > > #ifdef
> > > > > > > and #if defined was the problem. Just stepped away and came back
> > > > > > > for a
> > > > > > > few minutes and I can see that I just need to define the
> > > > > > > CONFIG_DDR4
> > > > > > > properly in arch/arm/mach-mvebu/Kconfig and build it to pass the
> > > > > > > CONFIG_DDR4 stuff.
> > > > > > >
> > > > > > > One more small hurdle after that was CONFIG_USE_PRIVATE_LIBGCC
> > > > > > > must be
> > > > > > > undefined for it to build (so I am using
> > > > > > > /usr/lib/gcc/arm-linux-gnueabi/10/libgcc.a, and not using
> > > > > > > arch/arm/lib/lib.a)
> > > > > >
> > > > > > Hello! It is normally a good idea to unset CONFIG_USE_PRIVATE_LIBGCC
> > > > > > unless you have compiled gcc for target CPU.
> > > > >
> > > > > CONFIG_USE_PRIVATE_LIBGCC was set as a default for ARM target, since
> > > > > u-boot has arch/arm/lib/lib.a. But using arch/arm/lib/lib.a I got
> > > > > several build errors like these:
> > > > >
> > > > > ld.bfd: drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.o: in
> > > > > function `mv_ddr4_copt_get':
> > > > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809:
> > > > > undefined reference to `__aeabi_i2d'
> > > > > ld.bfd:
> > > > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809:
> > > > > undefined reference to `__aeabi_dmul'
> > > > > ld.bfd:
> > > > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809:
> > > > > undefined reference to `__aeabi_d2uiz'
> > > >
> > > > This looks like a bug in that training code. I would need to see source
> > > > code, so I can figure out how to fix it.
> > >
> > > Have you solved this issue? Or if not, can you show what you had on that
> > > problematic line 809?
> >
> > No, I have not and actually have no idea what that code does! And I
> > thought you recognized the error, so I submitted the DDR4 patch so you
> > can compile and see the error. Here is the code snipet, the error is
> > now at 717.
> >
> > # grep -n10 PBS_VALUE_FACTOR
> > /usr/src/u-boot-master/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c
> > 704- u8 copt_val;
> > 705- u8 dq_idx;
> > 706- u8 center_zone_max_low = 0;
> > 707- u8 center_zone_min_high = 128;
> > 708- u8 vw_zone_max_low = 0;
> > 709- u8 vw_zone_min_high = 128;
> > 710- u8 min_vw = 63; /* minimum valid window between all bits */
> > 711- u8 center_low_el;
> > 712- u8 center_high_el;
> > 713-
> > 714: /* lambda calculated as D * PBS_VALUE_FACTOR / d */
> > 715- //printf("Copt::Debug::\t");
> > 716- for (dq_idx = 0; dq_idx < 8; dq_idx++) {
> > 717- center_per_dq[dq_idx] = 0.5 * (vw_h[dq_idx] + vw_l[dq_idx]);
> > 718- vw_per_dq[dq_idx] = 1 + (vw_h[dq_idx] - vw_l[dq_idx]);
> > 719- if (min_vw > vw_per_dq[dq_idx])
> > 720- min_vw = vw_per_dq[dq_idx];
> > 721- }
> > 722-
> > 723- /* calculate center zone */
> > 724- for (dq_idx = 0; dq_idx < 8; dq_idx++) {
>
> Haha! That is pretty simple. On line 717 you have fractional number 0.5
> which is represented by floating point and all numeric operation on that
> line are done as floating point.
>
> U-Boot and kernel does not floating point HW and instruct compiler to
> replace all floating point operations by function calls (which implement
> software floating point support).
>
> U-Boot (for very good reas
Re: [PATCH] ddr: marvell: a38x: Add support for DDR4 from Marvell mv-ddr-marvell repository
Hi Pali & Tom, On Sat, Jan 14, 2023 at 12:06 PM Pali Rohár wrote: > > On Saturday 14 January 2023 15:03:41 Tom Rini wrote: > > On Sat, Jan 14, 2023 at 07:51:00PM +0100, Pali Rohár wrote: > > > On Friday 13 January 2023 21:00:21 Tom Rini wrote: > > > > On Sat, Jan 14, 2023 at 02:41:32AM +0100, Pali Rohár wrote: > > > > > On Friday 13 January 2023 16:38:55 Tony Dinh wrote: > > > > > > @@ -16,4 +19,9 @@ obj-$(CONFIG_SPL_BUILD) += mv_ddr_build_message.o > > > > > > obj-$(CONFIG_SPL_BUILD) += mv_ddr_common.o > > > > > > obj-$(CONFIG_SPL_BUILD) += mv_ddr_spd.o > > > > > > obj-$(CONFIG_SPL_BUILD) += mv_ddr_topology.o > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_mpr_pda_if.o > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training.o > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training_calibration.o > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training_db.o > > > > > > +obj-$(CONFIG_SPL_BUILD) += mv_ddr4_training_leveling.o > > > > > > obj-$(CONFIG_SPL_BUILD) += xor.o > > > > > > > > > > And all these new files are ddr4 specific, so should be wrapped in > > > > > makefile section: > > > > > ifdef CONFIG_DDR4 > > > > > > > > Looking at the Makefile in question, I think we might want to make the > > > > whole thing ifdef CONFIG_SPL_BUILD ... endif and then more finely > > > > control building of what objects are built. Perhaps: > > > > drivers/Makefile:obj-$(CONFIG_ARMADA_38X) += ddr/marvell/a38x/ > > > > should only be for SPL instead, even? > > > > > > Some cleanup like this can be done. But it is related to DDR4 support > > > and is mostly independent of it. So lets do it after having DDR4 there. > > > > We're going to also want to not build the DDR3 code on the DDR4 > > platforms, right? A little clean up would make adding the DDR4 code a > > bit cleaner for both cases. It's not a hard no, if someone really wants > > to do the clean-up after. > > I can look at it _after_ all other stuff is done and merged. Thanks for the review and comments! and thanks Pali in advance for the Makefile improvement after. I will submit the V2 patches to fix the dead code and other editorial issues per Pali's review. All the best, Tony
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hi Pali,
On Fri, Jan 13, 2023 at 5:32 PM Pali Rohár wrote:
>
> On Wednesday 11 January 2023 21:56:41 Pali Rohár wrote:
> > On Wednesday 11 January 2023 12:44:45 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Wed, Jan 11, 2023 at 12:04 AM Pali Rohár wrote:
> > > >
> > > > On Tuesday 10 January 2023 21:07:45 Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > I got burned for being lazy :) it turned out that the mix of #ifdef
> > > > > and #if defined was the problem. Just stepped away and came back for a
> > > > > few minutes and I can see that I just need to define the CONFIG_DDR4
> > > > > properly in arch/arm/mach-mvebu/Kconfig and build it to pass the
> > > > > CONFIG_DDR4 stuff.
> > > > >
> > > > > One more small hurdle after that was CONFIG_USE_PRIVATE_LIBGCC must be
> > > > > undefined for it to build (so I am using
> > > > > /usr/lib/gcc/arm-linux-gnueabi/10/libgcc.a, and not using
> > > > > arch/arm/lib/lib.a)
> > > >
> > > > Hello! It is normally a good idea to unset CONFIG_USE_PRIVATE_LIBGCC
> > > > unless you have compiled gcc for target CPU.
> > >
> > > CONFIG_USE_PRIVATE_LIBGCC was set as a default for ARM target, since
> > > u-boot has arch/arm/lib/lib.a. But using arch/arm/lib/lib.a I got
> > > several build errors like these:
> > >
> > > ld.bfd: drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.o: in
> > > function `mv_ddr4_copt_get':
> > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809:
> > > undefined reference to `__aeabi_i2d'
> > > ld.bfd:
> > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809:
> > > undefined reference to `__aeabi_dmul'
> > > ld.bfd:
> > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809:
> > > undefined reference to `__aeabi_d2uiz'
> >
> > This looks like a bug in that training code. I would need to see source
> > code, so I can figure out how to fix it.
>
> Have you solved this issue? Or if not, can you show what you had on that
> problematic line 809?
No, I have not and actually have no idea what that code does! And I
thought you recognized the error, so I submitted the DDR4 patch so you
can compile and see the error. Here is the code snipet, the error is
now at 717.
# grep -n10 PBS_VALUE_FACTOR
/usr/src/u-boot-master/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c
704- u8 copt_val;
705- u8 dq_idx;
706- u8 center_zone_max_low = 0;
707- u8 center_zone_min_high = 128;
708- u8 vw_zone_max_low = 0;
709- u8 vw_zone_min_high = 128;
710- u8 min_vw = 63; /* minimum valid window between all bits */
711- u8 center_low_el;
712- u8 center_high_el;
713-
714: /* lambda calculated as D * PBS_VALUE_FACTOR / d */
715- //printf("Copt::Debug::\t");
716- for (dq_idx = 0; dq_idx < 8; dq_idx++) {
717- center_per_dq[dq_idx] = 0.5 * (vw_h[dq_idx] + vw_l[dq_idx]);
718- vw_per_dq[dq_idx] = 1 + (vw_h[dq_idx] - vw_l[dq_idx]);
719- if (min_vw > vw_per_dq[dq_idx])
720- min_vw = vw_per_dq[dq_idx];
721- }
722-
723- /* calculate center zone */
724- for (dq_idx = 0; dq_idx < 8; dq_idx++) {
Here are the build errors with the current code.
rm -f spl/common/spl/built-in.o; ar cDPrsT spl/common/spl/built-in.o
spl/common/spl/spl.o spl/common/spl/spl_bootrom.o
spl/common/spl/spl_spi.o
( cd spl && ld.bfd -T u-boot-spl.lds --gc-sections -Bstatic
--gc-sections --no-dynamic-linker --build-id=none -Ttext 0x4030
arch/arm/cpu/armv7/start.o --whole-archive
arch/arm/mach-mvebu/built-in.o arch/arm/cpu/armv7/built-in.o
arch/arm/cpu/built-in.o arch/arm/lib/built-in.o
board/thecus/n2350/built-in.o common/spl/built-in.o
common/init/built-in.o boot/built-in.o common/built-in.o
cmd/built-in.o env/built-in.o lib/built-in.o disk/built-in.o
drivers/built-in.o dts/built-in.o fs/built-in.o --no-whole-archive
arch/arm/lib/eabi_compat.o arch/arm/lib/lib.a -Map u-boot-spl.map -o
u-boot-spl )
ld.bfd: drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.o: in
function `mv_ddr4_copt_get':
/usr/src/u-boot-master/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:717:
undefined reference to `__aeabi_i2d'
ld.bfd:
/usr/src/u-boot-master/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:717:
undefined reference to `__aeabi_dmul'
ld.bfd:
/usr/src/u-boot-master/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:717:
undefined reference to `__aeabi_d2uiz'
ld.bfd:
/usr/src/u-boot-master/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:757:
undefined reference to `__aeabi_i2d'
ld.bfd:
/usr/s
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hi Stefan, On Thu, Jan 12, 2023 at 10:13 PM Stefan Roese wrote: > > Hi Tony, > > (added Tom to Cc) > > On 1/13/23 02:40, Tony Dinh wrote: > > Hi Stefan, > > > > On Wed, Jan 11, 2023 at 12:56 PM Pali Rohár wrote: > >> > >> On Wednesday 11 January 2023 12:44:45 Tony Dinh wrote: > >>> Hi Pali, > >>> > >>> On Wed, Jan 11, 2023 at 12:04 AM Pali Rohár wrote: > >>>> > >>>> On Tuesday 10 January 2023 21:07:45 Tony Dinh wrote: > >>>>> Hi Pali, > >>>>> > >>>>> I got burned for being lazy :) it turned out that the mix of #ifdef > >>>>> and #if defined was the problem. Just stepped away and came back for a > >>>>> few minutes and I can see that I just need to define the CONFIG_DDR4 > >>>>> properly in arch/arm/mach-mvebu/Kconfig and build it to pass the > >>>>> CONFIG_DDR4 stuff. > >>>>> > >>>>> One more small hurdle after that was CONFIG_USE_PRIVATE_LIBGCC must be > >>>>> undefined for it to build (so I am using > >>>>> /usr/lib/gcc/arm-linux-gnueabi/10/libgcc.a, and not using > >>>>> arch/arm/lib/lib.a) > >>>> > >>>> Hello! It is normally a good idea to unset CONFIG_USE_PRIVATE_LIBGCC > >>>> unless you have compiled gcc for target CPU. > >>> > >>> CONFIG_USE_PRIVATE_LIBGCC was set as a default for ARM target, since > >>> u-boot has arch/arm/lib/lib.a. But using arch/arm/lib/lib.a I got > >>> several build errors like these: > >>> > >>> ld.bfd: drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.o: in > >>> function `mv_ddr4_copt_get': > >>> /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: > >>> undefined reference to `__aeabi_i2d' > >>> ld.bfd: > >>> /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: > >>> undefined reference to `__aeabi_dmul' > >>> ld.bfd: > >>> /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: > >>> undefined reference to `__aeabi_d2uiz' > >> > >> This looks like a bug in that training code. I would need to see source > >> code, so I can figure out how to fix it. > >> > >>> Perhaps this is something that needs to be looked at. > >>> > >>>> > >>>>> But Marvell DDR4 is working fine! Please see the log. > >>>> > >>>> Nice! So you can send patches for that board to list. > >>> > >>> Sure I will for the N2350 board. How will we be handling the Marvell > >>> DDR code resync? > >> > >> Send that DDR code resync in one patch... and saying e.g. adding support > >> for DDR4 from Marvell repo. > > > > The DDR4 patch is quite large, about 272K. Will it get rejected from > > ML because it is over the 100K limit? > > Usually Tom as the mailing list maintainer will get informed about such > mails and if he decides how to handle such huge mails. If this can't be > handled differently, which is probably the case with such a sync to a > repository, then the mail will get sent to the list when he "releases" > such mails. > > > # git format-patch -1 HEAD > > # wc 0001-ddr-marvell-a38x-Add-support-for-DDR4-from-Marvell-m.patch > >7962 35309 277976 > > 0001-ddr-marvell-a38x-Add-support-for-DDR4-from-Marvell-m.patch > > > > How would you like to receive the patch? Would you like 2 emails (1st > > go to the ML without the patch, 2nd with the patch but not to the ML)? > > As a normal mail / patch please. Will do that! > > Side note: Does your patch /sync only touch the currently not supported > DDR4 handling? If changes also include DDR3 then this should be tested > on the boards currently using this code very intensive. All A38x board > maintainers should be pointed to such new changes in this case. Yes, indeed. I plan to do at least a DDR3 regression test with the Synology DS116 board (Armada 385, DDR3). The existing A38x boards do not have CONFIG_DDR4 enabled, so the DDR3 code looks to be the same, AFAITC. The patch should be reviewed by Pali and Marek to confirm that on paper, at least. But preferably, all A38x board maintainers should be aware. I will grep for the list of the A38x maintainers, and send directly to them (or if you already have such a list please let me know). Thanks, Tony > > Thanks, > Stefan >
Re: patman: ModuleNotFoundError
Hi Maxim, On Thu, Jan 12, 2023 at 5:22 PM Maxim Cournoyer wrote: > > Hi, > > - Original Message - > > From: "Tony Dinh" > > To: "Simon Glass" , "Maxim Cournoyer" > > , "U-Boot Mailing List" > > > > Cc: "Stefan Roese" > > Sent: Thursday, January 12, 2023 7:07:20 PM > > Subject: patman: ModuleNotFoundError > > > Hi Simon, > > > > I've updated to the latest u-boot master, and saw this error. > > > > ./tools/patman/patman --help > > > > Traceback (most recent call last): > > File "/usr/src/u-boot-master/./tools/patman/patman", line 23, in > >from patman import func_test > > File "/usr/src/u-boot-master/tools/patman/../patman/func_test.py", > > line 31, in > >from patman import status > > File "/usr/src/u-boot-master/tools/patman/../patman/status.py", line > > 17, in > >import requests > > ModuleNotFoundError: No module named 'requests' > > > > My Linux host is Debian bullseye (11.3). Am I missing some newly > > required Python packages? I have not run patman since about 3 months > > ago. > > patman requires pygit2 and requests, yes. Thanks Maxim! works fine after installing pygit2 and requests. All the best, Tony > HTH, > > Maxim
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hi Stefan, On Wed, Jan 11, 2023 at 12:56 PM Pali Rohár wrote: > > On Wednesday 11 January 2023 12:44:45 Tony Dinh wrote: > > Hi Pali, > > > > On Wed, Jan 11, 2023 at 12:04 AM Pali Rohár wrote: > > > > > > On Tuesday 10 January 2023 21:07:45 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > I got burned for being lazy :) it turned out that the mix of #ifdef > > > > and #if defined was the problem. Just stepped away and came back for a > > > > few minutes and I can see that I just need to define the CONFIG_DDR4 > > > > properly in arch/arm/mach-mvebu/Kconfig and build it to pass the > > > > CONFIG_DDR4 stuff. > > > > > > > > One more small hurdle after that was CONFIG_USE_PRIVATE_LIBGCC must be > > > > undefined for it to build (so I am using > > > > /usr/lib/gcc/arm-linux-gnueabi/10/libgcc.a, and not using > > > > arch/arm/lib/lib.a) > > > > > > Hello! It is normally a good idea to unset CONFIG_USE_PRIVATE_LIBGCC > > > unless you have compiled gcc for target CPU. > > > > CONFIG_USE_PRIVATE_LIBGCC was set as a default for ARM target, since > > u-boot has arch/arm/lib/lib.a. But using arch/arm/lib/lib.a I got > > several build errors like these: > > > > ld.bfd: drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.o: in > > function `mv_ddr4_copt_get': > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: > > undefined reference to `__aeabi_i2d' > > ld.bfd: > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: > > undefined reference to `__aeabi_dmul' > > ld.bfd: > > /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: > > undefined reference to `__aeabi_d2uiz' > > This looks like a bug in that training code. I would need to see source > code, so I can figure out how to fix it. > > > Perhaps this is something that needs to be looked at. > > > > > > > > > But Marvell DDR4 is working fine! Please see the log. > > > > > > Nice! So you can send patches for that board to list. > > > > Sure I will for the N2350 board. How will we be handling the Marvell > > DDR code resync? > > Send that DDR code resync in one patch... and saying e.g. adding support > for DDR4 from Marvell repo. The DDR4 patch is quite large, about 272K. Will it get rejected from ML because it is over the 100K limit? # git format-patch -1 HEAD # wc 0001-ddr-marvell-a38x-Add-support-for-DDR4-from-Marvell-m.patch 7962 35309 277976 0001-ddr-marvell-a38x-Add-support-for-DDR4-from-Marvell-m.patch How would you like to receive the patch? Would you like 2 emails (1st go to the ML without the patch, 2nd with the patch but not to the ML)? Thanks, Tony
patman: ModuleNotFoundError
Hi Simon, I've updated to the latest u-boot master, and saw this error. ./tools/patman/patman --help Traceback (most recent call last): File "/usr/src/u-boot-master/./tools/patman/patman", line 23, in from patman import func_test File "/usr/src/u-boot-master/tools/patman/../patman/func_test.py", line 31, in from patman import status File "/usr/src/u-boot-master/tools/patman/../patman/status.py", line 17, in import requests ModuleNotFoundError: No module named 'requests' My Linux host is Debian bullseye (11.3). Am I missing some newly required Python packages? I have not run patman since about 3 months ago. Thanks, Tony
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hi Pali, On Wed, Jan 11, 2023 at 12:04 AM Pali Rohár wrote: > > On Tuesday 10 January 2023 21:07:45 Tony Dinh wrote: > > Hi Pali, > > > > On Mon, Jan 9, 2023 at 5:44 PM Tony Dinh wrote: > > > > > > On Mon, Jan 9, 2023 at 5:38 PM Pali Rohár wrote: > > > > > > > > On Monday 09 January 2023 17:35:24 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > On Mon, Jan 9, 2023 at 5:02 PM Pali Rohár wrote: > > > > > > > > > > > > On Monday 09 January 2023 16:55:56 Tony Dinh wrote: > > > > > > > Hi Pali, > > > > > > > > > > > > > > On Wed, Jan 4, 2023 at 1:04 PM Tony Dinh > > > > > > > wrote: > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Wednesday 04 January 2023 23:41:05 Chris Packham wrote: > > > > > > > > > > On Wed, 4 Jan 2023, 8:52 PM Pali Rohár, > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote: > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > > > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > > > > > > > > > > > I'm building a new u-boot for the Thecus N2350 board > > > > > > > > > > > > > (Armada 385 > > > > > > > > > > > > > dual-core 1Ghz 1GB DDR4). The trouble with this board > > > > > > > > > > > > > is DDR4, which > > > > > > > > > > > > > is not currently supported in u-boot (also cc this to > > > > > > > > > > > > > Chris for > > > > > > > > > > > > > commenting about Marvell DDR4 training driver). > > > > > > > > > > > > > > > > > > > > > > > > Yes, ddr4 training code is not in u-boot yet. > > > > > > > > > > > > > > > > > > > > > > > > A38x u-boot ddr driver is in this directory: > > > > > > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x > > > > > > > > > > > > > > > > > > > > > > > > And it is copied from the original marvell driver by > > > > > > > > > > > > stripping non-a38x > > > > > > > > > > > > code and removal of the ddr4 code from the master > > > > > > > > > > > > branch: > > > > > > > > > > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell > > > > > > > > > > > > > > > > > > > > > > > > So you can try to copy code again without stripping > > > > > > > > > > > > ddr4 parts > > > > > > > > > > > > (run git log drivers/ddr/marvell/a38x in u-boot) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > > > > > > > > > > > > > > > > > And adjust u-boot board code for ddr4. > > > > > > > > > > > > > > > > > > > > > > > > I guess it could work but it would be needed to play > > > > > > > > > > > > with it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Last time I looked the MarvellEmbeddedProcessors stuff was > > > > > > > > > > a long way > >
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hi Pali, On Mon, Jan 9, 2023 at 5:44 PM Tony Dinh wrote: > > On Mon, Jan 9, 2023 at 5:38 PM Pali Rohár wrote: > > > > On Monday 09 January 2023 17:35:24 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Mon, Jan 9, 2023 at 5:02 PM Pali Rohár wrote: > > > > > > > > On Monday 09 January 2023 16:55:56 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > On Wed, Jan 4, 2023 at 1:04 PM Tony Dinh wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár wrote: > > > > > > > > > > > > > > On Wednesday 04 January 2023 23:41:05 Chris Packham wrote: > > > > > > > > On Wed, 4 Jan 2023, 8:52 PM Pali Rohár, wrote: > > > > > > > > > > > > > > > > > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote: > > > > > > > > > > Hello! > > > > > > > > > > > > > > > > > > > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > > > > > > > I'm building a new u-boot for the Thecus N2350 board > > > > > > > > > > > (Armada 385 > > > > > > > > > > > dual-core 1Ghz 1GB DDR4). The trouble with this board is > > > > > > > > > > > DDR4, which > > > > > > > > > > > is not currently supported in u-boot (also cc this to > > > > > > > > > > > Chris for > > > > > > > > > > > commenting about Marvell DDR4 training driver). > > > > > > > > > > > > > > > > > > > > Yes, ddr4 training code is not in u-boot yet. > > > > > > > > > > > > > > > > > > > > A38x u-boot ddr driver is in this directory: > > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x > > > > > > > > > > > > > > > > > > > > And it is copied from the original marvell driver by > > > > > > > > > > stripping non-a38x > > > > > > > > > > code and removal of the ddr4 code from the master branch: > > > > > > > > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell > > > > > > > > > > > > > > > > > > > > So you can try to copy code again without stripping ddr4 > > > > > > > > > > parts > > > > > > > > > > (run git log drivers/ddr/marvell/a38x in u-boot) > > > > > > > > > > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > > > > > > > > > > > > > And adjust u-boot board code for ddr4. > > > > > > > > > > > > > > > > > > > > I guess it could work but it would be needed to play with > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > Last time I looked the MarvellEmbeddedProcessors stuff was a > > > > > > > > long way > > > > > > > > behind what Marvell are releasing to customers. That was for > > > > > > > > the newer SoCs > > > > > > > > so maybe the A385 stuff is current. > > > > > > > > > > > > > > About half year ago, MarvellEmbeddedProcessors mv-ddr-marvell and > > > > > > > A3700-utils-marvell were up-to-date and same as the version > > > > > > > distributed > > > > > > > to the Marvell customers. I was cooperating with Marvell to > > > > > > > release all > > > > > > > patches from Marvell Extranet portal to github as opensource and > > > > > > > also to > > > > > > > incorporate github patches from community to their Extranet > > > > > > > version. > > &g
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
On Mon, Jan 9, 2023 at 5:38 PM Pali Rohár wrote: > > On Monday 09 January 2023 17:35:24 Tony Dinh wrote: > > Hi Pali, > > > > On Mon, Jan 9, 2023 at 5:02 PM Pali Rohár wrote: > > > > > > On Monday 09 January 2023 16:55:56 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > On Wed, Jan 4, 2023 at 1:04 PM Tony Dinh wrote: > > > > > > > > > > Hello, > > > > > > > > > > On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár wrote: > > > > > > > > > > > > On Wednesday 04 January 2023 23:41:05 Chris Packham wrote: > > > > > > > On Wed, 4 Jan 2023, 8:52 PM Pali Rohár, wrote: > > > > > > > > > > > > > > > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote: > > > > > > > > > Hello! > > > > > > > > > > > > > > > > > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > > > > > I'm building a new u-boot for the Thecus N2350 board > > > > > > > > > > (Armada 385 > > > > > > > > > > dual-core 1Ghz 1GB DDR4). The trouble with this board is > > > > > > > > > > DDR4, which > > > > > > > > > > is not currently supported in u-boot (also cc this to Chris > > > > > > > > > > for > > > > > > > > > > commenting about Marvell DDR4 training driver). > > > > > > > > > > > > > > > > > > Yes, ddr4 training code is not in u-boot yet. > > > > > > > > > > > > > > > > > > A38x u-boot ddr driver is in this directory: > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x > > > > > > > > > > > > > > > > > > And it is copied from the original marvell driver by > > > > > > > > > stripping non-a38x > > > > > > > > > code and removal of the ddr4 code from the master branch: > > > > > > > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell > > > > > > > > > > > > > > > > > > So you can try to copy code again without stripping ddr4 parts > > > > > > > > > (run git log drivers/ddr/marvell/a38x in u-boot) > > > > > > > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > > > > > > > > > > > And adjust u-boot board code for ddr4. > > > > > > > > > > > > > > > > > > I guess it could work but it would be needed to play with it. > > > > > > > > > > > > > > > > > > > > > > Last time I looked the MarvellEmbeddedProcessors stuff was a long > > > > > > > way > > > > > > > behind what Marvell are releasing to customers. That was for the > > > > > > > newer SoCs > > > > > > > so maybe the A385 stuff is current. > > > > > > > > > > > > About half year ago, MarvellEmbeddedProcessors mv-ddr-marvell and > > > > > > A3700-utils-marvell were up-to-date and same as the version > > > > > > distributed > > > > > > to the Marvell customers. I was cooperating with Marvell to release > > > > > > all > > > > > > patches from Marvell Extranet portal to github as opensource and > > > > > > also to > > > > > > incorporate github patches from community to their Extranet version. > > > > > > Also I was synchronizing u-boot drivers/ddr/marvell/a38x directory > > > > > > with > > > > > > MarvellEmbeddedProcessors version. I do not think that Marvell > > > > > > released > > > > > > something super new in these repositories in last half of year, so I > > > > > > think that the code on MarvellEmbeddedProcessors (for those two > > > > > > repositories) is still up-to-date. > > > > > > > &
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hi Pali, On Mon, Jan 9, 2023 at 5:02 PM Pali Rohár wrote: > > On Monday 09 January 2023 16:55:56 Tony Dinh wrote: > > Hi Pali, > > > > On Wed, Jan 4, 2023 at 1:04 PM Tony Dinh wrote: > > > > > > Hello, > > > > > > On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár wrote: > > > > > > > > On Wednesday 04 January 2023 23:41:05 Chris Packham wrote: > > > > > On Wed, 4 Jan 2023, 8:52 PM Pali Rohár, wrote: > > > > > > > > > > > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote: > > > > > > > Hello! > > > > > > > > > > > > > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > I'm building a new u-boot for the Thecus N2350 board (Armada 385 > > > > > > > > dual-core 1Ghz 1GB DDR4). The trouble with this board is DDR4, > > > > > > > > which > > > > > > > > is not currently supported in u-boot (also cc this to Chris for > > > > > > > > commenting about Marvell DDR4 training driver). > > > > > > > > > > > > > > Yes, ddr4 training code is not in u-boot yet. > > > > > > > > > > > > > > A38x u-boot ddr driver is in this directory: > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x > > > > > > > > > > > > > > And it is copied from the original marvell driver by stripping > > > > > > > non-a38x > > > > > > > code and removal of the ddr4 code from the master branch: > > > > > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell > > > > > > > > > > > > > > So you can try to copy code again without stripping ddr4 parts > > > > > > > (run git log drivers/ddr/marvell/a38x in u-boot) > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > > > > > > > And adjust u-boot board code for ddr4. > > > > > > > > > > > > > > I guess it could work but it would be needed to play with it. > > > > > > > > > > > > > > > > Last time I looked the MarvellEmbeddedProcessors stuff was a long way > > > > > behind what Marvell are releasing to customers. That was for the > > > > > newer SoCs > > > > > so maybe the A385 stuff is current. > > > > > > > > About half year ago, MarvellEmbeddedProcessors mv-ddr-marvell and > > > > A3700-utils-marvell were up-to-date and same as the version distributed > > > > to the Marvell customers. I was cooperating with Marvell to release all > > > > patches from Marvell Extranet portal to github as opensource and also to > > > > incorporate github patches from community to their Extranet version. > > > > Also I was synchronizing u-boot drivers/ddr/marvell/a38x directory with > > > > MarvellEmbeddedProcessors version. I do not think that Marvell released > > > > something super new in these repositories in last half of year, so I > > > > think that the code on MarvellEmbeddedProcessors (for those two > > > > repositories) is still up-to-date. > > > > > > Thanks all for commenting. As Pali has suggested, I will try copying > > > the latest Marvell Github DDR drivers. > > > > I've tried to bring in the latest Marvell DDR drivers, but failed > > miserably after many hours playing :) I used your DDR3 commit info as > > a guide as how to strip out other parts, and only kept DDR3 and DDR4 > > for a38x: > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > The current code has DDR4 interspersed in DDR3 with if-defs > > CONFIG_DDR4. And there are some minor dependencies on ATF types, > > quite difficult for me to get it to build cleanly. I guess I threw in > > the towel for now :) If you ever find some free time, please give it a > > shot. > > > > Thanks, > > Tony > > Hello! And what is the issue? DDR training is failing? Or SPL does not > boot? Or it do not compile? Each of the code files was compiled (after some include
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hi Pali, On Wed, Jan 4, 2023 at 1:04 PM Tony Dinh wrote: > > Hello, > > On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár wrote: > > > > On Wednesday 04 January 2023 23:41:05 Chris Packham wrote: > > > On Wed, 4 Jan 2023, 8:52 PM Pali Rohár, wrote: > > > > > > > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote: > > > > > Hello! > > > > > > > > > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > > > > > > > I'm building a new u-boot for the Thecus N2350 board (Armada 385 > > > > > > dual-core 1Ghz 1GB DDR4). The trouble with this board is DDR4, which > > > > > > is not currently supported in u-boot (also cc this to Chris for > > > > > > commenting about Marvell DDR4 training driver). > > > > > > > > > > Yes, ddr4 training code is not in u-boot yet. > > > > > > > > > > A38x u-boot ddr driver is in this directory: > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x > > > > > > > > > > And it is copied from the original marvell driver by stripping > > > > > non-a38x > > > > > code and removal of the ddr4 code from the master branch: > > > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell > > > > > > > > > > So you can try to copy code again without stripping ddr4 parts > > > > > (run git log drivers/ddr/marvell/a38x in u-boot) > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > > > And adjust u-boot board code for ddr4. > > > > > > > > > > I guess it could work but it would be needed to play with it. > > > > > > > > > > Last time I looked the MarvellEmbeddedProcessors stuff was a long way > > > behind what Marvell are releasing to customers. That was for the newer > > > SoCs > > > so maybe the A385 stuff is current. > > > > About half year ago, MarvellEmbeddedProcessors mv-ddr-marvell and > > A3700-utils-marvell were up-to-date and same as the version distributed > > to the Marvell customers. I was cooperating with Marvell to release all > > patches from Marvell Extranet portal to github as opensource and also to > > incorporate github patches from community to their Extranet version. > > Also I was synchronizing u-boot drivers/ddr/marvell/a38x directory with > > MarvellEmbeddedProcessors version. I do not think that Marvell released > > something super new in these repositories in last half of year, so I > > think that the code on MarvellEmbeddedProcessors (for those two > > repositories) is still up-to-date. > > Thanks all for commenting. As Pali has suggested, I will try copying > the latest Marvell Github DDR drivers. I've tried to bring in the latest Marvell DDR drivers, but failed miserably after many hours playing :) I used your DDR3 commit info as a guide as how to strip out other parts, and only kept DDR3 and DDR4 for a38x: https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 The current code has DDR4 interspersed in DDR3 with if-defs CONFIG_DDR4. And there are some minor dependencies on ATF types, quite difficult for me to get it to build cleanly. I guess I threw in the towel for now :) If you ever find some free time, please give it a shot. Thanks, Tony > > All the best, > Tony > > > > > > > > > > > > So I'm building with binary.0 in the ./board/thecus/n2350/. This > > > > > > binary.0 is a copy of the Marvell bin_hdr for SPI in the GPL source > > > > > > for this board (provided by Thecus). My > > > > > > ./board/thecus/n2350/kwbimage.cfg.in file looks like this > > > > > > > > > > > > # Armada 38x uses version 1 image format > > > > > > VERSION 1 > > > > > > # Boot Media configurations > > > > > > BOOT_FROM spi > > > > > > # Binary Header (bin_hdr) with DDR4 training code > > > > > > BINARY board/thecus/n2350/binary.0 005b 0068 > > > > > > > > > > > > When I kwboot the u-boot.kwb image (using kwboot binary built with > > > > > > 2023.01-rc4), the header was transferred successfully, but then the > > > > > > BootROM jumped to SPI u-boot, ins
Re: linksys wrt1900acs v2 boot problem
Hi all, On Fri, Jan 6, 2023 at 9:35 AM Pali Rohár wrote: > > Hello Dilyan! > > On Tuesday 28 September 2021 22:01:40 Dilyan Lazarov wrote: > > Hi, > > I have a problem with my linksys wrt1900acs. > > My main question is this a hardware problem or software problem? > > Is it possible to address? > > This looks like DDR3 training SW issue problem. Marek worked on in and > tried to address issue. He should know more details in this area. > > > I have started researching and have tried with "kwboot" under Windows VM - > > Ubuntu 20 - Linux but I have a problem with usb serial connection. I have > > tried several things but I understand that it isn't possible to start USB > > to Serial on a Windows VM. > > I will expect your response. > > Thank you in advance. > > You need to use kwboot natively. It was heavily tested on Linux and I > think it should work also on BSD systems. Windows systems are not really > supported and kwboot will not work on them. > > > All the best > > Dilyan > > > > I see the following Log from U-Boot with PuTTy under Windows 10: > > BootROM - 1.73 > > Booting from NAND flash > > > > General initialization - Version: 1.0.0 > > Detected Device ID 6820 > > High speed PHY - Version: 2.0 > > > > Init RD NAS topology Serdes Lane 3 is USB3 > > Serdes Lane 4 is SGMII > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > > > | 0| 06 | SATA0 | > > | 1| 05 | PCIe0 | > > | 2| 06 | SATA1 | > > | 3| 05 | USB3 HOST1 | > > | 4| 05 | PCIe1 | > > | 5| 00 | SGMII2 | > > > > :** Link is Gen1, check the EP capability > > PCIe, Idx 0: Link upgraded to Gen2 based on client cpabilities > > :** Link is Gen1, check the EP capability > > PCIe, Idx 1: remains Gen1 > > High speed PHY - Ended Successfully > > DDR3 Training Sequence - Ver TIP-1.26.0 > > mvSysEnvGetTopologyUpdateInfo: TWSI Read failed > > WL Supp: IF 0 busId 1 Failed ! > > WL Supp: IF 0 failed > > ddr3TipDynamicWriteLevelingSupp failure > > DRAM initialization Failed (res 0x1) > > DDR3 run algorithm - FAILED 0x1 > > DDR3 Training Sequence - FAILED > > > > > > ** DRAM initialization failed! > > -- > > Dilyan > > Could you please try to update U-Boot to the new version? If the issue > is still there? Because DDR3 marvell driver was updated and it is > possible that also your issue is fixed now too... I can confirm that on the Synology DS116 board (also Armada 385, 1GB DDR3). The last tests I ran on this board were built with u-boot-2022.07 and did not see any problem with DDR3 training. All the best, Tony
Re: kwboot : bug when board stops acking
Hello,
On Fri, Jan 6, 2023 at 9:52 AM Pali Rohár wrote:
>
> Hello Stephane!
>
> On Wednesday 08 January 2020 15:21:12 SC wrote:
> > Hi list,
> >
> > I think there's a bug in kwboot.
> > I have a faulty board that stops acking xmodem frames after a certain
> > number of packets and kwboot
> > instead of exiting continues to send frames up to 100%.
> > With the one second retry timer it's very long! More than 2 hours :-(
>
> I saw very similar bugs in kwboot and together with Marek we fixed lot
> of issues in kwboot.
>
> Could you test if last version of kwboot from U-Boot git master branch
> has still same or similar issue?
>
> > The bug is in the kwboot_xm_sendblock() fonction :
> > https://gitlab.denx.de/u-boot/u-boot/blob/master/tools/kwboot.c#L375
> > kwboot_tty_recv detects the timeout but the return value is based on the
> > last character received
> > (line 403)
> > The variable c is not initialized so if it keeps the previous value which
> > is ACK => rc=0 => infinite
> > loop
> >
> > There are several ways to fix the bug:
> > * Surround the "switch(c)" with a test:
> > if ( !((rc == -1) && (errno == ETIMEDOUT)) ) {
> > rc = -1;
> > switch (c) {
> > case ACK:
> > rc = 0;
> > break;
> > case NAK:
> > errno = EBADMSG;
> > break;
> > case CAN:
> > errno = ECANCELED;
> > break;
> > default:
> > errno = EPROTO;
> > break;
> > }
> > }
> > return rc;
> > * In the case of a TIMEOUT set c to a specific value and add the case in
> > the switch
> >
I've been running the latest kwboot (2023.01-rc4), and I did not see
this problem. And the current code looks OK to me. c is modified
before it is used later:
https://github.com/u-boot/u-boot/blob/master/tools/kwboot.c#L1238
And the function kwboot_xm_sendblock() in GitHub is line L1215!
https://github.com/u-boot/u-boot/blob/master/tools/kwboot.c#L1215
Probably Stephane is running an older version of kwboot?
Best,
Tony
> > Do you agree with my diagnosis?
> > What is the best solution to fix this bug?
> > Should I provide a patch?
> >
> > Thank you,
> > Stephane
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
Hello, On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár wrote: > > On Wednesday 04 January 2023 23:41:05 Chris Packham wrote: > > On Wed, 4 Jan 2023, 8:52 PM Pali Rohár, wrote: > > > > > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote: > > > > Hello! > > > > > > > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > I'm building a new u-boot for the Thecus N2350 board (Armada 385 > > > > > dual-core 1Ghz 1GB DDR4). The trouble with this board is DDR4, which > > > > > is not currently supported in u-boot (also cc this to Chris for > > > > > commenting about Marvell DDR4 training driver). > > > > > > > > Yes, ddr4 training code is not in u-boot yet. > > > > > > > > A38x u-boot ddr driver is in this directory: > > > > > > > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x > > > > > > > > And it is copied from the original marvell driver by stripping non-a38x > > > > code and removal of the ddr4 code from the master branch: > > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell > > > > > > > > So you can try to copy code again without stripping ddr4 parts > > > > (run git log drivers/ddr/marvell/a38x in u-boot) > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > And adjust u-boot board code for ddr4. > > > > > > > > I guess it could work but it would be needed to play with it. > > > > > > > Last time I looked the MarvellEmbeddedProcessors stuff was a long way > > behind what Marvell are releasing to customers. That was for the newer SoCs > > so maybe the A385 stuff is current. > > About half year ago, MarvellEmbeddedProcessors mv-ddr-marvell and > A3700-utils-marvell were up-to-date and same as the version distributed > to the Marvell customers. I was cooperating with Marvell to release all > patches from Marvell Extranet portal to github as opensource and also to > incorporate github patches from community to their Extranet version. > Also I was synchronizing u-boot drivers/ddr/marvell/a38x directory with > MarvellEmbeddedProcessors version. I do not think that Marvell released > something super new in these repositories in last half of year, so I > think that the code on MarvellEmbeddedProcessors (for those two > repositories) is still up-to-date. Thanks all for commenting. As Pali has suggested, I will try copying the latest Marvell Github DDR drivers. All the best, Tony > > > > > > > > So I'm building with binary.0 in the ./board/thecus/n2350/. This > > > > > binary.0 is a copy of the Marvell bin_hdr for SPI in the GPL source > > > > > for this board (provided by Thecus). My > > > > > ./board/thecus/n2350/kwbimage.cfg.in file looks like this > > > > > > > > > > # Armada 38x uses version 1 image format > > > > > VERSION 1 > > > > > # Boot Media configurations > > > > > BOOT_FROM spi > > > > > # Binary Header (bin_hdr) with DDR4 training code > > > > > BINARY board/thecus/n2350/binary.0 005b 0068 > > > > > > > > > > When I kwboot the u-boot.kwb image (using kwboot binary built with > > > > > 2023.01-rc4), the header was transferred successfully, but then the > > > > > BootROM jumped to SPI u-boot, instead of loading the u-boot payload > > > > > from UART. Please see the log below. > > > > > > > > > > # ./kwboot -t -p -B 115200 /dev/ttyUSB0 -b uboot.kwb > > > > > > > > > > kwboot version 2023.01-tld-1-00048-g19e15f9081-dirty > > > > > Patching image boot signature to UART > > > > > Aligning image header to Xmodem block size > > > > > Sending boot message. Please reboot the target.../ > > > > > Sending boot image header (97792 bytes)... > > > > > 0 % > > > [..] > > > > > 9 % > > > [..] > > > > > > > > > > 82 % > > > [..] > > > > > 91 % > > > [ ] >
[PATCH] arm: kirkwood: Convert to DM Serial for various Kirkwood boards
For Kirkwood boards, it is necessary to have early malloc in DRAM area when Driver Model for Serial is enabled. Please see Michael's patch here: https://lore.kernel.org/u-boot/20220817193809.1059688-20-mich...@walle.cc/ This patch enables the early malloc in DRAM for all Kirkwood boards. Note that this will work for boards that have either non-DM serial and DM_SERIAL. Also, add the CONFIG_KIRKWOOD_COMMON option to enable DM_SERIAL as a common option for boards that have been tested. Signed-off-by: Tony Dinh --- arch/arm/mach-kirkwood/Kconfig | 22 ++ 1 file changed, 22 insertions(+) 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" -- 2.30.2
Re: Converting to DM SERIAL for Kirkwood boards
Hi Stefan,
On Thu, Dec 15, 2022 at 10:29 PM Stefan Roese 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 wrote:
> >>
> >> Hi Michael,
> >>
> >> On Mon, Dec 12, 2022 at 1:03 AM Michael Walle 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 = <0x 0x1000>;
> >>>>> @@ -317,3 +321,8 @@
> >>>>>&pcie0 {
> >>>>> status = "okay";
> >>>>>};
> >>>>> +
> >>>>> +&uart0 {
> >>>>> + status = "okay";
> >>>>> + u-boot,dm-pre-reloc;
> >>>>> +};
> >>>>
> >>>> Thanks for the patch! but
Re: [PATCH] timer: orion-timer: Fix problem with early static variable
Hi Stefan,
On Wed, Dec 21, 2022 at 1:18 AM Stefan Roese wrote:
>
> We've noticed that at least one Kirkwood board (Pogo v4) has problems
> with the new orion DM timer implementation. Debugging revealed that this
> issue is related with the static variable "early_init_done" which does
> not work correctly before relocation in all cases.
>
> This patch removes this static variable and replaces it's functionality
> via a function that detects if the timer is already initialized.
>
> Signed-off-by: Stefan Roese
> Cc: Pali Rohár
> Cc: Michael Walle
> Cc: Tony Dinh
> ---
> drivers/timer/orion-timer.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/timer/orion-timer.c b/drivers/timer/orion-timer.c
> index d0eab3ce781d..6804bf0fa2cb 100644
> --- a/drivers/timer/orion-timer.c
> +++ b/drivers/timer/orion-timer.c
> @@ -23,15 +23,19 @@ struct orion_timer_priv {
>
> #define MVEBU_TIMER_FIXED_RATE_25MHZ 2500
>
> -static bool early_init_done __section(".data") = false;
> +static bool early_init_done(void *base)
> +{
> + if (readl(base + TIMER_CTRL) & TIMER0_EN)
> + return true;
> + return false;
> +}
>
> /* Common functions for early (boot) and DM based timer */
> 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(base))
> return;
> - early_init_done = true;
>
> writel(~0, base + TIMER0_VAL);
> writel(~0, base + TIMER0_RELOAD);
> --
> 2.39.0
>
I've tested with a couple Kirkwood boards, and they are working fine:
Pogo V4 (Kirkwood 88F6192) and Goflex Home (Kirkwood 88F6281). Note
that the Goflex Home does not have CONFIG_BOOTSTAGE (i.e. a regression
test, with a few sleep commands at the u-boot prompt).
Tested-by: Tony Dinh
Thanks,
Tony
Re: Converting to DM SERIAL for Kirkwood boards
Hi Stefan,
On Wed, Dec 21, 2022 at 1:29 AM Stefan Roese 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 wrote:
> >>>>
> >>>> Hi Stefan,
> >>>>
> >>>> On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh wrote:
> >>>>>
> >>>>> Hi Stefan,
> >>>>>
> >>>>> On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese wrote:
> >>>>>>
> >>>>>> Hi Tony,
> >>>>>>
> >>>>>> On 12/19/22 07:17, Stefan Roese wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> 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, devi
Re: Converting to DM SERIAL for Kirkwood boards
Hi Stefan,
On Mon, Dec 19, 2022 at 4:06 PM Tony Dinh wrote:
>
> Hi Stefan,
>
> On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh wrote:
> >
> > Hi Stefan,
> >
> > On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese wrote:
> > >
> > > Hi Tony,
> > >
> > > On 12/19/22 07:17, Stefan Roese wrote:
> > >
> > >
> > >
> > > >> 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
Re: Converting to DM SERIAL for Kirkwood boards
Hi Stefan,
On Mon, Dec 19, 2022 at 1:22 PM Tony Dinh wrote:
>
> Hi Stefan,
>
> On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese wrote:
> >
> > Hi Tony,
> >
> > On 12/19/22 07:17, Stefan Roese wrote:
> >
> >
> >
> > >> 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
Re: Converting to DM SERIAL for Kirkwood boards
Hi Stefan, On Sun, Dec 18, 2022 at 11:29 PM Stefan Roese wrote: > > Hi Tony, > > On 12/19/22 07:17, Stefan Roese wrote: > > > > >> 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
Re: Converting to DM SERIAL for Kirkwood boards
Hi Stefan, On Fri, Dec 16, 2022 at 1:49 PM Tony Dinh 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
Re: Converting to DM SERIAL for Kirkwood boards
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
Re: Converting to DM SERIAL for Kirkwood boards
Hi all,
On Mon, Dec 12, 2022 at 5:18 PM Tony Dinh wrote:
>
> Hi Michael,
>
> On Mon, Dec 12, 2022 at 1:03 AM Michael Walle 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 = <0x 0x1000>;
> > >> @@ -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-mich...@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
Re: Converting to DM SERIAL for Kirkwood boards
Hi Michael,
On Mon, Dec 12, 2022 at 1:03 AM Michael Walle 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 = <0x 0x1000>;
> >> @@ -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-mich...@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
Re: Converting to DM SERIAL for Kirkwood boards
On Thu, Dec 8, 2022 at 10:56 PM Stefan Roese 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 = <0x 0x1000>;
> @@ -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
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
Re: [PATCH 5/6] pogo_v4: Disable LTO
Hi Tom,
On Wed, Nov 23, 2022 at 5:45 AM Tom Rini wrote:
>
> On Tue, Nov 22, 2022 at 01:09:55PM -0800, Tony Dinh wrote:
> > Resend to include the mailing list!
> >
> > Tony
> >
> > On Tue, Nov 22, 2022 at 11:58 AM Tony Dinh wrote:
> > >
> > > Hi Tom,
> > >
> > > On Tue, Nov 22, 2022 at 9:32 AM Tom Rini wrote:
> > > >
> > > > With gcc-12.2 we now get:
> > > > lib/zlib/inflate.c:360: undefined reference to `__gnu_thumb1_case_si'
> > > > when building this platform. This seems like some odd problem with LTO
> > > > and Thumb, but since the platform continues to link, I assume it's
> > > > within size constraints, so lets just disable LTO for now.
> > >
> > > We don't have a hard size constraint for this board. Thumb and LTO
> > > were to help keep the image 512K or less (by convention, for some
> > > downstream scripts).
>
> Ah, well, uh-oh. Then we needed to add:
> CONFIG_HAS_BOARD_SIZE_LIMIT=y
> CONFIG_BOARD_SIZE_LIMIT=524288
> to the config. Which is fine now, but without both LTO and thumb, we now
> are too big. So this means digging harder at that error message. Which
> in turn shows that 806f86bd826e ("arm: lib: Import Thumb1 functions") is
> where we imported the __gnu_thumb1_case_* functions we have now, and
> need to do similar work to import (and then do the follow-up
> improvements to) __gnu_thumb1_case_si. Can you please take a look at
> that? FWIW, the gcc-12.2.0 toolchain I'm using is just
> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/x86_64-gcc-12.2.0-nolibc-arm-linux-gnueabi.tar.xz
I think I was not clear in my previous response. We did not implement
a hard size constraint, but only tried to keep it small at 512K. If it
grows larger, it's OK. Others and I just need to modify the flashing
script, which is not a big deal. So removing LTO and Thumb is fine to
get through this gcc build problem. Nothing will break because it is
still small enough at 670K (built using gcc 11).
I'm not well versed in troubleshooting this type of compiler problem.
I could try, but I think someone like Simon would be able to solve it
quicker. Please let me know what you think.
All the best,
Tony
>
> --
> Tom
Re: [PATCH 5/6] pogo_v4: Disable LTO
Resend to include the mailing list! Tony On Tue, Nov 22, 2022 at 11:58 AM Tony Dinh wrote: > > Hi Tom, > > On Tue, Nov 22, 2022 at 9:32 AM Tom Rini wrote: > > > > With gcc-12.2 we now get: > > lib/zlib/inflate.c:360: undefined reference to `__gnu_thumb1_case_si' > > when building this platform. This seems like some odd problem with LTO > > and Thumb, but since the platform continues to link, I assume it's > > within size constraints, so lets just disable LTO for now. > > We don't have a hard size constraint for this board. Thumb and LTO > were to help keep the image 512K or less (by convention, for some > downstream scripts). > > Thanks, > Acked-by: Tony Dinh > > > > > Cc: Tony Dinh > > Signed-off-by: Tom Rini > > --- > > configs/pogo_v4_defconfig | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig > > index 3b08cb7b1d14..c4b7f7c31471 100644 > > --- a/configs/pogo_v4_defconfig > > +++ b/configs/pogo_v4_defconfig > > @@ -17,7 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="kirkwood-pogoplug-series-4" > > CONFIG_SYS_PROMPT="Pogo_V4> " > > CONFIG_IDENT_STRING="\nPogoplug V4" > > CONFIG_SYS_LOAD_ADDR=0x80 > > -CONFIG_LTO=y > > CONFIG_DISTRO_DEFAULTS=y > > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000 > > -- > > 2.25.1 > >
Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case
Thanks Damiel! On Sun, Sep 4, 2022 at 3:10 PM Pali Rohár wrote: > > On Sunday 04 September 2022 22:58:19 Daniel Golle wrote: > > On Sun, Sep 04, 2022 at 12:28:24PM -0700, Tony Dinh wrote: > > > Hi Pali, > > > > > > On Sun, Sep 4, 2022 at 2:37 AM Pali Rohár wrote: > > > > > > > > On Saturday 03 September 2022 20:01:45 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár wrote: > > > > > > > > > > > > Do various small fixup/cleanups and extend test script to boot > > > > > > kernel > > > > > > image from UBI volume. This test verifies that U-Boot UBI > > > > > > implementation > > > > > > is working and U-Boot can read volume with bootable kernel code > > > > > > correctly. And therefore CI prevents UBI breakage. > > > > > > > > > > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and > > > > > > trying to mount UBIFS from UBI volume fails :-( I have already > > > > > > tried to > > > > > > debug this issue but I have no idea why it is failing. > > > > > > > > > > I've recently implemented UBI distro boot on a pair of Kirkwood boards > > > > > (Pogo V4 and NSA310s) successfully. I created the UBI partition and > > > > > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the > > > > > u-boot distro boot scan the UBI partition to find the boot script > > > > > boot.scr. And also mount it manually to look at the file system. > > > > > > > > Hello! I think you mean UBIFS on UBI, right? > > > > > > Yes. UBIFS on UBI. > > > > > > > > > > > > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is > > > > > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume > > > > > allowed me to mount it in the u-boot command line. I think squashfs is > > > > > incomplete in u-boot, at the moment. > > > > > > > > UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works > > > > only on UBI. I guess you could have squashfs on UBI, but on linux this > > > > requires mtdblock, hence it is squashfs on mtdblock on UBI. > > > > > > I meant that (the rootfs) is a squashfs inside an UBIFS volume. And > > > the system running with another UBIFS volume overlaid on top of that. > > > > Just to clarify: OpenWrt uses squashfs in UBI volumes for the compressed > > rootfs. In Linux, ubiblock is used to mount them. > > That is what I thought. squashfs on ubiblock. IIRC U-Boot does not > implement neither mtdblock (block device on mtd) nor ubiblock (block > device on top of ubi volume). So mounting squashfs (which is block based > filesystem) from ubi volume does not work in u-boot. > > I think implementation should not be such hard, this sounds like and > interesting exercise. > > But I'm more interested to figure out why UBIFS does not want to work on > ARM Omap3 Nokia N900, but works fine on PowerPC Freescale P2020 > > > We also usually don't store the kernel in a filesystem but just use a > > bare UBI volume to directly store the uImage.FIT to be booted, for both > > simplicity and robustness reasons. > > On devices with recent enough U-Boot we can use a 'filesystem'-type > > sub-image of a uImage.FIT for squashfs and mount that in Linux. > > > > > > > > Best, > > > Tony > > > > > > > > > > > > Best, > > > > > Tony > > > > > > > > > > > > > > > > Function > > > > > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct > > > > > > and > > > > > > valid because Linux kernel can successfully mount it. And to make it > > > > > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc > > > > > > platform. So UBIFS issue is probably endian or arch specific. > > > > > > (This is UBIFS related, not UBI related.) > > > > > > > > > > > > Pali Rohár (9): > > > > > > Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S > > > > > > Nokia RX-51: Do not clear unknown memory in lowlevel_init.S > > > > > > Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000 > > > > > > Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script > > > > > > Nokia RX-51: Call bootm in test script only when image is valid > > > > > > Nokia RX-51: Fix documentation how to enable UBI support > > > > > > Nokia RX-51: Do not set useless ARCH= in test script > > > > > > Nokia RX-51: Add comment describing kernel image type into test > > > > > > script > > > > > > Nokia RX-51: Add booting from UBI into test script > > > > > > > > > > > > board/nokia/rx51/lowlevel_init.S | 7 +-- > > > > > > configs/nokia_rx51_defconfig | 2 +- > > > > > > doc/board/nokia/rx51.rst | 3 +- > > > > > > test/nokia_rx51_test.sh | 97 > > > > > > +--- > > > > > > 4 files changed, 82 insertions(+), 27 deletions(-) > > > > > > > > > > > > -- > > > > > > 2.20.1 > > > > > >
Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case
On Sun, Sep 4, 2022 at 12:28 PM Tony Dinh wrote: > > Hi Pali, > > On Sun, Sep 4, 2022 at 2:37 AM Pali Rohár wrote: > > > > On Saturday 03 September 2022 20:01:45 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár wrote: > > > > > > > > Do various small fixup/cleanups and extend test script to boot kernel > > > > image from UBI volume. This test verifies that U-Boot UBI implementation > > > > is working and U-Boot can read volume with bootable kernel code > > > > correctly. And therefore CI prevents UBI breakage. > > > > > > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and > > > > trying to mount UBIFS from UBI volume fails :-( I have already tried to > > > > debug this issue but I have no idea why it is failing. > > > > > > I've recently implemented UBI distro boot on a pair of Kirkwood boards > > > (Pogo V4 and NSA310s) successfully. I created the UBI partition and > > > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the > > > u-boot distro boot scan the UBI partition to find the boot script > > > boot.scr. And also mount it manually to look at the file system. > > > > Hello! I think you mean UBIFS on UBI, right? > > Yes. UBIFS on UBI. > > > > > > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is > > > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume > > > allowed me to mount it in the u-boot command line. I think squashfs is > > > incomplete in u-boot, at the moment. > > > > UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works > > only on UBI. I guess you could have squashfs on UBI, but on linux this > > requires mtdblock, hence it is squashfs on mtdblock on UBI. > > I meant that (the rootfs) is a squashfs inside an UBIFS volume. And > the system running with another UBIFS volume overlaid on top of that. I should say "UBI volume" above. > > Best, > Tony > > > > > > Best, > > > Tony > > > > > > > > > > Function > > > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct and > > > > valid because Linux kernel can successfully mount it. And to make it > > > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc > > > > platform. So UBIFS issue is probably endian or arch specific. > > > > (This is UBIFS related, not UBI related.) > > > > > > > > Pali Rohár (9): > > > > Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S > > > > Nokia RX-51: Do not clear unknown memory in lowlevel_init.S > > > > Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000 > > > > Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script > > > > Nokia RX-51: Call bootm in test script only when image is valid > > > > Nokia RX-51: Fix documentation how to enable UBI support > > > > Nokia RX-51: Do not set useless ARCH= in test script > > > > Nokia RX-51: Add comment describing kernel image type into test script > > > > Nokia RX-51: Add booting from UBI into test script > > > > > > > > board/nokia/rx51/lowlevel_init.S | 7 +-- > > > > configs/nokia_rx51_defconfig | 2 +- > > > > doc/board/nokia/rx51.rst | 3 +- > > > > test/nokia_rx51_test.sh | 97 +--- > > > > 4 files changed, 82 insertions(+), 27 deletions(-) > > > > > > > > -- > > > > 2.20.1 > > > >
Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
Hi Michael, On Sun, Sep 4, 2022 at 1:54 AM Michael Walle wrote: > > Am 2022-09-04 02:02, schrieb Tony Dinh: > > Hi Stefan, > > > > Sorry, that message was prematurely sent (fat finger). Please see the > > continuation below. > > > > On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh wrote: > >> > >> Hi Stefan, > >> > >> On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese wrote: > >> > > >> > Hi Tony, > >> > > >> > On 03.09.22 11:44, Tony Dinh wrote: > >> > > Hi Stefan, > >> > > > >> > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese wrote: > >> > >> > >> > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE > >> > >> enabled, like pogo_v4. > >> > >> > >> > >> Signed-off-by: Stefan Roese > >> > >> --- > >> > >> v2: > >> > >> - Change timer_get_boot_us() to use the timer_early functions > >> > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE) > >> > >> > >> > >> Simon, I'm currently looking into this timer_get_boot_us() to using > >> > >> timer_early_get_count() etc consolidation. > >> > > > >> > > Indeed, as you've mentioned above, I think timer_early_get_count() and > >> > > timer_early_get_rate() do need to take into consideration what the > >> > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as > >> > > the Pogo V4. > >> > > > >> > > I'm seeing on the Pogo V4 test, the timer command reports time about 6 > >> > > times slower than it should. It does seem to jive with the fact that > >> > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate. > >> > > >> > Ah, I've missing updating the early functions to also differentiate > >> > between fixed clocks and TCLK timer. > >> > > >> > Please give the attached patch a try - should be applied on top of this > >> > latest patchset. > >> > > > > That looks promising, but I think we are still missing something. > > After applying the attached patch, I ran the test again and it behaved > > the same way (clock rate 6 times slower). So I did another test. > > > > --- Test 1 > > Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get > > 60.000 > > 90.000 > > > > So apparently the sleep cmd has reset the correct clock rate. > > > > --- Test 2 > > > > Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get > > 30.000 > > 60.000 > > > > And then wait for 30 seconds, do another "timer get" (I expected to > > see about 90 to 95 seconds). > > > > Pogo_V4> timer get > > 66.237 > > I've did the same test and can confirm it. But I think that is > a drawback from the timer command. With a 32bit timer and a > TCLK of 166MHz (on my board), the timer will wrap around about > every 26s. So if you don't do a get_timer() call for that whole > period, the overflow won't be counted in timer_conv_64(). > > For the sleep command it works correctly, because it will > poll get_timer() every 100us. > > In summary, you cannot expect a "timer get" on the console > to work if you cannot make sure, the you call it at least > every "2^32 / TCLK" seconds. > > -michael Thanks for confirming that and the explanation. It makes perfect sense! I think I got side tracked and never noticed that it is a 32-bit timer wrap- around :) All the best, Tony
Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case
Hi Pali, On Sun, Sep 4, 2022 at 2:37 AM Pali Rohár wrote: > > On Saturday 03 September 2022 20:01:45 Tony Dinh wrote: > > Hi Pali, > > > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár wrote: > > > > > > Do various small fixup/cleanups and extend test script to boot kernel > > > image from UBI volume. This test verifies that U-Boot UBI implementation > > > is working and U-Boot can read volume with bootable kernel code > > > correctly. And therefore CI prevents UBI breakage. > > > > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and > > > trying to mount UBIFS from UBI volume fails :-( I have already tried to > > > debug this issue but I have no idea why it is failing. > > > > I've recently implemented UBI distro boot on a pair of Kirkwood boards > > (Pogo V4 and NSA310s) successfully. I created the UBI partition and > > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the > > u-boot distro boot scan the UBI partition to find the boot script > > boot.scr. And also mount it manually to look at the file system. > > Hello! I think you mean UBIFS on UBI, right? Yes. UBIFS on UBI. > > > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is > > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume > > allowed me to mount it in the u-boot command line. I think squashfs is > > incomplete in u-boot, at the moment. > > UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works > only on UBI. I guess you could have squashfs on UBI, but on linux this > requires mtdblock, hence it is squashfs on mtdblock on UBI. I meant that (the rootfs) is a squashfs inside an UBIFS volume. And the system running with another UBIFS volume overlaid on top of that. Best, Tony > > > Best, > > Tony > > > > > > > Function > > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct and > > > valid because Linux kernel can successfully mount it. And to make it > > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc > > > platform. So UBIFS issue is probably endian or arch specific. > > > (This is UBIFS related, not UBI related.) > > > > > > Pali Rohár (9): > > > Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S > > > Nokia RX-51: Do not clear unknown memory in lowlevel_init.S > > > Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000 > > > Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script > > > Nokia RX-51: Call bootm in test script only when image is valid > > > Nokia RX-51: Fix documentation how to enable UBI support > > > Nokia RX-51: Do not set useless ARCH= in test script > > > Nokia RX-51: Add comment describing kernel image type into test script > > > Nokia RX-51: Add booting from UBI into test script > > > > > > board/nokia/rx51/lowlevel_init.S | 7 +-- > > > configs/nokia_rx51_defconfig | 2 +- > > > doc/board/nokia/rx51.rst | 3 +- > > > test/nokia_rx51_test.sh | 97 +--- > > > 4 files changed, 82 insertions(+), 27 deletions(-) > > > > > > -- > > > 2.20.1 > > >
Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case
Hi Pali, On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár wrote: > > Do various small fixup/cleanups and extend test script to boot kernel > image from UBI volume. This test verifies that U-Boot UBI implementation > is working and U-Boot can read volume with bootable kernel code > correctly. And therefore CI prevents UBI breakage. > > Note that U-Boot UBIFS code on ARM is currently somehow broken and > trying to mount UBIFS from UBI volume fails :-( I have already tried to > debug this issue but I have no idea why it is failing. I've recently implemented UBI distro boot on a pair of Kirkwood boards (Pogo V4 and NSA310s) successfully. I created the UBI partition and formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the u-boot distro boot scan the UBI partition to find the boot script boot.scr. And also mount it manually to look at the file system. An observation: I cannot mount OpenWrt rootfs in u-boot, since it is an UBIFS volume overlay on squashfs. But creating my own UBIFS volume allowed me to mount it in the u-boot command line. I think squashfs is incomplete in u-boot, at the moment. Best, Tony > Function > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct and > valid because Linux kernel can successfully mount it. And to make it > more suspicious, U-Boot UBIFS is working fine on big endian powerpc > platform. So UBIFS issue is probably endian or arch specific. > (This is UBIFS related, not UBI related.) > > Pali Rohár (9): > Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S > Nokia RX-51: Do not clear unknown memory in lowlevel_init.S > Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000 > Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script > Nokia RX-51: Call bootm in test script only when image is valid > Nokia RX-51: Fix documentation how to enable UBI support > Nokia RX-51: Do not set useless ARCH= in test script > Nokia RX-51: Add comment describing kernel image type into test script > Nokia RX-51: Add booting from UBI into test script > > board/nokia/rx51/lowlevel_init.S | 7 +-- > configs/nokia_rx51_defconfig | 2 +- > doc/board/nokia/rx51.rst | 3 +- > test/nokia_rx51_test.sh | 97 +--- > 4 files changed, 82 insertions(+), 27 deletions(-) > > -- > 2.20.1 >
Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
Hi Pali, On Sat, Sep 3, 2022 at 6:08 PM Pali Rohár wrote: > > On Saturday 03 September 2022 17:38:01 Tony Dinh wrote: > > Hi Pali, > > > > Is there a way to get the CPU frequency from the board upon start up? > > > > Thanks, > > Tony > > Hello! Each SoC has either fixed CPU frequency or has some bits in SAR > register which say on which frequency is CPU running. SAR bits are SoC > specific and are documented either in Functional Specifications or in > Hardware Specifications (both documents are available for free all > 32-bit Marvell SoCs except 375 and 39x). Thanks for the recap. I do remember you posted a patch for that detection. https://lists.denx.de/pipermail/u-boot/2022-August/492034.html Just want to make sure that the SAR register is the only way we can detect it in u-boot. The Kirkwood 6192 SoC on this Pogo V4 board can run at 200 Mhz and 800 Mhz with frequency scaling in Linux. Thanks, Tony
Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
Hi Pali, On Sat, Sep 3, 2022 at 5:02 PM Tony Dinh wrote: > > Hi Stefan, > > Sorry, that message was prematurely sent (fat finger). Please see the > continuation below. > > On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh wrote: > > > > Hi Stefan, > > > > On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese wrote: > > > > > > Hi Tony, > > > > > > On 03.09.22 11:44, Tony Dinh wrote: > > > > Hi Stefan, > > > > > > > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese wrote: > > > >> > > > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE > > > >> enabled, like pogo_v4. > > > >> > > > >> Signed-off-by: Stefan Roese > > > >> --- > > > >> v2: > > > >> - Change timer_get_boot_us() to use the timer_early functions > > > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE) > > > >> > > > >> Simon, I'm currently looking into this timer_get_boot_us() to using > > > >> timer_early_get_count() etc consolidation. > > > > > > > > Indeed, as you've mentioned above, I think timer_early_get_count() and > > > > timer_early_get_rate() do need to take into consideration what the > > > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as > > > > the Pogo V4. > > > > > > > > I'm seeing on the Pogo V4 test, the timer command reports time about 6 > > > > times slower than it should. It does seem to jive with the fact that > > > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate. > > > > > > Ah, I've missing updating the early functions to also differentiate > > > between fixed clocks and TCLK timer. > > > > > > Please give the attached patch a try - should be applied on top of this > > > latest patchset. > > > > That looks promising, but I think we are still missing something. > After applying the attached patch, I ran the test again and it behaved > the same way (clock rate 6 times slower). So I did another test. > > --- Test 1 > Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get > 60.000 > 90.000 > > So apparently the sleep cmd has reset the correct clock rate. > > --- Test 2 > > Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get > 30.000 > 60.000 > > And then wait for 30 seconds, do another "timer get" (I expected to > see about 90 to 95 seconds). > > Pogo_V4> timer get > 66.237 > > The different call tree with the timer vs the sleep command made a > difference. But I could not see where. > > --- Test 3 > > Then I recalled about CONFIG_TIMER_EARLY. It is not selected by > default in Kconfig currently. So I enabled that to see the behavior. > But running this build hangs right off the bat. No u-boot version > banner is printed out. > Is there a way to get the CPU frequency from the board upon start up? Thanks, Tony
Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
Hi Stefan, Sorry, that message was prematurely sent (fat finger). Please see the continuation below. On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh wrote: > > Hi Stefan, > > On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese wrote: > > > > Hi Tony, > > > > On 03.09.22 11:44, Tony Dinh wrote: > > > Hi Stefan, > > > > > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese wrote: > > >> > > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE > > >> enabled, like pogo_v4. > > >> > > >> Signed-off-by: Stefan Roese > > >> --- > > >> v2: > > >> - Change timer_get_boot_us() to use the timer_early functions > > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE) > > >> > > >> Simon, I'm currently looking into this timer_get_boot_us() to using > > >> timer_early_get_count() etc consolidation. > > > > > > Indeed, as you've mentioned above, I think timer_early_get_count() and > > > timer_early_get_rate() do need to take into consideration what the > > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as > > > the Pogo V4. > > > > > > I'm seeing on the Pogo V4 test, the timer command reports time about 6 > > > times slower than it should. It does seem to jive with the fact that > > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate. > > > > Ah, I've missing updating the early functions to also differentiate > > between fixed clocks and TCLK timer. > > > > Please give the attached patch a try - should be applied on top of this > > latest patchset. > That looks promising, but I think we are still missing something. After applying the attached patch, I ran the test again and it behaved the same way (clock rate 6 times slower). So I did another test. --- Test 1 Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get 60.000 90.000 So apparently the sleep cmd has reset the correct clock rate. --- Test 2 Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get 30.000 60.000 And then wait for 30 seconds, do another "timer get" (I expected to see about 90 to 95 seconds). Pogo_V4> timer get 66.237 The different call tree with the timer vs the sleep command made a difference. But I could not see where. --- Test 3 Then I recalled about CONFIG_TIMER_EARLY. It is not selected by default in Kconfig currently. So I enabled that to see the behavior. But running this build hangs right off the bat. No u-boot version banner is printed out. Thanks, Tony > > > > > Thanks, > > Stefan
Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
Hi Stefan, On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese wrote: > > Hi Tony, > > On 03.09.22 11:44, Tony Dinh wrote: > > Hi Stefan, > > > > On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese wrote: > >> > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE > >> enabled, like pogo_v4. > >> > >> Signed-off-by: Stefan Roese > >> --- > >> v2: > >> - Change timer_get_boot_us() to use the timer_early functions > >> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE) > >> > >> Simon, I'm currently looking into this timer_get_boot_us() to using > >> timer_early_get_count() etc consolidation. > > > > Indeed, as you've mentioned above, I think timer_early_get_count() and > > timer_early_get_rate() do need to take into consideration what the > > input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as > > the Pogo V4. > > > > I'm seeing on the Pogo V4 test, the timer command reports time about 6 > > times slower than it should. It does seem to jive with the fact that > > the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate. > > Ah, I've missing updating the early functions to also differentiate > between fixed clocks and TCLK timer. > > Please give the attached patch a try - should be applied on top of this > latest patchset. That looks promising, but I think we are still missing something. After applying the attached patch, I ran the test again and it behaved the same way (clock rate 6 times slower). So I did another test. > Thanks, > Stefan
Re: [PATCH v2 3/8] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support
Hi Stefan,
On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese wrote:
>
> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE
> enabled, like pogo_v4.
>
> Signed-off-by: Stefan Roese
> ---
> v2:
> - Change timer_get_boot_us() to use the timer_early functions
> - Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)
>
> Simon, I'm currently looking into this timer_get_boot_us() to using
> timer_early_get_count() etc consolidation.
Indeed, as you've mentioned above, I think timer_early_get_count() and
timer_early_get_rate() do need to take into consideration what the
input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as
the Pogo V4.
I'm seeing on the Pogo V4 test, the timer command reports time about 6
times slower than it should. It does seem to jive with the fact that
the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate.
All the best,
Tony
>
> drivers/timer/orion-timer.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/timer/orion-timer.c b/drivers/timer/orion-timer.c
> index 14f318e57d4d..6c0b8550412d 100644
> --- a/drivers/timer/orion-timer.c
> +++ b/drivers/timer/orion-timer.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -39,6 +40,14 @@ u64 notrace timer_early_get_count(void)
> return timer_conv_64(~readl(MVEBU_TIMER_BASE + TIMER0_VAL));
> }
>
> +ulong timer_get_boot_us(void)
> +{
> + u64 ticks;
> +
> + ticks = timer_early_get_count();
> + return lldiv(ticks * 1000, timer_early_get_rate());
> +}
> +
> static uint64_t orion_timer_get_count(struct udevice *dev)
> {
> struct orion_timer_priv *priv = dev_get_priv(dev);
> --
> 2.37.3
>
Re: [PATCH v2 0/8] Enable CONFIG_TIMER for all Kirkwood / MVEBU boards
Hi Stefan, On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese wrote: > > This patchset enhaces the recently added Orion Timer driver to support > all other Kirkwood & 32bit MVEBU Armada platforms. Additionally, this > timer support is then enabled per default for those platforms, so that > the board config files don't need to be changed. Also necessary is > some dts hacking, so that the timer DT node is available in early > U-Boot stages. > > I've successfully tested this patchset on an Armada XP board. Additional > test on other boards and platforms are very welcome and necessary. I've also discovered that the timer command (CONFIG_CMD_TIMER) was broken at some time in the past. It does not keep time correctly (lagging realtime badly), with or without this patch set . I think we would want to investigate that issue later. The sleep command works perfectly. Therefore, Tested-by: Tony Dinh Thanks, Tony > Thanks, > Stefan > > Stefan Roese (8): > timer: orion-timer: Use timer_conv_64() to fix timer wrap around > timer: orion-timer: Add support for other Armada SoC's > timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support > arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms > arm: mvebu: dts: Makefile: Compile Armada 375 dtb in a separate step > arm: mvebu: dts: armada-375.dtsi: Add timer0 & timer1 > arm: mvebu: dts: mvebu-u-boot.dtsi: Add "u-boot,dm-pre-reloc" to timer > DT node > kirkwood: lsxl: Sync defconfigs > > arch/arm/Kconfig | 4 ++ > arch/arm/dts/Makefile | 6 ++- > arch/arm/dts/armada-375.dtsi | 4 +- > arch/arm/dts/mvebu-u-boot.dtsi| 11 + > arch/arm/mach-mvebu/include/mach/config.h | 5 --- > configs/lschlv2_defconfig | 3 -- > configs/lsxhl_defconfig | 3 -- > drivers/timer/Kconfig | 5 ++- > drivers/timer/orion-timer.c | 53 +-- > 9 files changed, 75 insertions(+), 19 deletions(-) > > -- > 2.37.3 >
Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Hi Stefan,
On Thu, Sep 1, 2022 at 7:51 PM Tony Dinh wrote:
>
> Hello,
>
> On Thu, Sep 1, 2022 at 4:46 PM Tony Dinh wrote:
> >
> > Hi Stefan R,
> >
> > On Thu, Sep 1, 2022 at 7:35 AM Simon Glass wrote:
> > >
> > > Hi,
> > >
> > > On Thu, 1 Sept 2022 at 03:27, Stefan Roese wrote:
> > > >
> > > > Hi Tony,
> > > >
> > > > On 01.09.22 09:39, Tony Dinh wrote:
> > > >
> > > >
> > > >
> > > > >>> Some ideas.
> > > > >>>
> > > > >>> The get_timer() function looks wrong assigning an uint64_t to ulong.
> > > > >>>
> > > > >>> lib/time.c
> > > > >>>
> > > > >>> static uint64_t notrace tick_to_time(uint64_t tick)
> > > > >>> uint64_t notrace get_ticks(void)
> > > > >>> uint64_t __weak notrace get_ticks(void)
> > > > >>>
> > > > >>> ulong __weak get_timer(ulong base)
> > > > >>> {
> > > > >>> return tick_to_time(get_ticks()) - base;
> > > > >>> }
> > > > >>>
> > > > >>> Most of the timer infrastructure is using uint64_t. I'm seeing this
> > > > >>> __weak function get_timer was invoked in Kirkwood boards. Both in
> > > > >>> sleep and timer commands.
> > > > >>
> > > > >> The get_ticks() thing can run at 1MHz but the timer is 1KHz, so that
> > > > >> is why we don't need a u64 for the timer.
> > >
> > > This is wrong, I meant that get_tbclk() can run at 1MHZ (for example).
> > > The tick is 1KHz.
> > >
> > > > >
> > > > > Thanks for your explanation! However, would you agree that code is
> > > > > problematic and needed some improvement ? IOW, depending what the
> > > > > compiler does, it might return the 1st 32 bit of the 64-bit integer
> > > > > result?
> > >
> > > Yes, we should really use ulong for the tick count as well. The use of
> > > 64-bits seems wrong (on 32-bit machines).
> > >
> > > >
> > > > It will return the lower 32 bits if the system is 32bit, yes.
> > > >
> > > > To check if we have a problem here, please add this (totally untested)
> > > > code and extend it if it makes sense:
> > > >
> > > > diff --git a/lib/time.c b/lib/time.c
> > > > index bbf191f67323..ef5252419f3b 100644
> > > > --- a/lib/time.c
> > > > +++ b/lib/time.c
> > > > @@ -146,7 +146,15 @@ int __weak timer_init(void)
> > > > /* Returns time in milliseconds */
> > > > ulong __weak get_timer(ulong base)
> > > > {
> > > > - return tick_to_time(get_ticks()) - base;
> > > > + u64 ticks = get_ticks();
> > > > + u64 time_ms = tick_to_time(ticks);
> > > > +
> > > > + if (time_ms & 0xULL)
> > > > + printf("ticks=%lld time_ms=%lld\n", ticks, time_ms);
> > > > + if ((time_ms - base) & 0x8000ULL)
> > > > + printf("ticks=%lld time_ms=%lld base=%ld ret=%lld\n",
> > > > ticks, time_ms, base, time_ms - base);
> > > > +
> > > > + return time_ms - base;
> > > > }
> >
> > With this patch, indeed it showed a wrap around. And the system was
> > frozen during the next command.
> >
> > Below is the log (my annotated comment starts with ***).
> >
> >
> > U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Sep 01 2022 - 15:44:22 -0700)
> > Pogoplug V4
> >
> > SoC: Kirkwood 88F6281_A1
> > Model: Cloud Engines PogoPlug Series 4
> > DRAM: 128 MiB
> > orion_timer_probe Clock Rate 16600
> > orion_timer_probe successful
> > Core: 19 devices, 15 uclasses, devicetree: separate
> > NAND: 128 MiB
> > MMC: mvsdio@9: 0
> > Loading Environment from NAND... OK
> > In:serial
> > Out: serial
> > Err: serial
> > pcie0.0: Link up
> > Net: eth0: ethernet-controller@72000
> > Hit any key to stop autoboot: 0
> > Pogo_V4> sleep 5
> > do_sleep got a timer start = 14344
> > do_sleep delay = 5000
> > do_sleep delay = 5000
> > do_sleep sleeping...
> > do_sleep sta
Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Hello,
On Thu, Sep 1, 2022 at 4:46 PM Tony Dinh wrote:
>
> Hi Stefan R,
>
> On Thu, Sep 1, 2022 at 7:35 AM Simon Glass wrote:
> >
> > Hi,
> >
> > On Thu, 1 Sept 2022 at 03:27, Stefan Roese wrote:
> > >
> > > Hi Tony,
> > >
> > > On 01.09.22 09:39, Tony Dinh wrote:
> > >
> > >
> > >
> > > >>> Some ideas.
> > > >>>
> > > >>> The get_timer() function looks wrong assigning an uint64_t to ulong.
> > > >>>
> > > >>> lib/time.c
> > > >>>
> > > >>> static uint64_t notrace tick_to_time(uint64_t tick)
> > > >>> uint64_t notrace get_ticks(void)
> > > >>> uint64_t __weak notrace get_ticks(void)
> > > >>>
> > > >>> ulong __weak get_timer(ulong base)
> > > >>> {
> > > >>> return tick_to_time(get_ticks()) - base;
> > > >>> }
> > > >>>
> > > >>> Most of the timer infrastructure is using uint64_t. I'm seeing this
> > > >>> __weak function get_timer was invoked in Kirkwood boards. Both in
> > > >>> sleep and timer commands.
> > > >>
> > > >> The get_ticks() thing can run at 1MHz but the timer is 1KHz, so that
> > > >> is why we don't need a u64 for the timer.
> >
> > This is wrong, I meant that get_tbclk() can run at 1MHZ (for example).
> > The tick is 1KHz.
> >
> > > >
> > > > Thanks for your explanation! However, would you agree that code is
> > > > problematic and needed some improvement ? IOW, depending what the
> > > > compiler does, it might return the 1st 32 bit of the 64-bit integer
> > > > result?
> >
> > Yes, we should really use ulong for the tick count as well. The use of
> > 64-bits seems wrong (on 32-bit machines).
> >
> > >
> > > It will return the lower 32 bits if the system is 32bit, yes.
> > >
> > > To check if we have a problem here, please add this (totally untested)
> > > code and extend it if it makes sense:
> > >
> > > diff --git a/lib/time.c b/lib/time.c
> > > index bbf191f67323..ef5252419f3b 100644
> > > --- a/lib/time.c
> > > +++ b/lib/time.c
> > > @@ -146,7 +146,15 @@ int __weak timer_init(void)
> > > /* Returns time in milliseconds */
> > > ulong __weak get_timer(ulong base)
> > > {
> > > - return tick_to_time(get_ticks()) - base;
> > > + u64 ticks = get_ticks();
> > > + u64 time_ms = tick_to_time(ticks);
> > > +
> > > + if (time_ms & 0xULL)
> > > + printf("ticks=%lld time_ms=%lld\n", ticks, time_ms);
> > > + if ((time_ms - base) & 0x8000ULL)
> > > + printf("ticks=%lld time_ms=%lld base=%ld ret=%lld\n",
> > > ticks, time_ms, base, time_ms - base);
> > > +
> > > + return time_ms - base;
> > > }
>
> With this patch, indeed it showed a wrap around. And the system was
> frozen during the next command.
>
> Below is the log (my annotated comment starts with ***).
>
>
> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Sep 01 2022 - 15:44:22 -0700)
> Pogoplug V4
>
> SoC: Kirkwood 88F6281_A1
> Model: Cloud Engines PogoPlug Series 4
> DRAM: 128 MiB
> orion_timer_probe Clock Rate 16600
> orion_timer_probe successful
> Core: 19 devices, 15 uclasses, devicetree: separate
> NAND: 128 MiB
> MMC: mvsdio@9: 0
> Loading Environment from NAND... OK
> In:serial
> Out: serial
> Err: serial
> pcie0.0: Link up
> Net: eth0: ethernet-controller@72000
> Hit any key to stop autoboot: 0
> Pogo_V4> sleep 5
> do_sleep got a timer start = 14344
> do_sleep delay = 5000
> do_sleep delay = 5000
> do_sleep sleeping...
> do_sleep start 14344 curent 100
> do_sleep start 14344 curent 200
>
> do_sleep start 14344 curent 4800
> do_sleep start 14344 curent 4900
> do_sleep end of sleep ... current = 5000
>
> Pogo_V4> sleep 10
> do_sleep got a timer start = 22370
> do_sleep delay = 1
> do_sleep delay = 1
> do_sleep sleeping...
> do_sleep start 22370 curent 100
> do_sleep start 22370 curent 200
> do_sleep start 22370 curent 300
> do_sleep start 22370 curent 400
>
> do_sleep start 22370 curent 3300
> do_sleep start 22370 curent 3400
> do_sleep start
Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Hi Stefan R,
On Thu, Sep 1, 2022 at 7:35 AM Simon Glass wrote:
>
> Hi,
>
> On Thu, 1 Sept 2022 at 03:27, Stefan Roese wrote:
> >
> > Hi Tony,
> >
> > On 01.09.22 09:39, Tony Dinh wrote:
> >
> >
> >
> > >>> Some ideas.
> > >>>
> > >>> The get_timer() function looks wrong assigning an uint64_t to ulong.
> > >>>
> > >>> lib/time.c
> > >>>
> > >>> static uint64_t notrace tick_to_time(uint64_t tick)
> > >>> uint64_t notrace get_ticks(void)
> > >>> uint64_t __weak notrace get_ticks(void)
> > >>>
> > >>> ulong __weak get_timer(ulong base)
> > >>> {
> > >>> return tick_to_time(get_ticks()) - base;
> > >>> }
> > >>>
> > >>> Most of the timer infrastructure is using uint64_t. I'm seeing this
> > >>> __weak function get_timer was invoked in Kirkwood boards. Both in
> > >>> sleep and timer commands.
> > >>
> > >> The get_ticks() thing can run at 1MHz but the timer is 1KHz, so that
> > >> is why we don't need a u64 for the timer.
>
> This is wrong, I meant that get_tbclk() can run at 1MHZ (for example).
> The tick is 1KHz.
>
> > >
> > > Thanks for your explanation! However, would you agree that code is
> > > problematic and needed some improvement ? IOW, depending what the
> > > compiler does, it might return the 1st 32 bit of the 64-bit integer
> > > result?
>
> Yes, we should really use ulong for the tick count as well. The use of
> 64-bits seems wrong (on 32-bit machines).
>
> >
> > It will return the lower 32 bits if the system is 32bit, yes.
> >
> > To check if we have a problem here, please add this (totally untested)
> > code and extend it if it makes sense:
> >
> > diff --git a/lib/time.c b/lib/time.c
> > index bbf191f67323..ef5252419f3b 100644
> > --- a/lib/time.c
> > +++ b/lib/time.c
> > @@ -146,7 +146,15 @@ int __weak timer_init(void)
> > /* Returns time in milliseconds */
> > ulong __weak get_timer(ulong base)
> > {
> > - return tick_to_time(get_ticks()) - base;
> > + u64 ticks = get_ticks();
> > + u64 time_ms = tick_to_time(ticks);
> > +
> > + if (time_ms & 0xULL)
> > + printf("ticks=%lld time_ms=%lld\n", ticks, time_ms);
> > + if ((time_ms - base) & 0x8000ULL)
> > + printf("ticks=%lld time_ms=%lld base=%ld ret=%lld\n",
> > ticks, time_ms, base, time_ms - base);
> > +
> > + return time_ms - base;
> > }
With this patch, indeed it showed a wrap around. And the system was
frozen during the next command.
Below is the log (my annotated comment starts with ***).
U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Sep 01 2022 - 15:44:22 -0700)
Pogoplug V4
SoC: Kirkwood 88F6281_A1
Model: Cloud Engines PogoPlug Series 4
DRAM: 128 MiB
orion_timer_probe Clock Rate 16600
orion_timer_probe successful
Core: 19 devices, 15 uclasses, devicetree: separate
NAND: 128 MiB
MMC: mvsdio@9: 0
Loading Environment from NAND... OK
In:serial
Out: serial
Err: serial
pcie0.0: Link up
Net: eth0: ethernet-controller@72000
Hit any key to stop autoboot: 0
Pogo_V4> sleep 5
do_sleep got a timer start = 14344
do_sleep delay = 5000
do_sleep delay = 5000
do_sleep sleeping...
do_sleep start 14344 curent 100
do_sleep start 14344 curent 200
do_sleep start 14344 curent 4800
do_sleep start 14344 curent 4900
do_sleep end of sleep ... current = 5000
Pogo_V4> sleep 10
do_sleep got a timer start = 22370
do_sleep delay = 1
do_sleep delay = 1
do_sleep sleeping...
do_sleep start 22370 curent 100
do_sleep start 22370 curent 200
do_sleep start 22370 curent 300
do_sleep start 22370 curent 400
do_sleep start 22370 curent 3300
do_sleep start 22370 curent 3400
do_sleep start 22370 curent 3500
ticks=188 time_ms=0 base=22370 ret=-22370
do_sleep end of sleep ... current = 4294944926
*** we are seeing wrap around here
Pogo_V4> sleep 15
do_sleep got a timer start = 15733
do_sleep delay = 15000
do_sleep delay = 15000
do_sleep sleeping...
do_sleep start 15733 curent 100
do_sleep start 15733 curent 200
do_sleep start 15733 curent 300
do_sleep start 15733 curent 400
do_sleep start 15733 curent 9900
do_sleep start 15733 curent 1
do_sleep start 15733 curent 10100
*** And the system was frozen here
Thanks,
Tony
> >
> > At least here, you seem to have a wrap around with the 32bits AFAICT:
> >
> > > GoFlexHome> sleep 20.5
> > > do_sleep got a timer start = 15031
> > > do_sleep delay = 2
> > > do_sleep delay = 20500
> > > do_sleep sleeping...
> > > do_sleep start 15031 current 100
> > >
> > > do_sleep start 15031 current 6400
> > > do_sleep end of sleep ... current = 4294952265
> > >
> > > *** Something strange happened here. current should be 6500, but it
> > > seems to have garbage. So the loop exits prematurely.
> >
> > 4294952265 = 0xC549!
>
> Yes this all needs a look, I think.
>
> Regards,
> Simon
Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Hi Simon, On Wed, Aug 31, 2022 at 7:27 PM Simon Glass wrote: > > Hi Tony, > > On Wed, 31 Aug 2022 at 19:39, Tony Dinh wrote: > > > > Hi Stefan, > > > > On Wed, Aug 31, 2022 at 2:53 PM Tony Dinh wrote: > > > > > > Hi Stefan, > > > > > > On Wed, Aug 31, 2022 at 8:08 AM Tony Dinh wrote: > > > > > > > > Hi Stefan, > > > > > > > > On Wed, Aug 31, 2022 at 12:22 AM Stefan Roese wrote: > > > > > > > > > > Hi Tony, > > > > > > > > > > On 31.08.22 08:30, Tony Dinh wrote: > > > > > > Hi Stefan, > > > > > > > > > > > > On Tue, Aug 30, 2022 at 10:08 PM Stefan Roese wrote: > > > > > >> > > > > > >> Hi Tony, > > > > > >> > > > > > >> On 31.08.22 07:02, Stefan Roese wrote: > > > > > >>> Hi Tony, > > > > > >>> > > > > > >>> On 31.08.22 00:15, Tony Dinh wrote: > > > > > >>>> Hi Stefan, > > > > > >>>> > > > > > >>>> On Tue, Aug 30, 2022 at 4:53 AM Stefan Roese > > > > > >>>> wrote: > > > > > >>>>> > > > > > >>>>> This patchset enhaces the recently added Orion Timer driver to > > > > > >>>>> support > > > > > >>>>> all other Kirkwood & 32bit MVEBU Armada platforms. > > > > > >>>>> Additionally, this > > > > > >>>>> timer support is then enabled per default for those platforms, > > > > > >>>>> so that > > > > > >>>>> the board config files don't need to be changed. Also necessary > > > > > >>>>> is > > > > > >>>>> some dts hacking, so that the timer DT node is available in > > > > > >>>>> early > > > > > >>>>> U-Boot stages. > > > > > >>>>> > > > > > >>>>> I've successfully tested this patchset on an Armada XP board. > > > > > >>>>> Additional > > > > > >>>>> test on other boards and platforms are very welcome and > > > > > >>>>> necessary. > > > > > >>>> > > > > > >>>> I've run some tests with the following 2 Kirkwood boards: Cloud > > > > > >>>> Engines Pogo V4 88F6192 (with CONFIG_DM_RTC and > > > > > >>>> CONFIG_RTC_EMULATION), > > > > > >>>> and Marvell Sheevaplug 88F6281 (with CONFIG_DM_RTC and > > > > > >>>> CONFIG_RTC_MV). > > > > > >>>> > > > > > >>>> It seems that it was either frozen or the timer did not expire > > > > > >>>> at some > > > > > >>>> subsequent sleep commands. Sometime it happened at 2nd command, > > > > > >>>> some > > > > > >>>> time at a later sleep command. For example, > > > > > >>>> > > > > > >>>> === Pogo V4 (the 1st sleep command works correctly at 10 seconds > > > > > >>>> on my > > > > > >>>> stopwatch) > > > > > >>>> > > > > > >>>> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - > > > > > >>>> 13:38:24 -0700) > > > > > >>>> Pogoplug V4 > > > > > >>>> > > > > > >>>> Hit any key to stop autoboot: 0 > > > > > >>>> Pogo_V4> sleep 10 > > > > > >>>> Pogo_V4> sleep 31.5 > > > > > >>>> > > > > > >>> > > > > > >>> Does the cmd interface support fractial numbers? Please test > > > > > >>> again with > > > > > >>> 31 or other integral numbers. > > > > > >>> > > > > > >>>> === Sheevaplug (RTC battery is old, so the date was not updated, > > > > > >>>> but > > > > > >>>> the clock seems OK) > > > > > >>>> > > > > > >>>> U-Boot 20
Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Hi Stefan, On Wed, Aug 31, 2022 at 2:53 PM Tony Dinh wrote: > > Hi Stefan, > > On Wed, Aug 31, 2022 at 8:08 AM Tony Dinh wrote: > > > > Hi Stefan, > > > > On Wed, Aug 31, 2022 at 12:22 AM Stefan Roese wrote: > > > > > > Hi Tony, > > > > > > On 31.08.22 08:30, Tony Dinh wrote: > > > > Hi Stefan, > > > > > > > > On Tue, Aug 30, 2022 at 10:08 PM Stefan Roese wrote: > > > >> > > > >> Hi Tony, > > > >> > > > >> On 31.08.22 07:02, Stefan Roese wrote: > > > >>> Hi Tony, > > > >>> > > > >>> On 31.08.22 00:15, Tony Dinh wrote: > > > >>>> Hi Stefan, > > > >>>> > > > >>>> On Tue, Aug 30, 2022 at 4:53 AM Stefan Roese wrote: > > > >>>>> > > > >>>>> This patchset enhaces the recently added Orion Timer driver to > > > >>>>> support > > > >>>>> all other Kirkwood & 32bit MVEBU Armada platforms. Additionally, > > > >>>>> this > > > >>>>> timer support is then enabled per default for those platforms, so > > > >>>>> that > > > >>>>> the board config files don't need to be changed. Also necessary is > > > >>>>> some dts hacking, so that the timer DT node is available in early > > > >>>>> U-Boot stages. > > > >>>>> > > > >>>>> I've successfully tested this patchset on an Armada XP board. > > > >>>>> Additional > > > >>>>> test on other boards and platforms are very welcome and necessary. > > > >>>> > > > >>>> I've run some tests with the following 2 Kirkwood boards: Cloud > > > >>>> Engines Pogo V4 88F6192 (with CONFIG_DM_RTC and > > > >>>> CONFIG_RTC_EMULATION), > > > >>>> and Marvell Sheevaplug 88F6281 (with CONFIG_DM_RTC and > > > >>>> CONFIG_RTC_MV). > > > >>>> > > > >>>> It seems that it was either frozen or the timer did not expire at > > > >>>> some > > > >>>> subsequent sleep commands. Sometime it happened at 2nd command, some > > > >>>> time at a later sleep command. For example, > > > >>>> > > > >>>> === Pogo V4 (the 1st sleep command works correctly at 10 seconds on > > > >>>> my > > > >>>> stopwatch) > > > >>>> > > > >>>> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 13:38:24 > > > >>>> -0700) > > > >>>> Pogoplug V4 > > > >>>> > > > >>>> Hit any key to stop autoboot: 0 > > > >>>> Pogo_V4> sleep 10 > > > >>>> Pogo_V4> sleep 31.5 > > > >>>> > > > >>> > > > >>> Does the cmd interface support fractial numbers? Please test again > > > >>> with > > > >>> 31 or other integral numbers. > > > >>> > > > >>>> === Sheevaplug (RTC battery is old, so the date was not updated, but > > > >>>> the clock seems OK) > > > >>>> > > > >>>> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 14:14:24 > > > >>>> -0700) > > > >>>> Marvell-Sheevaplug > > > >>>> Hit any key to stop autoboot: 0 > > > >>>> => date > > > >>>> Date: 2000-01-01 (Saturday)Time: 0:02:55 > > > >>>> => sleep 10 > > > >>>> => date > > > >>>> Date: 2000-01-01 (Saturday)Time: 0:03:18 > > > >>>> => sleep 10 > > > >>>> => sleep 20.1 > > > >>>> > > > >>>> > > > >>>> Please let me know what I can do (i.e. perhaps running a debug > > > >>>> patch). > > > >>> > > > >>> Please see above. I assume that the fractional numbers result in very > > > >>> long numbers internally, which result in a frozen / hanging system. > > > >> > > > >> I just tested fractional numbers on another board and hey, it just > > > >> works. Learned
Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Hi Stefan,
On Wed, Aug 31, 2022 at 8:08 AM Tony Dinh wrote:
>
> Hi Stefan,
>
> On Wed, Aug 31, 2022 at 12:22 AM Stefan Roese wrote:
> >
> > Hi Tony,
> >
> > On 31.08.22 08:30, Tony Dinh wrote:
> > > Hi Stefan,
> > >
> > > On Tue, Aug 30, 2022 at 10:08 PM Stefan Roese wrote:
> > >>
> > >> Hi Tony,
> > >>
> > >> On 31.08.22 07:02, Stefan Roese wrote:
> > >>> Hi Tony,
> > >>>
> > >>> On 31.08.22 00:15, Tony Dinh wrote:
> > >>>> Hi Stefan,
> > >>>>
> > >>>> On Tue, Aug 30, 2022 at 4:53 AM Stefan Roese wrote:
> > >>>>>
> > >>>>> This patchset enhaces the recently added Orion Timer driver to support
> > >>>>> all other Kirkwood & 32bit MVEBU Armada platforms. Additionally, this
> > >>>>> timer support is then enabled per default for those platforms, so that
> > >>>>> the board config files don't need to be changed. Also necessary is
> > >>>>> some dts hacking, so that the timer DT node is available in early
> > >>>>> U-Boot stages.
> > >>>>>
> > >>>>> I've successfully tested this patchset on an Armada XP board.
> > >>>>> Additional
> > >>>>> test on other boards and platforms are very welcome and necessary.
> > >>>>
> > >>>> I've run some tests with the following 2 Kirkwood boards: Cloud
> > >>>> Engines Pogo V4 88F6192 (with CONFIG_DM_RTC and CONFIG_RTC_EMULATION),
> > >>>> and Marvell Sheevaplug 88F6281 (with CONFIG_DM_RTC and CONFIG_RTC_MV).
> > >>>>
> > >>>> It seems that it was either frozen or the timer did not expire at some
> > >>>> subsequent sleep commands. Sometime it happened at 2nd command, some
> > >>>> time at a later sleep command. For example,
> > >>>>
> > >>>> === Pogo V4 (the 1st sleep command works correctly at 10 seconds on my
> > >>>> stopwatch)
> > >>>>
> > >>>> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 13:38:24
> > >>>> -0700)
> > >>>> Pogoplug V4
> > >>>>
> > >>>> Hit any key to stop autoboot: 0
> > >>>> Pogo_V4> sleep 10
> > >>>> Pogo_V4> sleep 31.5
> > >>>>
> > >>>
> > >>> Does the cmd interface support fractial numbers? Please test again with
> > >>> 31 or other integral numbers.
> > >>>
> > >>>> === Sheevaplug (RTC battery is old, so the date was not updated, but
> > >>>> the clock seems OK)
> > >>>>
> > >>>> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 14:14:24
> > >>>> -0700)
> > >>>> Marvell-Sheevaplug
> > >>>> Hit any key to stop autoboot: 0
> > >>>> => date
> > >>>> Date: 2000-01-01 (Saturday)Time: 0:02:55
> > >>>> => sleep 10
> > >>>> => date
> > >>>> Date: 2000-01-01 (Saturday)Time: 0:03:18
> > >>>> => sleep 10
> > >>>> => sleep 20.1
> > >>>>
> > >>>>
> > >>>> Please let me know what I can do (i.e. perhaps running a debug patch).
> > >>>
> > >>> Please see above. I assume that the fractional numbers result in very
> > >>> long numbers internally, which result in a frozen / hanging system.
> > >>
> > >> I just tested fractional numbers on another board and hey, it just
> > >> works. Learned something new. So we seem to have a problem here. Let
> > >> me see, if I can find something.
> > >
> > > I've added debug printfs and possibly tracked down this issue. Seems
> > > like in the 2nd call to sleep, get_timer(0) did not reset the start
> > > number.
> > >
> > > cmd/sleep.c
> > > static int do_sleep(struct cmd_tbl *cmdtp, int flag, int argc,
> > > char *const argv[])
> > > {
> > > ulong start = get_timer(0);
> > >
> > > "do_sleep got a timer start = 2015" is the 1st call to sleep 5.
> > > "do_sleep got a timer start = 16304" is the 2nd call to sleep 10.
> > >
> > >
Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Hi Stefan,
On Wed, Aug 31, 2022 at 12:22 AM Stefan Roese wrote:
>
> Hi Tony,
>
> On 31.08.22 08:30, Tony Dinh wrote:
> > Hi Stefan,
> >
> > On Tue, Aug 30, 2022 at 10:08 PM Stefan Roese wrote:
> >>
> >> Hi Tony,
> >>
> >> On 31.08.22 07:02, Stefan Roese wrote:
> >>> Hi Tony,
> >>>
> >>> On 31.08.22 00:15, Tony Dinh wrote:
> >>>> Hi Stefan,
> >>>>
> >>>> On Tue, Aug 30, 2022 at 4:53 AM Stefan Roese wrote:
> >>>>>
> >>>>> This patchset enhaces the recently added Orion Timer driver to support
> >>>>> all other Kirkwood & 32bit MVEBU Armada platforms. Additionally, this
> >>>>> timer support is then enabled per default for those platforms, so that
> >>>>> the board config files don't need to be changed. Also necessary is
> >>>>> some dts hacking, so that the timer DT node is available in early
> >>>>> U-Boot stages.
> >>>>>
> >>>>> I've successfully tested this patchset on an Armada XP board. Additional
> >>>>> test on other boards and platforms are very welcome and necessary.
> >>>>
> >>>> I've run some tests with the following 2 Kirkwood boards: Cloud
> >>>> Engines Pogo V4 88F6192 (with CONFIG_DM_RTC and CONFIG_RTC_EMULATION),
> >>>> and Marvell Sheevaplug 88F6281 (with CONFIG_DM_RTC and CONFIG_RTC_MV).
> >>>>
> >>>> It seems that it was either frozen or the timer did not expire at some
> >>>> subsequent sleep commands. Sometime it happened at 2nd command, some
> >>>> time at a later sleep command. For example,
> >>>>
> >>>> === Pogo V4 (the 1st sleep command works correctly at 10 seconds on my
> >>>> stopwatch)
> >>>>
> >>>> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 13:38:24 -0700)
> >>>> Pogoplug V4
> >>>>
> >>>> Hit any key to stop autoboot: 0
> >>>> Pogo_V4> sleep 10
> >>>> Pogo_V4> sleep 31.5
> >>>>
> >>>
> >>> Does the cmd interface support fractial numbers? Please test again with
> >>> 31 or other integral numbers.
> >>>
> >>>> === Sheevaplug (RTC battery is old, so the date was not updated, but
> >>>> the clock seems OK)
> >>>>
> >>>> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 14:14:24 -0700)
> >>>> Marvell-Sheevaplug
> >>>> Hit any key to stop autoboot: 0
> >>>> => date
> >>>> Date: 2000-01-01 (Saturday)Time: 0:02:55
> >>>> => sleep 10
> >>>> => date
> >>>> Date: 2000-01-01 (Saturday)Time: 0:03:18
> >>>> => sleep 10
> >>>> => sleep 20.1
> >>>>
> >>>>
> >>>> Please let me know what I can do (i.e. perhaps running a debug patch).
> >>>
> >>> Please see above. I assume that the fractional numbers result in very
> >>> long numbers internally, which result in a frozen / hanging system.
> >>
> >> I just tested fractional numbers on another board and hey, it just
> >> works. Learned something new. So we seem to have a problem here. Let
> >> me see, if I can find something.
> >
> > I've added debug printfs and possibly tracked down this issue. Seems
> > like in the 2nd call to sleep, get_timer(0) did not reset the start
> > number.
> >
> > cmd/sleep.c
> > static int do_sleep(struct cmd_tbl *cmdtp, int flag, int argc,
> > char *const argv[])
> > {
> > ulong start = get_timer(0);
> >
> > "do_sleep got a timer start = 2015" is the 1st call to sleep 5.
> > "do_sleep got a timer start = 16304" is the 2nd call to sleep 10.
> >
> >
> > Pogo_V4> sleep 5
> > do_sleep got a timer start = 2015
> > do_sleep delay = 5000
> > do_sleep delay = 5000
> > do_sleep sleeping...
> > do_sleep start 2015 curent 100
> > do_sleep start 2015 curent 200
> > do_sleep start 2015 curent 300
> >
> > do_sleep start 2015 curent 4900
> > do_sleep end of sleep ... current = 5000
> > Pogo_V4>
> >
> > Pogo_V4> sleep 10
> > do_sleep got a timer start = 16304
> > do_sleep delay = 1
> > do_sleep delay = 1
> > do_sleep sleeping...
> >
> >
> >
> >
> > So somewhere in the DM timer, "start" got accumulated. I think each
> > get_timer(0) should be a different timer instance. It looks like the
> > same timer instance is used again and again, causing the "start "to
> > grow bigger, and at one point it might just overflow.
>
> Frankly I don't really understand the problem you describe above. What
> do you mean with "timer instance"? get_timer(0) will return different
> values, depending on when you call this function. So where exactly is
> the problem with the 2nd "sleep 10" above?
Please ignore what I said above! I misunderstood what get_timer()
does. I'll try again on another KIrkwood board to see if the behavior
will be the same.
Thanks,
Tony
> Thanks,
> Stefan
Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Hi Stefan, On Tue, Aug 30, 2022 at 11:19 PM Stefan Roese wrote: > > Hi Tony, > > On 31.08.22 07:08, Stefan Roese wrote: > > Hi Tony, > > > > On 31.08.22 07:02, Stefan Roese wrote: > >> Hi Tony, > >> > >> On 31.08.22 00:15, Tony Dinh wrote: > >>> Hi Stefan, > >>> > >>> On Tue, Aug 30, 2022 at 4:53 AM Stefan Roese wrote: > >>>> > >>>> This patchset enhaces the recently added Orion Timer driver to support > >>>> all other Kirkwood & 32bit MVEBU Armada platforms. Additionally, this > >>>> timer support is then enabled per default for those platforms, so that > >>>> the board config files don't need to be changed. Also necessary is > >>>> some dts hacking, so that the timer DT node is available in early > >>>> U-Boot stages. > >>>> > >>>> I've successfully tested this patchset on an Armada XP board. > >>>> Additional > >>>> test on other boards and platforms are very welcome and necessary. > >>> > >>> I've run some tests with the following 2 Kirkwood boards: Cloud > >>> Engines Pogo V4 88F6192 (with CONFIG_DM_RTC and CONFIG_RTC_EMULATION), > >>> and Marvell Sheevaplug 88F6281 (with CONFIG_DM_RTC and CONFIG_RTC_MV). > >>> > >>> It seems that it was either frozen or the timer did not expire at some > >>> subsequent sleep commands. Sometime it happened at 2nd command, some > >>> time at a later sleep command. For example, > >>> > >>> === Pogo V4 (the 1st sleep command works correctly at 10 seconds on my > >>> stopwatch) > >>> > >>> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 13:38:24 > >>> -0700) > >>> Pogoplug V4 > >>> > >>> Hit any key to stop autoboot: 0 > >>> Pogo_V4> sleep 10 > >>> Pogo_V4> sleep 31.5 > >>> > >> > >> Does the cmd interface support fractial numbers? Please test again with > >> 31 or other integral numbers. > >> > >>> === Sheevaplug (RTC battery is old, so the date was not updated, but > >>> the clock seems OK) > >>> > >>> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 14:14:24 > >>> -0700) > >>> Marvell-Sheevaplug > >>> Hit any key to stop autoboot: 0 > >>> => date > >>> Date: 2000-01-01 (Saturday)Time: 0:02:55 > >>> => sleep 10 > >>> => date > >>> Date: 2000-01-01 (Saturday)Time: 0:03:18 > >>> => sleep 10 > >>> => sleep 20.1 > >>> > >>> > >>> Please let me know what I can do (i.e. perhaps running a debug patch). > >> > >> Please see above. I assume that the fractional numbers result in very > >> long numbers internally, which result in a frozen / hanging system. > > > > I just tested fractional numbers on another board and hey, it just > > works. Learned something new. So we seem to have a problem here. Let > > me see, if I can find something. > > I can't reproduce this problem on my Armada XP platform. When your > system is frozen, can you interrupt the sleep cmd via Ctrl-C? Can you > please also test without this patchset applied, if a series of sleep > commands works fine there? Indeed, it works without the patchset. I ran an older version (U-Boot 2021.10) and entered some random sleep periods such as Pogo_V4> sleep 5 Pogo_V4> sleep 20.5 Pogo_V4> sleep 35 Pogo_V4> sleep 15.3 Pogo_V4> sleep 33.33 Pogo_V4> sleep 77.23 And it is also true that I could not do Ctrl-C when it is frozen running with the new timer. Thanks, Tony > Thanks, > Stefan
Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Hi Stefan,
On Tue, Aug 30, 2022 at 10:08 PM Stefan Roese wrote:
>
> Hi Tony,
>
> On 31.08.22 07:02, Stefan Roese wrote:
> > Hi Tony,
> >
> > On 31.08.22 00:15, Tony Dinh wrote:
> >> Hi Stefan,
> >>
> >> On Tue, Aug 30, 2022 at 4:53 AM Stefan Roese wrote:
> >>>
> >>> This patchset enhaces the recently added Orion Timer driver to support
> >>> all other Kirkwood & 32bit MVEBU Armada platforms. Additionally, this
> >>> timer support is then enabled per default for those platforms, so that
> >>> the board config files don't need to be changed. Also necessary is
> >>> some dts hacking, so that the timer DT node is available in early
> >>> U-Boot stages.
> >>>
> >>> I've successfully tested this patchset on an Armada XP board. Additional
> >>> test on other boards and platforms are very welcome and necessary.
> >>
> >> I've run some tests with the following 2 Kirkwood boards: Cloud
> >> Engines Pogo V4 88F6192 (with CONFIG_DM_RTC and CONFIG_RTC_EMULATION),
> >> and Marvell Sheevaplug 88F6281 (with CONFIG_DM_RTC and CONFIG_RTC_MV).
> >>
> >> It seems that it was either frozen or the timer did not expire at some
> >> subsequent sleep commands. Sometime it happened at 2nd command, some
> >> time at a later sleep command. For example,
> >>
> >> === Pogo V4 (the 1st sleep command works correctly at 10 seconds on my
> >> stopwatch)
> >>
> >> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 13:38:24 -0700)
> >> Pogoplug V4
> >>
> >> Hit any key to stop autoboot: 0
> >> Pogo_V4> sleep 10
> >> Pogo_V4> sleep 31.5
> >>
> >
> > Does the cmd interface support fractial numbers? Please test again with
> > 31 or other integral numbers.
> >
> >> === Sheevaplug (RTC battery is old, so the date was not updated, but
> >> the clock seems OK)
> >>
> >> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 14:14:24 -0700)
> >> Marvell-Sheevaplug
> >> Hit any key to stop autoboot: 0
> >> => date
> >> Date: 2000-01-01 (Saturday)Time: 0:02:55
> >> => sleep 10
> >> => date
> >> Date: 2000-01-01 (Saturday)Time: 0:03:18
> >> => sleep 10
> >> => sleep 20.1
> >>
> >>
> >> Please let me know what I can do (i.e. perhaps running a debug patch).
> >
> > Please see above. I assume that the fractional numbers result in very
> > long numbers internally, which result in a frozen / hanging system.
>
> I just tested fractional numbers on another board and hey, it just
> works. Learned something new. So we seem to have a problem here. Let
> me see, if I can find something.
I've added debug printfs and possibly tracked down this issue. Seems
like in the 2nd call to sleep, get_timer(0) did not reset the start
number.
cmd/sleep.c
static int do_sleep(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
ulong start = get_timer(0);
"do_sleep got a timer start = 2015" is the 1st call to sleep 5.
"do_sleep got a timer start = 16304" is the 2nd call to sleep 10.
Pogo_V4> sleep 5
do_sleep got a timer start = 2015
do_sleep delay = 5000
do_sleep delay = 5000
do_sleep sleeping...
do_sleep start 2015 curent 100
do_sleep start 2015 curent 200
do_sleep start 2015 curent 300
do_sleep start 2015 curent 4900
do_sleep end of sleep ... current = 5000
Pogo_V4>
Pogo_V4> sleep 10
do_sleep got a timer start = 16304
do_sleep delay = 1
do_sleep delay = 1
do_sleep sleeping...
So somewhere in the DM timer, "start" got accumulated. I think each
get_timer(0) should be a different timer instance. It looks like the
same timer instance is used again and again, causing the "start "to
grow bigger, and at one point it might just overflow.
Thanks,
Tony
> Thanks,
> Stefan
Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Hi Stefan, On Tue, Aug 30, 2022 at 4:53 AM Stefan Roese wrote: > > This patchset enhaces the recently added Orion Timer driver to support > all other Kirkwood & 32bit MVEBU Armada platforms. Additionally, this > timer support is then enabled per default for those platforms, so that > the board config files don't need to be changed. Also necessary is > some dts hacking, so that the timer DT node is available in early > U-Boot stages. > > I've successfully tested this patchset on an Armada XP board. Additional > test on other boards and platforms are very welcome and necessary. I've run some tests with the following 2 Kirkwood boards: Cloud Engines Pogo V4 88F6192 (with CONFIG_DM_RTC and CONFIG_RTC_EMULATION), and Marvell Sheevaplug 88F6281 (with CONFIG_DM_RTC and CONFIG_RTC_MV). It seems that it was either frozen or the timer did not expire at some subsequent sleep commands. Sometime it happened at 2nd command, some time at a later sleep command. For example, === Pogo V4 (the 1st sleep command works correctly at 10 seconds on my stopwatch) U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 13:38:24 -0700) Pogoplug V4 Hit any key to stop autoboot: 0 Pogo_V4> sleep 10 Pogo_V4> sleep 31.5 === Sheevaplug (RTC battery is old, so the date was not updated, but the clock seems OK) U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 14:14:24 -0700) Marvell-Sheevaplug Hit any key to stop autoboot: 0 => date Date: 2000-01-01 (Saturday)Time: 0:02:55 => sleep 10 => date Date: 2000-01-01 (Saturday)Time: 0:03:18 => sleep 10 => sleep 20.1 Please let me know what I can do (i.e. perhaps running a debug patch). Thanks, Tony > Thanks, > Stefan > > Stefan Roese (6): > timer: orion-timer: Add support for other Armada SoC's > timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support > arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms > arm: mvebu: dts: Makefile: Compile Armada 375 dtb in a separate step > arm: mvebu: dts: armada-375.dtsi: Add timer0 & timer1 > arm: mvebu: dts: mvebu-u-boot.dtsi: Add "u-boot,dm-pre-reloc" to timer > DT node > > arch/arm/Kconfig | 4 ++ > arch/arm/dts/Makefile | 6 ++- > arch/arm/dts/armada-375.dtsi | 4 +- > arch/arm/dts/mvebu-u-boot.dtsi| 11 > arch/arm/mach-mvebu/include/mach/config.h | 5 -- > drivers/timer/Kconfig | 5 +- > drivers/timer/orion-timer.c | 66 +-- > 7 files changed, 89 insertions(+), 12 deletions(-) > > -- > 2.37.2 >
Re: mvebu - switch to orion-timer
Hi Stefan, On Mon, Aug 29, 2022 at 5:50 AM Pali Rohár wrote: > > On Monday 29 August 2022 14:07:29 Stefan Roese wrote: > > Hi Michael, Pali, Tony & all, > > > > On 24.08.22 09:35, Michael Walle wrote: > > > Hi, > > > > > > > On 24.08.22 00:33, Pali Rohár wrote: > > > > > Hello Stefan! Now when U-Boot contains new orion-timer.c driver, which > > > > > Michael wrote, I think that it mvebu platform should switch to use it. > > > > > Because build process for armada boards prints deprecation warning > > > > > that > > > > > new timer is not being used. Could you look at it, if it is possible > > > > > to > > > > > do global switch for mach-mvebu and mach-kirkwood? I think it does not > > > > > make sense to do per-board switching as it is de-facto platform > > > > > related > > > > > code. > > > > > > > > Yes, I also though about this. > > > > > > > > But... > > > > > > > > In Linux we have 2 different timer clocksource drivers for Orion / > > > > Kirkwood and Armada XP / 370 etc: > > > > > > > > drivers/clocksource/timer-orion.c > > > > drivers/clocksource/timer-armada-370-xp.c > > > > > > > > I did not check, if and why this is necessary to handle those chips > > > > via different drivers yet. Perhaps later this week. Or someone of > > > > you beats me with this. ;) > > > > > > One thing which is definitely missing is > > > https://elixir.bootlin.com/u-boot/v2022.10-rc3/source/arch/arm/mach-mvebu/timer.c#L33 > > > > > > I didn't bother to handle that one. And of course all the compatibles are > > > missing. > > > > Thanks. Just a short status update: > > > > I'm currently busy with this CONFIG_TIMER migration for MVEBU / > > Kirkwood. Looks good so far - I can only test on Armada XP right now. > > So I need some extensive testing on all other kind of Marvell 32bit > > users / developers. I expect to send the first draft patchset in a few > > days. > > > > Thanks, > > Stefan > > I will test it on Turris Omnia - A385. I will test it on a few Kirkwood boards (88F6281, 88F6282, 88F6192). Please let us know if you have any particular suggestion for a good test. Best, Tony
Re: mvebu - switch to orion-timer
Hi Stefan, I would like to see this too. I was thinking of doing it per board, but it is more appropriate to enable it for Arch_Kirkwood and Arch_MVEBU. Thanks, Tony On Tue, Aug 23, 2022 at 3:33 PM Pali Rohár wrote: > > Hello Stefan! Now when U-Boot contains new orion-timer.c driver, which > Michael wrote, I think that it mvebu platform should switch to use it. > Because build process for armada boards prints deprecation warning that > new timer is not being used. Could you look at it, if it is possible to > do global switch for mach-mvebu and mach-kirkwood? I think it does not > make sense to do per-board switching as it is de-facto platform related > code.
Re: [PATCH] arm: mvebu: mbus: Fix mbus driver to work also after U-Boot relocation
Hi Pali,
On Mon, Aug 22, 2022 at 4:00 PM Pali Rohár wrote:
>
> On Wednesday 17 August 2022 08:17:36 Stefan Roese wrote:
> > On 10.08.22 14:46, Pali Rohár wrote:
> > > mbus driver is initialized from arch_cpu_init() callback which is called
> > > before relocation. This driver stores lot of functions and structure
> > > pointers into global variables, so it is data position dependent.
> > >
> > > Therefore after relocations all pointers are invalid and driver does not
> > > work anymore as all pointers referes to the old memory, which overlaps
> > > with
> > > CONFIG_SYS_LOAD_ADDR and ${loadaddr}.
> > >
> > > For example U-Boot fuse command crashes if loadaddr memory is cleared or
> > > rewritten by some image loaded by U-Boot load command.
> > >
> > >mw.w ${loadaddr} 0x0 1
> > >fuse read 0 1 2
> > >
> > > Fix this issue by removing of all mbus global variables in which are
> > > stored
> > > pointers to structures or functions which changes during relocation. And
> > > replace it by direct function calls (not via pointers). With this change
> > > fuse command finally works.
> > >
> > > Signed-off-by: Pali Rohár
> >
> > Reviewed-by: Stefan Roese
> >
> > Thanks,
> > Stefan
>
> Stefan, this is something which is needed to have fixed. Could you test
> this change on your boards and prepare for merging to master branch?
>
> Chris, could you also test this change for possible regressions?
>
> I have tested it on A385 Turris Omnia.
I did a couple regression tests and both are running fine!
Cloud Engines Pogo V4 (88F6192 SoC)
Zyxel NSA310S (88F6702 SoC)
All the best,
Tony
>
> > > ---
> > > arch/arm/mach-kirkwood/include/mach/cpu.h | 3 -
> > > arch/arm/mach-mvebu/include/mach/cpu.h| 3 -
> > > arch/arm/mach-mvebu/mbus.c| 167 +-
> > > board/alliedtelesis/x530/x530.c | 2 +-
> > > board/maxbcm/maxbcm.c | 8 +-
> > > board/theadorable/theadorable.c | 4 +-
> > > include/linux/mbus.h | 13 +-
> > > 7 files changed, 75 insertions(+), 125 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-kirkwood/include/mach/cpu.h
> > > b/arch/arm/mach-kirkwood/include/mach/cpu.h
> > > index 71c546f9acf6..d8639c60352b 100644
> > > --- a/arch/arm/mach-kirkwood/include/mach/cpu.h
> > > +++ b/arch/arm/mach-kirkwood/include/mach/cpu.h
> > > @@ -144,9 +144,6 @@ struct kwgpio_registers {
> > > u32 irq_level;
> > > };
> > > -/* Needed for dynamic (board-specific) mbus configuration */
> > > -extern struct mvebu_mbus_state mbus_state;
> > > -
> > > /*
> > >* functions
> > >*/
> > > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > index 689c96bd4eac..d9fa1f32aa52 100644
> > > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > @@ -122,9 +122,6 @@ struct sar_freq_modes {
> > > u32 d_clk;
> > > };
> > > -/* Needed for dynamic (board-specific) mbus configuration */
> > > -extern struct mvebu_mbus_state mbus_state;
> > > -
> > > /*
> > >* functions
> > >*/
> > > diff --git a/arch/arm/mach-mvebu/mbus.c b/arch/arm/mach-mvebu/mbus.c
> > > index 3b1b9f73ebf6..7092f6cc10c2 100644
> > > --- a/arch/arm/mach-mvebu/mbus.c
> > > +++ b/arch/arm/mach-mvebu/mbus.c
> > > @@ -88,31 +88,34 @@
> > > #define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
> > > -struct mvebu_mbus_state;
> > > -
> > > -struct mvebu_mbus_soc_data {
> > > - unsigned int num_wins;
> > > - unsigned int num_remappable_wins;
> > > - unsigned int (*win_cfg_offset)(const int win);
> > > - void (*setup_cpu_target)(struct mvebu_mbus_state *s);
> > > -};
> > > -
> > > -struct mvebu_mbus_state mbus_state
> > > - __section(".data");
> > > static struct mbus_dram_target_info mbus_dram_info
> > > __section(".data");
> > > +#if defined(CONFIG_ARCH_MVEBU)
> > > + #define MVEBU_MBUS_NUM_WINS 20
> > > + #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 8
> > > + #define MVEBU_MBUS_WIN_CFG_OFFSET(win)
> > > armada_370_xp_mbus_win_offset(win)
> > > +#elif defined(CONFIG_ARCH_KIRKWOOD)
> > > + #define MVEBU_MBUS_NUM_WINS 8
> > > + #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 4
> > > + #define MVEBU_MBUS_WIN_CFG_OFFSET(win) orion5x_mbus_win_offset(win)
> > > +#else
> > > + #error "No supported architecture"
> > > +#endif
> > > +
> > > +static unsigned int armada_370_xp_mbus_win_offset(int win);
> > > +static unsigned int orion5x_mbus_win_offset(int win);
> > > +
> > > /*
> > >* Functions to manipulate the address decoding windows
> > >*/
> > > -static void mvebu_mbus_read_window(struct mvebu_mbus_state *mbus,
> > > - int win, int *enabled, u64 *base,
> > > +static void mvebu_mbus_read_window(int win, int *enabled, u64 *base,
> > >u32 *size, u8 *target, u8 *attr,
> > >u64 *remap)
> > > {
> > > - void __iomem *addr = mb
[PATCH] arm: kirkwood: Add CONFIG_SUPPORT_PASSING_ATAGS
Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy image method of booting. Debian and OpenWrt installer use uImage with appended DTB for these Kirkwood boards. Signed-off-by: Tony Dinh --- configs/dockstar_defconfig | 3 +++ configs/dreamplug_defconfig | 3 +++ configs/goflexhome_defconfig | 3 +++ configs/iconnect_defconfig | 3 +++ configs/pogo_e02_defconfig | 3 +++ configs/sheevaplug_defconfig | 3 +++ 6 files changed, 18 insertions(+) diff --git a/configs/dockstar_defconfig b/configs/dockstar_defconfig index 6f99cdd44b..82eb81e4de 100644 --- a/configs/dockstar_defconfig +++ b/configs/dockstar_defconfig @@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y CONFIG_ARCH_CPU_INIT=y CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_KIRKWOOD=y +CONFIG_SUPPORT_PASSING_ATAGS=y +CONFIG_CMDLINE_TAG=y +CONFIG_INITRD_TAG=y CONFIG_SYS_KWD_CONFIG="board/Seagate/dockstar/kwbimage.cfg" CONFIG_SYS_TEXT_BASE=0x60 CONFIG_NR_DRAM_BANKS=2 diff --git a/configs/dreamplug_defconfig b/configs/dreamplug_defconfig index d6b55636ba..ccc9ee38de 100644 --- a/configs/dreamplug_defconfig +++ b/configs/dreamplug_defconfig @@ -3,6 +3,9 @@ CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_SYS_DCACHE_OFF=y CONFIG_ARCH_CPU_INIT=y CONFIG_ARCH_KIRKWOOD=y +CONFIG_SUPPORT_PASSING_ATAGS=y +CONFIG_CMDLINE_TAG=y +CONFIG_INITRD_TAG=y CONFIG_SYS_KWD_CONFIG="board/Marvell/dreamplug/kwbimage.cfg" CONFIG_SYS_TEXT_BASE=0x60 CONFIG_NR_DRAM_BANKS=2 diff --git a/configs/goflexhome_defconfig b/configs/goflexhome_defconfig index 1ef4d6c881..3cfbe7d558 100644 --- a/configs/goflexhome_defconfig +++ b/configs/goflexhome_defconfig @@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y CONFIG_ARCH_CPU_INIT=y CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_KIRKWOOD=y +CONFIG_SUPPORT_PASSING_ATAGS=y +CONFIG_CMDLINE_TAG=y +CONFIG_INITRD_TAG=y CONFIG_SYS_KWD_CONFIG="board/Seagate/goflexhome/kwbimage.cfg" CONFIG_SYS_TEXT_BASE=0x60 CONFIG_NR_DRAM_BANKS=2 diff --git a/configs/iconnect_defconfig b/configs/iconnect_defconfig index 7adf76d777..fc5928b9df 100644 --- a/configs/iconnect_defconfig +++ b/configs/iconnect_defconfig @@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y CONFIG_ARCH_CPU_INIT=y CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_KIRKWOOD=y +CONFIG_SUPPORT_PASSING_ATAGS=y +CONFIG_CMDLINE_TAG=y +CONFIG_INITRD_TAG=y CONFIG_SYS_KWD_CONFIG="board/iomega/iconnect/kwbimage.cfg" CONFIG_SYS_TEXT_BASE=0x60 CONFIG_NR_DRAM_BANKS=2 diff --git a/configs/pogo_e02_defconfig b/configs/pogo_e02_defconfig index e1a2517eb6..0b647e8af9 100644 --- a/configs/pogo_e02_defconfig +++ b/configs/pogo_e02_defconfig @@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y CONFIG_ARCH_CPU_INIT=y CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_KIRKWOOD=y +CONFIG_SUPPORT_PASSING_ATAGS=y +CONFIG_CMDLINE_TAG=y +CONFIG_INITRD_TAG=y CONFIG_SYS_KWD_CONFIG="board/cloudengines/pogo_e02/kwbimage.cfg" CONFIG_SYS_TEXT_BASE=0x60 CONFIG_NR_DRAM_BANKS=2 diff --git a/configs/sheevaplug_defconfig b/configs/sheevaplug_defconfig index fa1e7bd2c0..cc9cd7d9c9 100644 --- a/configs/sheevaplug_defconfig +++ b/configs/sheevaplug_defconfig @@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y CONFIG_ARCH_CPU_INIT=y CONFIG_SYS_THUMB_BUILD=y CONFIG_ARCH_KIRKWOOD=y +CONFIG_SUPPORT_PASSING_ATAGS=y +CONFIG_CMDLINE_TAG=y +CONFIG_INITRD_TAG=y CONFIG_SYS_KWD_CONFIG="board/Marvell/sheevaplug/kwbimage.cfg" CONFIG_SYS_TEXT_BASE=0x60 CONFIG_NR_DRAM_BANKS=2 -- 2.30.2
Re: [RESEND PATCH] arm: kirkwood: nsa310s: Add Distro boot capability
Hi Stefan,
On Thu, Aug 11, 2022 at 10:29 PM Stefan Roese wrote:
>
> Hi Tony,
>
> On 12.08.22 01:40, Tony Dinh wrote:
> > - Add distro boot to board include file and deconfig file
> > - Miscellaneous changes:
> > - Remove Gerald from maintainer list (email bounced)
> > - Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
> > kernel method of booting (e.g. OpenWrt) with appended DTB.
> > - Add CONFIG_UBIFS_SILENCE_MSG to reduce binary size.
> >
> > Note that this patch is depended on the following patch:
> > https://patchwork.ozlabs.org/project/uboot/patch/20220807192709.21717-1-p...@kernel.org/
> >
> > Signed-off-by: Tony Dinh
>
> So did you change anything here? Last time you mentioned, that you need
> to resend this patch. I assumed that you needed to make some changes.
Sorry, I was not clear about the reason for RESEND. I inadvertently
removed the existing envs for booting with the UBIFS partition. In
this patch, I only implemented distro boot for USB and SATA, so I
should keep UBI booting the same way as before. In this RESED patch
I've restored those envs.
#define CONFIG_EXTRA_ENV_SETTINGS \
"console=console=ttyS0,115200\0" \
"kernel=/boot/zImage\0" \
"fdt=/boot/nsa310s.dtb\0" \
- "bootargs_root=ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw\0"
+ "bootargs_root=ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw\0" \
+ LOAD_ADDRESS_ENV_SETTINGS \
+ BOOTENV
+
Thanks,
Tony
>
> Thanks,
> Stefan
>
> > ---
> >
> > board/zyxel/nsa310s/MAINTAINERS | 1 -
> > configs/nsa310s_defconfig | 17 +
> > include/configs/nsa310s.h | 31 +--
> > 3 files changed, 34 insertions(+), 15 deletions(-)
> >
> > diff --git a/board/zyxel/nsa310s/MAINTAINERS
> > b/board/zyxel/nsa310s/MAINTAINERS
> > index d153758c21..11106acf3e 100644
> > --- a/board/zyxel/nsa310s/MAINTAINERS
> > +++ b/board/zyxel/nsa310s/MAINTAINERS
> > @@ -1,5 +1,4 @@
> > NSA310S BOARD
> > -M: Gerald Kerma
> > M: Tony Dinh
> > M: Luka Perkov
> > S: Maintained
> > diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig
> > index 2b39ae74b3..a5f01ef88e 100644
> > --- a/configs/nsa310s_defconfig
> > +++ b/configs/nsa310s_defconfig
> > @@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y
> > CONFIG_ARCH_CPU_INIT=y
> > CONFIG_SYS_THUMB_BUILD=y
> > CONFIG_ARCH_KIRKWOOD=y
> > +CONFIG_SUPPORT_PASSING_ATAGS=y
> > +CONFIG_CMDLINE_TAG=y
> > +CONFIG_INITRD_TAG=y
> > CONFIG_SYS_KWD_CONFIG="board/zyxel/nsa310s/kwbimage.cfg"
> > CONFIG_SYS_TEXT_BASE=0x60
> > CONFIG_SYS_MALLOC_F_LEN=0x400
> > @@ -14,35 +17,25 @@ CONFIG_ENV_OFFSET=0xE
> > CONFIG_DEFAULT_DEVICE_TREE="kirkwood-nsa310s"
> > CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server"
> > CONFIG_SYS_LOAD_ADDR=0x80
> > +CONFIG_DISTRO_DEFAULTS=y
> > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
> > CONFIG_BOOTDELAY=3
> > -CONFIG_USE_BOOTCOMMAND=y
> > -CONFIG_BOOTCOMMAND="setenv bootargs ${console} ${mtdparts}
> > ${bootargs_root}; ubi part root; ubifsmount ubi:rootfs; ubifsload 0x80
> > ${kernel}; ubifsload 0x70 ${fdt}; ubifsumount; fdt addr 0x70; fdt
> > resize; fdt chosen; bootz 0x80 - 0x70"
> > CONFIG_USE_PREBOOT=y
> > # CONFIG_DISPLAY_BOARDINFO is not set
> > -CONFIG_HUSH_PARSER=y
> > CONFIG_SYS_PROMPT="NSA310s> "
> > CONFIG_SYS_MAXARGS=32
> > CONFIG_SYS_PBSIZE=1050
> > -CONFIG_CMD_BOOTZ=y
> > # CONFIG_CMD_FLASH is not set
> > CONFIG_CMD_NAND=y
> > CONFIG_CMD_SATA=y
> > CONFIG_CMD_USB=y
> > # CONFIG_CMD_SETEXPR is not set
> > -CONFIG_CMD_DHCP=y
> > -CONFIG_CMD_MII=y
> > -CONFIG_CMD_PING=y
> > -CONFIG_CMD_EXT2=y
> > -CONFIG_CMD_FAT=y
> > -CONFIG_CMD_FS_GENERIC=y
> > CONFIG_CMD_JFFS2=y
> > CONFIG_CMD_MTDPARTS=y
> > CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
> >
> > CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:0xe@0x0(uboot),0x2@0xe(uboot_env),0x10@0x10(second_stage_uboot),-@0x20(root)"
> > CONFIG_CMD_UBI=y
> > -CONFIG_ISO_PARTITION=y
> > CONFIG_OF_CONTROL=y
> > CONFIG_ENV_OVERWRITE=y
> > CONFIG_ENV_IS_IN_NAND=y
> > @@ -65,6 +58,6 @@ CONFIG_MII=y
> > CONFIG_SYS_NS16550=y
> > CONFIG_USB=y
> > CONFIG
[RESEND PATCH] arm: kirkwood: nsa310s: Add Distro boot capability
- Add distro boot to board include file and deconfig file
- Miscellaneous changes:
- Remove Gerald from maintainer list (email bounced)
- Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
kernel method of booting (e.g. OpenWrt) with appended DTB.
- Add CONFIG_UBIFS_SILENCE_MSG to reduce binary size.
Note that this patch is depended on the following patch:
https://patchwork.ozlabs.org/project/uboot/patch/20220807192709.21717-1-p...@kernel.org/
Signed-off-by: Tony Dinh
---
board/zyxel/nsa310s/MAINTAINERS | 1 -
configs/nsa310s_defconfig | 17 +
include/configs/nsa310s.h | 31 +--
3 files changed, 34 insertions(+), 15 deletions(-)
diff --git a/board/zyxel/nsa310s/MAINTAINERS b/board/zyxel/nsa310s/MAINTAINERS
index d153758c21..11106acf3e 100644
--- a/board/zyxel/nsa310s/MAINTAINERS
+++ b/board/zyxel/nsa310s/MAINTAINERS
@@ -1,5 +1,4 @@
NSA310S BOARD
-M: Gerald Kerma
M: Tony Dinh
M: Luka Perkov
S: Maintained
diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig
index 2b39ae74b3..a5f01ef88e 100644
--- a/configs/nsa310s_defconfig
+++ b/configs/nsa310s_defconfig
@@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_KIRKWOOD=y
+CONFIG_SUPPORT_PASSING_ATAGS=y
+CONFIG_CMDLINE_TAG=y
+CONFIG_INITRD_TAG=y
CONFIG_SYS_KWD_CONFIG="board/zyxel/nsa310s/kwbimage.cfg"
CONFIG_SYS_TEXT_BASE=0x60
CONFIG_SYS_MALLOC_F_LEN=0x400
@@ -14,35 +17,25 @@ CONFIG_ENV_OFFSET=0xE
CONFIG_DEFAULT_DEVICE_TREE="kirkwood-nsa310s"
CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server"
CONFIG_SYS_LOAD_ADDR=0x80
+CONFIG_DISTRO_DEFAULTS=y
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
CONFIG_BOOTDELAY=3
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="setenv bootargs ${console} ${mtdparts} ${bootargs_root};
ubi part root; ubifsmount ubi:rootfs; ubifsload 0x80 ${kernel}; ubifsload
0x70 ${fdt}; ubifsumount; fdt addr 0x70; fdt resize; fdt chosen; bootz
0x80 - 0x70"
CONFIG_USE_PREBOOT=y
# CONFIG_DISPLAY_BOARDINFO is not set
-CONFIG_HUSH_PARSER=y
CONFIG_SYS_PROMPT="NSA310s> "
CONFIG_SYS_MAXARGS=32
CONFIG_SYS_PBSIZE=1050
-CONFIG_CMD_BOOTZ=y
# CONFIG_CMD_FLASH is not set
CONFIG_CMD_NAND=y
CONFIG_CMD_SATA=y
CONFIG_CMD_USB=y
# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
CONFIG_CMD_JFFS2=y
CONFIG_CMD_MTDPARTS=y
CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:0xe@0x0(uboot),0x2@0xe(uboot_env),0x10@0x10(second_stage_uboot),-@0x20(root)"
CONFIG_CMD_UBI=y
-CONFIG_ISO_PARTITION=y
CONFIG_OF_CONTROL=y
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_IS_IN_NAND=y
@@ -65,6 +58,6 @@ CONFIG_MII=y
CONFIG_SYS_NS16550=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_STORAGE=y
+CONFIG_UBIFS_SILENCE_MSG=y
CONFIG_LZMA=y
CONFIG_BZIP2=y
diff --git a/include/configs/nsa310s.h b/include/configs/nsa310s.h
index 027a47b5a3..62f0701180 100644
--- a/include/configs/nsa310s.h
+++ b/include/configs/nsa310s.h
@@ -9,15 +9,42 @@
#ifndef _CONFIG_NSA310S_H
#define _CONFIG_NSA310S_H
+/*
+ * mv-common.h should be defined after CMD configs since it used them
+ * to enable certain macros
+ */
#include "mv-common.h"
-/* default environment variables */
+/* Include the common distro boot environment */
+#ifndef CONFIG_SPL_BUILD
+
+#define BOOT_TARGET_DEVICES(func) \
+ func(USB, usb, 0) \
+ func(SATA, sata, 0) \
+ func(DHCP, dhcp, na)
+
+#define KERNEL_ADDR_R __stringify(0x80)
+#define FDT_ADDR_R __stringify(0x2c0)
+#define RAMDISK_ADDR_R __stringify(0x0110)
+#define SCRIPT_ADDR_R __stringify(0x20)
+
+#define LOAD_ADDRESS_ENV_SETTINGS \
+ "kernel_addr_r=" KERNEL_ADDR_R "\0" \
+ "fdt_addr_r=" FDT_ADDR_R "\0" \
+ "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \
+ "scriptaddr=" SCRIPT_ADDR_R "\0"
+
+#include
#define CONFIG_EXTRA_ENV_SETTINGS \
"console=console=ttyS0,115200\0" \
"kernel=/boot/zImage\0" \
"fdt=/boot/nsa310s.dtb\0" \
- "bootargs_root=ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw\0"
+ "bootargs_root=ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw\0" \
+ LOAD_ADDRESS_ENV_SETTINGS \
+ BOOTENV
+
+#endif /* CONFIG_SPL_BUILD */
/* Ethernet driver configuration */
#define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
--
2.30.2
Re: [PATCH] arm: kirkwood: nsa310s: Add Distro boot capability
Hi Stefan,
I need to resend this patch. Sorry for the noise!
Thanks,
Tony
On Mon, Aug 8, 2022 at 7:35 PM Tony Dinh wrote:
>
> - Add distro boot to board include file and deconfig file
> - Miscellaneous changes:
> - Remove Gerald from maintainer list (email bounced)
> - Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
> kernel method of booting (e.g. OpenWrt) with appended DTB.
> - Add CONFIG_UBIFS_SILENCE_MSG to reduce binary size.
>
> Note that this patch is depended on the following patch:
> https://patchwork.ozlabs.org/project/uboot/patch/20220807192709.21717-1-p...@kernel.org/
>
> Signed-off-by: Tony Dinh
> ---
>
> board/zyxel/nsa310s/MAINTAINERS | 1 -
> configs/nsa310s_defconfig | 17
> include/configs/nsa310s.h | 48 +
> 3 files changed, 48 insertions(+), 18 deletions(-)
>
> diff --git a/board/zyxel/nsa310s/MAINTAINERS b/board/zyxel/nsa310s/MAINTAINERS
> index d153758c21..11106acf3e 100644
> --- a/board/zyxel/nsa310s/MAINTAINERS
> +++ b/board/zyxel/nsa310s/MAINTAINERS
> @@ -1,5 +1,4 @@
> NSA310S BOARD
> -M: Gerald Kerma
> M: Tony Dinh
> M: Luka Perkov
> S: Maintained
> diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig
> index 2b39ae74b3..a5f01ef88e 100644
> --- a/configs/nsa310s_defconfig
> +++ b/configs/nsa310s_defconfig
> @@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y
> CONFIG_ARCH_CPU_INIT=y
> CONFIG_SYS_THUMB_BUILD=y
> CONFIG_ARCH_KIRKWOOD=y
> +CONFIG_SUPPORT_PASSING_ATAGS=y
> +CONFIG_CMDLINE_TAG=y
> +CONFIG_INITRD_TAG=y
> CONFIG_SYS_KWD_CONFIG="board/zyxel/nsa310s/kwbimage.cfg"
> CONFIG_SYS_TEXT_BASE=0x60
> CONFIG_SYS_MALLOC_F_LEN=0x400
> @@ -14,35 +17,25 @@ CONFIG_ENV_OFFSET=0xE
> CONFIG_DEFAULT_DEVICE_TREE="kirkwood-nsa310s"
> CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server"
> CONFIG_SYS_LOAD_ADDR=0x80
> +CONFIG_DISTRO_DEFAULTS=y
> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
> CONFIG_BOOTDELAY=3
> -CONFIG_USE_BOOTCOMMAND=y
> -CONFIG_BOOTCOMMAND="setenv bootargs ${console} ${mtdparts} ${bootargs_root};
> ubi part root; ubifsmount ubi:rootfs; ubifsload 0x80 ${kernel}; ubifsload
> 0x70 ${fdt}; ubifsumount; fdt addr 0x70; fdt resize; fdt chosen;
> bootz 0x80 - 0x70"
> CONFIG_USE_PREBOOT=y
> # CONFIG_DISPLAY_BOARDINFO is not set
> -CONFIG_HUSH_PARSER=y
> CONFIG_SYS_PROMPT="NSA310s> "
> CONFIG_SYS_MAXARGS=32
> CONFIG_SYS_PBSIZE=1050
> -CONFIG_CMD_BOOTZ=y
> # CONFIG_CMD_FLASH is not set
> CONFIG_CMD_NAND=y
> CONFIG_CMD_SATA=y
> CONFIG_CMD_USB=y
> # CONFIG_CMD_SETEXPR is not set
> -CONFIG_CMD_DHCP=y
> -CONFIG_CMD_MII=y
> -CONFIG_CMD_PING=y
> -CONFIG_CMD_EXT2=y
> -CONFIG_CMD_FAT=y
> -CONFIG_CMD_FS_GENERIC=y
> CONFIG_CMD_JFFS2=y
> CONFIG_CMD_MTDPARTS=y
> CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
>
> CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:0xe@0x0(uboot),0x2@0xe(uboot_env),0x10@0x10(second_stage_uboot),-@0x20(root)"
> CONFIG_CMD_UBI=y
> -CONFIG_ISO_PARTITION=y
> CONFIG_OF_CONTROL=y
> CONFIG_ENV_OVERWRITE=y
> CONFIG_ENV_IS_IN_NAND=y
> @@ -65,6 +58,6 @@ CONFIG_MII=y
> CONFIG_SYS_NS16550=y
> CONFIG_USB=y
> CONFIG_USB_EHCI_HCD=y
> -CONFIG_USB_STORAGE=y
> +CONFIG_UBIFS_SILENCE_MSG=y
> CONFIG_LZMA=y
> CONFIG_BZIP2=y
> diff --git a/include/configs/nsa310s.h b/include/configs/nsa310s.h
> index 027a47b5a3..a538721c45 100644
> --- a/include/configs/nsa310s.h
> +++ b/include/configs/nsa310s.h
> @@ -9,15 +9,53 @@
> #ifndef _CONFIG_NSA310S_H
> #define _CONFIG_NSA310S_H
>
> +/*
> + * mv-common.h should be defined after CMD configs since it used them
> + * to enable certain macros
> + */
> #include "mv-common.h"
>
> -/* default environment variables */
> +/* Include the common distro boot environment */
> +#ifndef CONFIG_SPL_BUILD
> +
> +#ifdef CONFIG_SATA
> +#define BOOT_TARGET_DEVICES_SATA(func) func(SATA, sata, 0)
> +#else
> +#define BOOT_TARGET_DEVICES_SATA(func)
> +#endif
> +
> +#ifdef CONFIG_USB_STORAGE
> +#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
> +#else
> +#define BOOT_TARGET_DEVICES_USB(func)
> +#endif
> +
> +#define BOOT_TARGET_DEVICES(func) \
> + BOOT_TARGET_DEVICES_USB(func) \
> + BOOT_TARGET_DEVICES_SATA(func) \
> + func(DHCP, dhcp, na)
> +
> +#define KERNEL_ADDR_R __stringify(0x80)
> +#define FDT_ADDR_R __stringify(0x2c0)
> +#define RAMDISK_ADDR_R __stringify(0x0110)
> +#define SCRIPT_A
[PATCH] arm: kirkwood: pogo_v4: Add Distro boot capability
- Add distro boot to board include file and deconfig file
- Miscellaneous changes:
- Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
kernel method of booting (e.g. OpenWrt) with appended DTB.
- Add CONFIG_LTO and CONFIG_UBIFS_SILENCE_MSG, and disable some
unused configs to reduce binary size.
Note that this patch is depended on the following patch:
https://patchwork.ozlabs.org/project/uboot/patch/20220807192709.21717-1-p...@kernel.org/
Signed-off-by: Tony Dinh
---
configs/pogo_v4_defconfig | 25 --
include/configs/pogo_v4.h | 54 +--
2 files changed, 57 insertions(+), 22 deletions(-)
diff --git a/configs/pogo_v4_defconfig b/configs/pogo_v4_defconfig
index c62c88f1b5..748842100e 100644
--- a/configs/pogo_v4_defconfig
+++ b/configs/pogo_v4_defconfig
@@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_KIRKWOOD=y
+CONFIG_SUPPORT_PASSING_ATAGS=y
+CONFIG_CMDLINE_TAG=y
+CONFIG_INITRD_TAG=y
CONFIG_SYS_KWD_CONFIG="board/cloudengines/pogo_v4/kwbimage.cfg"
CONFIG_SYS_TEXT_BASE=0x60
CONFIG_SYS_MALLOC_F_LEN=0x400
@@ -13,23 +16,24 @@ CONFIG_ENV_OFFSET=0xC
CONFIG_DEFAULT_DEVICE_TREE="kirkwood-pogoplug-series-4"
CONFIG_IDENT_STRING="\nPogoplug V4"
CONFIG_SYS_LOAD_ADDR=0x80
+CONFIG_LTO=y
+CONFIG_DISTRO_DEFAULTS=y
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
CONFIG_BOOTSTAGE=y
CONFIG_SHOW_BOOT_PROGRESS=y
CONFIG_BOOTDELAY=10
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="setenv bootargs ${bootargs_console}; run bootcmd_usb;
bootm 0x0080 0x0110 0x2c0"
CONFIG_USE_PREBOOT=y
CONFIG_BOARD_LATE_INIT=y
-CONFIG_HUSH_PARSER=y
CONFIG_SYS_PROMPT="Pogo_V4> "
CONFIG_SYS_MAXARGS=32
CONFIG_SYS_PBSIZE=1050
-CONFIG_CMD_BOOTZ=y
# CONFIG_BOOTM_PLAN9 is not set
# CONFIG_BOOTM_RTEMS is not set
# CONFIG_BOOTM_VXWORKS is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_XIMG is not set
# CONFIG_CMD_FLASH is not set
CONFIG_CMD_MMC=y
CONFIG_CMD_MTD=y
@@ -37,22 +41,14 @@ CONFIG_CMD_NAND=y
CONFIG_CMD_PCI=y
CONFIG_CMD_SATA=y
CONFIG_CMD_USB=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
CONFIG_CMD_SNTP=y
CONFIG_CMD_DNS=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
+# CONFIG_CMD_BLOCK_CACHE is not set
CONFIG_CMD_JFFS2=y
CONFIG_CMD_MTDPARTS=y
CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root)"
CONFIG_CMD_UBI=y
-CONFIG_ISO_PARTITION=y
-CONFIG_EFI_PARTITION=y
CONFIG_PARTITION_TYPE_GUID=y
CONFIG_OF_CONTROL=y
CONFIG_ENV_OVERWRITE=y
@@ -62,6 +58,7 @@ CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_NETCONSOLE=y
CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y
CONFIG_DM=y
+# CONFIG_DM_WARN is not set
CONFIG_SATA_MV=y
CONFIG_SYS_SATA_MAX_DEVICE=1
CONFIG_LBA48=y
@@ -84,6 +81,6 @@ CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_STORAGE=y
CONFIG_JFFS2_LZO=y
CONFIG_JFFS2_NAND=y
+CONFIG_UBIFS_SILENCE_MSG=y
diff --git a/include/configs/pogo_v4.h b/include/configs/pogo_v4.h
index 7fff78b7b5..b5ce2dd13d 100644
--- a/include/configs/pogo_v4.h
+++ b/include/configs/pogo_v4.h
@@ -21,15 +21,53 @@
*/
#include "mv-common.h"
-/*
- * Default environment variables
- */
+/* Include the common distro boot environment */
+#ifndef CONFIG_SPL_BUILD
+
+#ifdef CONFIG_MMC
+#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0)
+#else
+#define BOOT_TARGET_DEVICES_MMC(func)
+#endif
+
+#ifdef CONFIG_SATA
+#define BOOT_TARGET_DEVICES_SATA(func) func(SATA, sata, 0)
+#else
+#define BOOT_TARGET_DEVICES_SATA(func)
+#endif
+
+#ifdef CONFIG_USB_STORAGE
+#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
+#else
+#define BOOT_TARGET_DEVICES_USB(func)
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+ BOOT_TARGET_DEVICES_MMC(func) \
+ BOOT_TARGET_DEVICES_USB(func) \
+ BOOT_TARGET_DEVICES_SATA(func) \
+ func(DHCP, dhcp, na)
+
+#define KERNEL_ADDR_R __stringify(0x80)
+#define FDT_ADDR_R __stringify(0x2c0)
+#define RAMDISK_ADDR_R __stringify(0x0110)
+#define SCRIPT_ADDR_R __stringify(0x20)
+
+#define LOAD_ADDRESS_ENV_SETTINGS \
+ "kernel_addr_r=" KERNEL_ADDR_R "\0" \
+ "fdt_addr_r=" FDT_ADDR_R "\0" \
+ "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \
+ "scriptaddr=" SCRIPT_ADDR_R "\0"
+
+#include
+
#define CONFIG_EXTRA_ENV_SETTINGS \
- "dtb_file=/boot/dts/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
- "bootargs_console=console=ttyS0,115200\0" \
- "bootcmd_usb=usb start; load usb 0:1 0x0080 /boot/uImage; " \
- "load usb 0:1 0x0110 /boot/uInitrd; " \
-
[PATCH] arm: kirkwood: nsa310s: Add Distro boot capability
- Add distro boot to board include file and deconfig file
- Miscellaneous changes:
- Remove Gerald from maintainer list (email bounced)
- Add CONFIG_SUPPORT_PASSING_ATAGS and friends to support legacy
kernel method of booting (e.g. OpenWrt) with appended DTB.
- Add CONFIG_UBIFS_SILENCE_MSG to reduce binary size.
Note that this patch is depended on the following patch:
https://patchwork.ozlabs.org/project/uboot/patch/20220807192709.21717-1-p...@kernel.org/
Signed-off-by: Tony Dinh
---
board/zyxel/nsa310s/MAINTAINERS | 1 -
configs/nsa310s_defconfig | 17
include/configs/nsa310s.h | 48 +
3 files changed, 48 insertions(+), 18 deletions(-)
diff --git a/board/zyxel/nsa310s/MAINTAINERS b/board/zyxel/nsa310s/MAINTAINERS
index d153758c21..11106acf3e 100644
--- a/board/zyxel/nsa310s/MAINTAINERS
+++ b/board/zyxel/nsa310s/MAINTAINERS
@@ -1,5 +1,4 @@
NSA310S BOARD
-M: Gerald Kerma
M: Tony Dinh
M: Luka Perkov
S: Maintained
diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig
index 2b39ae74b3..a5f01ef88e 100644
--- a/configs/nsa310s_defconfig
+++ b/configs/nsa310s_defconfig
@@ -4,6 +4,9 @@ CONFIG_SYS_DCACHE_OFF=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_KIRKWOOD=y
+CONFIG_SUPPORT_PASSING_ATAGS=y
+CONFIG_CMDLINE_TAG=y
+CONFIG_INITRD_TAG=y
CONFIG_SYS_KWD_CONFIG="board/zyxel/nsa310s/kwbimage.cfg"
CONFIG_SYS_TEXT_BASE=0x60
CONFIG_SYS_MALLOC_F_LEN=0x400
@@ -14,35 +17,25 @@ CONFIG_ENV_OFFSET=0xE
CONFIG_DEFAULT_DEVICE_TREE="kirkwood-nsa310s"
CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server"
CONFIG_SYS_LOAD_ADDR=0x80
+CONFIG_DISTRO_DEFAULTS=y
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc8012000
CONFIG_BOOTDELAY=3
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="setenv bootargs ${console} ${mtdparts} ${bootargs_root};
ubi part root; ubifsmount ubi:rootfs; ubifsload 0x80 ${kernel}; ubifsload
0x70 ${fdt}; ubifsumount; fdt addr 0x70; fdt resize; fdt chosen; bootz
0x80 - 0x70"
CONFIG_USE_PREBOOT=y
# CONFIG_DISPLAY_BOARDINFO is not set
-CONFIG_HUSH_PARSER=y
CONFIG_SYS_PROMPT="NSA310s> "
CONFIG_SYS_MAXARGS=32
CONFIG_SYS_PBSIZE=1050
-CONFIG_CMD_BOOTZ=y
# CONFIG_CMD_FLASH is not set
CONFIG_CMD_NAND=y
CONFIG_CMD_SATA=y
CONFIG_CMD_USB=y
# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
CONFIG_CMD_JFFS2=y
CONFIG_CMD_MTDPARTS=y
CONFIG_MTDIDS_DEFAULT="nand0=orion_nand"
CONFIG_MTDPARTS_DEFAULT="mtdparts=orion_nand:0xe@0x0(uboot),0x2@0xe(uboot_env),0x10@0x10(second_stage_uboot),-@0x20(root)"
CONFIG_CMD_UBI=y
-CONFIG_ISO_PARTITION=y
CONFIG_OF_CONTROL=y
CONFIG_ENV_OVERWRITE=y
CONFIG_ENV_IS_IN_NAND=y
@@ -65,6 +58,6 @@ CONFIG_MII=y
CONFIG_SYS_NS16550=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_STORAGE=y
+CONFIG_UBIFS_SILENCE_MSG=y
CONFIG_LZMA=y
CONFIG_BZIP2=y
diff --git a/include/configs/nsa310s.h b/include/configs/nsa310s.h
index 027a47b5a3..a538721c45 100644
--- a/include/configs/nsa310s.h
+++ b/include/configs/nsa310s.h
@@ -9,15 +9,53 @@
#ifndef _CONFIG_NSA310S_H
#define _CONFIG_NSA310S_H
+/*
+ * mv-common.h should be defined after CMD configs since it used them
+ * to enable certain macros
+ */
#include "mv-common.h"
-/* default environment variables */
+/* Include the common distro boot environment */
+#ifndef CONFIG_SPL_BUILD
+
+#ifdef CONFIG_SATA
+#define BOOT_TARGET_DEVICES_SATA(func) func(SATA, sata, 0)
+#else
+#define BOOT_TARGET_DEVICES_SATA(func)
+#endif
+
+#ifdef CONFIG_USB_STORAGE
+#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
+#else
+#define BOOT_TARGET_DEVICES_USB(func)
+#endif
+
+#define BOOT_TARGET_DEVICES(func) \
+ BOOT_TARGET_DEVICES_USB(func) \
+ BOOT_TARGET_DEVICES_SATA(func) \
+ func(DHCP, dhcp, na)
+
+#define KERNEL_ADDR_R __stringify(0x80)
+#define FDT_ADDR_R __stringify(0x2c0)
+#define RAMDISK_ADDR_R __stringify(0x0110)
+#define SCRIPT_ADDR_R __stringify(0x20)
+
+#define LOAD_ADDRESS_ENV_SETTINGS \
+ "kernel_addr_r=" KERNEL_ADDR_R "\0" \
+ "fdt_addr_r=" FDT_ADDR_R "\0" \
+ "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \
+ "scriptaddr=" SCRIPT_ADDR_R "\0"
+
+#include
#define CONFIG_EXTRA_ENV_SETTINGS \
- "console=console=ttyS0,115200\0" \
- "kernel=/boot/zImage\0" \
- "fdt=/boot/nsa310s.dtb\0" \
- "bootargs_root=ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs rw\0"
+ LOAD_ADDRESS_ENV_SETTINGS \
+ "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
+ "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
+ "console=ttyS0,115200\0" \
+ BOOTENV
+
+#endif /* CONFIG_SPL_BUILD */
/* Ethernet driver configuration */
#define CONFIG_MVGBE_PORTS {1, 0} /* enable port 0 only */
--
2.30.2
Re: [PATCH] ubifs: Allow to silence debug dumps
Hi Pali,
On Sun, Aug 7, 2022 at 3:54 PM Pali Rohár wrote:
>
> On Sunday 07 August 2022 15:30:33 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Sun, Aug 7, 2022 at 12:27 PM Pali Rohár wrote:
> > >
> > > Debug dump logs are not always required. Add a new config option
> > > UBIFS_SILENCE_DEBUG_DUMP to silence all debug dumps. On powerpc/mpc85xx
> > > when enabled this will decrease size of U-Boot binary by 11 kB.
> >
> > Great patch! I had a hunch that we could cut down the binary size of
> > the Kirkwood boards by doing something about this ubifs debug.c, but
> > was not sure how to do it properly.
>
> Wow, I'm surprised that there are other boards which needs ubifs support
> in u-boot.
Indeed, there are quite a few Kirkwood boards that run OpenWrt on
UBIFS. Also, keeping u-boot binary size under 512K is important for
those boards. IOW, ability to do u-boot upgrade for boxes running
Debian, Arch and OpenWrt distros without changing mtdparts and
installation script.
> Anyway, another option for decreasing u-boot size is to enable LTO
> support or optimize inlining option.
Cool!
Thanks,
Tony
>
> > I rebuilt with this patch for a few Kirkwood boxes (Sheevaplug, Pogo
> > V4, GoFlexHome, Zyxel NSA310S), and each was reduced by 10 KB (with
> > CONFIG_SYS_THUMB_BUILD=y). I also ran a regression test booting with
> > UBIFS on the NSA310S board.
> >
> > Tested-by: Tony Dinh
> >
> > Thanks,
> > Tony
> >
> > >
> > > Signed-off-by: Pali Rohár
> > > ---
> > > fs/ubifs/Kconfig | 8
> > > fs/ubifs/debug.c | 28
> > > 2 files changed, 36 insertions(+)
> > >
> > > diff --git a/fs/ubifs/Kconfig b/fs/ubifs/Kconfig
> > > index 9da35b8a3794..949b28841194 100644
> > > --- a/fs/ubifs/Kconfig
> > > +++ b/fs/ubifs/Kconfig
> > > @@ -4,3 +4,11 @@ config UBIFS_SILENCE_MSG
> > > help
> > > Make the verbose messages from UBIFS stop printing. This leaves
> > > warnings and errors enabled.
> > > +
> > > +config UBIFS_SILENCE_DEBUG_DUMP
> > > + bool "UBIFS silence debug dumps"
> > > + default y if UBIFS_SILENCE_MSG
> > > + default n
> > > + help
> > > + Make the debug dumps from UBIFS stop printing.
> > > + This decreases size of U-Boot binary.
> > > diff --git a/fs/ubifs/debug.c b/fs/ubifs/debug.c
> > > index 2ff8f1a5f9b1..bede7d01cab0 100644
> > > --- a/fs/ubifs/debug.c
> > > +++ b/fs/ubifs/debug.c
> > > @@ -35,6 +35,7 @@
> > > static DEFINE_SPINLOCK(dbg_lock);
> > > #endif
> > >
> > > +#ifndef CONFIG_UBIFS_SILENCE_DEBUG_DUMP
> > > static const char *get_key_fmt(int fmt)
> > > {
> > > switch (fmt) {
> > > @@ -230,6 +231,7 @@ static void dump_ch(const struct ubifs_ch *ch)
> > >(unsigned long long)le64_to_cpu(ch->sqnum));
> > > pr_err("\tlen%u\n", le32_to_cpu(ch->len));
> > > }
> > > +#endif
> > >
> > > void ubifs_dump_inode(struct ubifs_info *c, const struct inode *inode)
> > > {
> > > @@ -303,6 +305,7 @@ void ubifs_dump_inode(struct ubifs_info *c, const
> > > struct inode *inode)
> > >
> > > void ubifs_dump_node(const struct ubifs_info *c, const void *node)
> > > {
> > > +#ifndef CONFIG_UBIFS_SILENCE_DEBUG_DUMP
> > > int i, n;
> > > union ubifs_key key;
> > > const struct ubifs_ch *ch = node;
> > > @@ -546,10 +549,12 @@ void ubifs_dump_node(const struct ubifs_info *c,
> > > const void *node)
> > >(int)ch->node_type);
> > > }
> > > spin_unlock(&dbg_lock);
> > > +#endif
> > > }
> > >
> > > void ubifs_dump_budget_req(const struct ubifs_budget_req *req)
> > > {
> > > +#ifndef CONFIG_UBIFS_SILENCE_DEBUG_DUMP
> > > spin_lock(&dbg_lock);
> > > pr_err("Budgeting request: new_ino %d, dirtied_ino %d\n",
> > >req->new_ino, req->dirtied_ino);
> > > @@ -563,10 +568,12 @@ void ubifs_dump_budget_req(const struct
> > > ubifs_budget_req *req)
> > > pr_err("\tdata_growth %d dd_growth %d\n",
> > >req->data_growth, req->dd_growth);
> > > spin_unlock(&dbg_lock);
> > > +#endif
> &g
Re: [PATCH] ubifs: Allow to silence debug dumps
Hi Pali,
On Sun, Aug 7, 2022 at 12:27 PM Pali Rohár wrote:
>
> Debug dump logs are not always required. Add a new config option
> UBIFS_SILENCE_DEBUG_DUMP to silence all debug dumps. On powerpc/mpc85xx
> when enabled this will decrease size of U-Boot binary by 11 kB.
Great patch! I had a hunch that we could cut down the binary size of
the Kirkwood boards by doing something about this ubifs debug.c, but
was not sure how to do it properly.
I rebuilt with this patch for a few Kirkwood boxes (Sheevaplug, Pogo
V4, GoFlexHome, Zyxel NSA310S), and each was reduced by 10 KB (with
CONFIG_SYS_THUMB_BUILD=y). I also ran a regression test booting with
UBIFS on the NSA310S board.
Tested-by: Tony Dinh
Thanks,
Tony
>
> Signed-off-by: Pali Rohár
> ---
> fs/ubifs/Kconfig | 8
> fs/ubifs/debug.c | 28
> 2 files changed, 36 insertions(+)
>
> diff --git a/fs/ubifs/Kconfig b/fs/ubifs/Kconfig
> index 9da35b8a3794..949b28841194 100644
> --- a/fs/ubifs/Kconfig
> +++ b/fs/ubifs/Kconfig
> @@ -4,3 +4,11 @@ config UBIFS_SILENCE_MSG
> help
> Make the verbose messages from UBIFS stop printing. This leaves
> warnings and errors enabled.
> +
> +config UBIFS_SILENCE_DEBUG_DUMP
> + bool "UBIFS silence debug dumps"
> + default y if UBIFS_SILENCE_MSG
> + default n
> + help
> + Make the debug dumps from UBIFS stop printing.
> + This decreases size of U-Boot binary.
> diff --git a/fs/ubifs/debug.c b/fs/ubifs/debug.c
> index 2ff8f1a5f9b1..bede7d01cab0 100644
> --- a/fs/ubifs/debug.c
> +++ b/fs/ubifs/debug.c
> @@ -35,6 +35,7 @@
> static DEFINE_SPINLOCK(dbg_lock);
> #endif
>
> +#ifndef CONFIG_UBIFS_SILENCE_DEBUG_DUMP
> static const char *get_key_fmt(int fmt)
> {
> switch (fmt) {
> @@ -230,6 +231,7 @@ static void dump_ch(const struct ubifs_ch *ch)
>(unsigned long long)le64_to_cpu(ch->sqnum));
> pr_err("\tlen%u\n", le32_to_cpu(ch->len));
> }
> +#endif
>
> void ubifs_dump_inode(struct ubifs_info *c, const struct inode *inode)
> {
> @@ -303,6 +305,7 @@ void ubifs_dump_inode(struct ubifs_info *c, const struct
> inode *inode)
>
> void ubifs_dump_node(const struct ubifs_info *c, const void *node)
> {
> +#ifndef CONFIG_UBIFS_SILENCE_DEBUG_DUMP
> int i, n;
> union ubifs_key key;
> const struct ubifs_ch *ch = node;
> @@ -546,10 +549,12 @@ void ubifs_dump_node(const struct ubifs_info *c, const
> void *node)
>(int)ch->node_type);
> }
> spin_unlock(&dbg_lock);
> +#endif
> }
>
> void ubifs_dump_budget_req(const struct ubifs_budget_req *req)
> {
> +#ifndef CONFIG_UBIFS_SILENCE_DEBUG_DUMP
> spin_lock(&dbg_lock);
> pr_err("Budgeting request: new_ino %d, dirtied_ino %d\n",
>req->new_ino, req->dirtied_ino);
> @@ -563,10 +568,12 @@ void ubifs_dump_budget_req(const struct
> ubifs_budget_req *req)
> pr_err("\tdata_growth %d dd_growth %d\n",
>req->data_growth, req->dd_growth);
> spin_unlock(&dbg_lock);
> +#endif
> }
>
> void ubifs_dump_lstats(const struct ubifs_lp_stats *lst)
> {
> +#ifndef CONFIG_UBIFS_SILENCE_DEBUG_DUMP
> spin_lock(&dbg_lock);
> pr_err("(pid %d) Lprops statistics: empty_lebs %d, idx_lebs %d\n",
>current->pid, lst->empty_lebs, lst->idx_lebs);
> @@ -575,6 +582,7 @@ void ubifs_dump_lstats(const struct ubifs_lp_stats *lst)
> pr_err("\ttotal_used %lld, total_dark %lld, total_dead %lld\n",
>lst->total_used, lst->total_dark, lst->total_dead);
> spin_unlock(&dbg_lock);
> +#endif
> }
>
> #ifndef __UBOOT__
> @@ -653,6 +661,7 @@ void ubifs_dump_budg(struct ubifs_info *c, const struct
> ubifs_budg_info *bi)
>
> void ubifs_dump_lprop(const struct ubifs_info *c, const struct ubifs_lprops
> *lp)
> {
> +#ifndef CONFIG_UBIFS_SILENCE_DEBUG_DUMP
> int i, spc, dark = 0, dead = 0;
> struct rb_node *rb;
> struct ubifs_bud *bud;
> @@ -740,6 +749,7 @@ void ubifs_dump_lprop(const struct ubifs_info *c, const
> struct ubifs_lprops *lp)
> if (lp->lnum == c->gc_lnum)
> pr_cont(", GC LEB");
> pr_cont(")\n");
> +#endif
> }
>
> void ubifs_dump_lprops(struct ubifs_info *c)
> @@ -766,6 +776,7 @@ void ubifs_dump_lprops(struct ubifs_info *c)
>
> void ubifs_dump_lpt_info(struct ubifs_info *c)
> {
> +#ifndef CONFIG_UBIFS_SILENCE_DEBUG_DUMP
> int i;
&g
Re: [PATCH] arm: mvebu: spl: Always fallback to BootROM boot method
Hi Pali,
Follow up on the topic of slow/fast SPL SPI loading.
common/spl/spl_spi.c
/*
* Load U-Boot image from SPI flash into RAM
* In DM mode: defaults speed and mode will be
* taken from DT when available
*/
flash = spi_flash_probe(sf_bus, sf_cs,
CONFIG_SF_DEFAULT_SPEED,
CONFIG_SF_DEFAULT_MODE);
if (!flash) {
puts("SPI probe failed.\n");
return -ENODEV;
}
So that spi-max-frequency = <5000> in the DTS is not used in the probe.
Thanks,
Tony
On Wed, Aug 3, 2022 at 11:06 PM Tony Dinh wrote:
>
> Hi Pali,
>
> On Wed, Aug 3, 2022 at 3:24 AM Pali Rohár wrote:
> >
> > On Tuesday 02 August 2022 15:13:13 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Tue, Aug 2, 2022 at 3:00 PM Pali Rohár wrote:
> > > >
> > > > Hello! We have tested that A385 BootROM on Turris Omnia board is much
> > > > slower when reading proper U-Boot from SPI NOR than native SPL SPI
> > > > driver.
> > > >
> > > > If you have different test results on A385, could you check SPI speed
> > > > used by U-Boot? I think that CONFIG_SF_DEFAULT_SPEED should define it.
> > > > For Omnia we use CONFIG_SF_DEFAULT_SPEED=4000. Also check value of
> > > > DT property spi-max-frequency. We have: spi-max-frequency = <4000>;
> > >
> > > It seems the spi-max-frequency = <5000> in the DTS took precedence
> > > here?
> >
> > I'm not sure. It is possible that config option has higher priority. Try
> > to set both values to same speed.
>
> That's exactly what has caused the SPL SPI driver to slow down. Once I
> set the configurations for the default and the max to the same speed,
> SPL SPI driver boots instantly (no observable delay).
>
> CONFIG_ENV_SPI_MAX_HZ=5000
> CONFIG_SF_DEFAULT_SPEED=5000
> (and spi-max-frequency = <5000> in the DTS)
>
> It is noticeably faster than BootROM loading the u-boot image, which
> takes an observable fraction of a second.
>
> So somewhere in the SPL SPL driver, the logic needs some improvement.
> Setting default speed and max speed to the same value apparently has
> short-circuit that logic.
>
> Thanks,
> Tony
>
>
>
>
>
> >
> > > #grep CONFIG_SF_DEFAULT_SPEED .config
> > > CONFIG_SF_DEFAULT_SPEED=100
> > >
> > > #grep spi-max-frequency arch/arm/dts/armada-385-synology-ds116.dts
> > > spi-max-frequency = <5000>;
> > >
> > > Thanks,
> > > Tony
> > >
> > >
> > > > On Tuesday 02 August 2022 14:50:32 Tony Dinh wrote:
> > > > > Hi Pali,
> > > > >
> > > > > It works great!
> > > > >
> > > > > An observation: BootROM boot method is a lot faster than SPL SPI
> > > > > driver method on this Armada 385 board. The BootROM took a fraction of
> > > > > a second to load the u-boot image. SPL SPI driver took a few seconds
> > > > > to load. Perhaps the SPI flash speed vs some probing code in SPL SPI
> > > > > driver? I also include the boot log after signature.
> > > > >
> > > > > Tested-by: Tony Dinh
> > > > >
> > > > > Thanks,
> > > > > Tony
> > > > >
> > > > >
> > > > >
> > > > > BootROM - 1.73
> > > > > Booting from SPI flash
> > > > >
> > > > > U-Boot SPL 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 -
> > > > > 14:07:12 -0700)
> > > > > High speed PHY - Version: 2.0
> > > > > Detected Device ID 6820
> > > > > board SerDes lanes topology details:
> > > > > | Lane # | Speed | Type |
> > > > >
> > > > > | 0| 0 | SGMII0 |
> > > > > | 1| 6 | SATA0 |
> > > > > | 4| 5 | USB3 HOST0 |
> > > > > | 5| 5 | USB3 HOST1 |
> > > > >
> > > > > High speed PHY - Ended Successfully
> > > > > mv_ddr: 14.0.0
> > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> > > > > mv_ddr: completed successfully
> > > > > Trying to boot from SPI
> > > > > Invalid bus 0 (err=-19)
> > > > > SPI probe failed.
> > > >
Re: [PATCH] arm: mvebu: spl: Always fallback to BootROM boot method
Hi Pali, On Wed, Aug 3, 2022 at 3:24 AM Pali Rohár wrote: > > On Tuesday 02 August 2022 15:13:13 Tony Dinh wrote: > > Hi Pali, > > > > On Tue, Aug 2, 2022 at 3:00 PM Pali Rohár wrote: > > > > > > Hello! We have tested that A385 BootROM on Turris Omnia board is much > > > slower when reading proper U-Boot from SPI NOR than native SPL SPI > > > driver. > > > > > > If you have different test results on A385, could you check SPI speed > > > used by U-Boot? I think that CONFIG_SF_DEFAULT_SPEED should define it. > > > For Omnia we use CONFIG_SF_DEFAULT_SPEED=4000. Also check value of > > > DT property spi-max-frequency. We have: spi-max-frequency = <4000>; > > > > It seems the spi-max-frequency = <5000> in the DTS took precedence here? > > I'm not sure. It is possible that config option has higher priority. Try > to set both values to same speed. That's exactly what has caused the SPL SPI driver to slow down. Once I set the configurations for the default and the max to the same speed, SPL SPI driver boots instantly (no observable delay). CONFIG_ENV_SPI_MAX_HZ=5000 CONFIG_SF_DEFAULT_SPEED=5000 (and spi-max-frequency = <5000> in the DTS) It is noticeably faster than BootROM loading the u-boot image, which takes an observable fraction of a second. So somewhere in the SPL SPL driver, the logic needs some improvement. Setting default speed and max speed to the same value apparently has short-circuit that logic. Thanks, Tony > > > #grep CONFIG_SF_DEFAULT_SPEED .config > > CONFIG_SF_DEFAULT_SPEED=100 > > > > #grep spi-max-frequency arch/arm/dts/armada-385-synology-ds116.dts > > spi-max-frequency = <5000>; > > > > Thanks, > > Tony > > > > > > > On Tuesday 02 August 2022 14:50:32 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > It works great! > > > > > > > > An observation: BootROM boot method is a lot faster than SPL SPI > > > > driver method on this Armada 385 board. The BootROM took a fraction of > > > > a second to load the u-boot image. SPL SPI driver took a few seconds > > > > to load. Perhaps the SPI flash speed vs some probing code in SPL SPI > > > > driver? I also include the boot log after signature. > > > > > > > > Tested-by: Tony Dinh > > > > > > > > Thanks, > > > > Tony > > > > > > > > > > > > > > > > BootROM - 1.73 > > > > Booting from SPI flash > > > > > > > > U-Boot SPL 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 - 14:07:12 > > > > -0700) > > > > High speed PHY - Version: 2.0 > > > > Detected Device ID 6820 > > > > board SerDes lanes topology details: > > > > | Lane # | Speed | Type | > > > > > > > > | 0| 0 | SGMII0 | > > > > | 1| 6 | SATA0 | > > > > | 4| 5 | USB3 HOST0 | > > > > | 5| 5 | USB3 HOST1 | > > > > > > > > High speed PHY - Ended Successfully > > > > mv_ddr: 14.0.0 > > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > > > mv_ddr: completed successfully > > > > Trying to boot from SPI > > > > Invalid bus 0 (err=-19) > > > > SPI probe failed. > > > > Trying to boot from BOOTROM > > > > Returning to BootROM (return address 0x05c4)... > > > > BootROM: Image checksum verification PASSED > > > > > > > > > > > > U-Boot 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 - 14:07:12 > > > > -0700) > > > > Synology DS116 > > > > > > > > SoC: MV88F6820-A0 at 1866 MHz > > > > DRAM: 1 GiB (933 MHz, 32-bit, ECC not enabled) > > > > Core: 41 devices, 18 uclasses, devicetree: separate > > > > MMC: > > > > Loading Environment from SPIFlash... SF: Detected mx25l6405d with page > > > > size 256 Bytes, erase size 4 KiB, total 8 MiB > > > > OK > > > > Model: Synology DS116 > > > > Board: Synology DS116 > > > > Net: eth0: ethernet@7 > > > > Hit any key to stop autoboot: 0 > > > > > > > > > > > > > > > > > > > > On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár wrote: > > > > > > > > > >
Re: [PATCH 0/5] arm: mvebu: Cleanup u-boot,dm-pre-reloc code
Hi Pali,
I ran 3 tests: UART booting, SPI NOR booting from SPL, and SPI NOR
booting from BootROM (CONFIG_SPL_SPI is not set). All tests work
great!
Synology DS116 (Armada 385).
Tested-by: Tony Dinh
Thanks,
Tony
On Wed, Aug 3, 2022 at 4:01 AM Pali Rohár wrote:
>
> This patch series cleanup u-boot,dm-pre-reloc code in 32-bit mvebu
> device tree files. All repeated code patterns are moved into the new
> mvebu-u-boot.dtsi file which is automatically included by U-Boot build
> process into all mvebu boards. In file mvebu-u-boot.dtsi is also enabled
> u-boot,dm-pre-reloc for SPI node when SPL is compiled with SPI driver
> for loading proper U-Boot. This avoids manually defining
> &spi0 { u-boot,dm-pre-reloc; };
> in every armada soc which store U-Boot in SPI NOR.
>
> I tested this patch series only on Armada 385 Turris Omnia board (both
> UART and SPI-NOR booting). Please test it on other Armada boards.
>
> CI tests were running at:
> https://github.com/u-boot/u-boot/pull/203
> But some x86 test failed, which must be irrelevant as this patch series
> did not touch code outside of arch/arm/.
>
> Pali Rohár (5):
> arm: mvebu: a7040/a8040/cn9130: Add spi0 dts reference
> arm: mvebu: Introduce mvebu-u-boot.dtsi for 32-bit Armada SoCs
> arm: mvebu: Remove redundant u-boot,dm-pre-reloc from all 32-bit
> Armada SoCs
> arm: mvebu: armada-xp-theadorable.dts: Move u-boot,dm-pre-reloc to
> -u-boot.dtsi
> arm: mvebu: armada-38x-controlcenterdc.dts: Move u-boot,dm-pre-reloc
> to -u-boot.dtsi
>
> arch/arm/dts/armada-370-xp.dtsi | 1 -
> arch/arm/dts/armada-375-db.dts| 3 ---
> arch/arm/dts/armada-375.dtsi | 2 --
> arch/arm/dts/armada-385-atl-x530-u-boot.dtsi | 14 ++-
> arch/arm/dts/armada-385-db-88f6820-amc.dts| 3 ---
> .../dts/armada-385-turris-omnia-u-boot.dtsi | 8 +-
> arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 2 ++
> arch/arm/dts/armada-388-gp.dts| 3 ---
> arch/arm/dts/armada-388-helios4-u-boot.dtsi | 2 ++
> .../armada-38x-controlcenterdc-u-boot.dtsi| 25 +++
> arch/arm/dts/armada-38x-controlcenterdc.dts | 20 ---
> .../arm/dts/armada-38x-solidrun-microsom.dtsi | 1 -
> arch/arm/dts/armada-38x.dtsi | 2 --
> arch/arm/dts/armada-7040.dtsi | 3 +++
> arch/arm/dts/armada-8040.dtsi | 3 +++
> .../dts/armada-xp-crs305-1g-4s-u-boot.dtsi| 13 --
> arch/arm/dts/armada-xp-crs305-1g-4s.dtsi | 1 -
> .../dts/armada-xp-crs326-24g-2s-u-boot.dtsi | 13 --
> arch/arm/dts/armada-xp-crs326-24g-2s.dtsi | 1 -
> .../armada-xp-crs328-4c-20s-4s-u-boot.dtsi| 13 --
> arch/arm/dts/armada-xp-crs328-4c-20s-4s.dtsi | 1 -
> .../dts/armada-xp-db-xc3-24g4xg-u-boot.dtsi | 12 +
> arch/arm/dts/armada-xp-gp-u-boot.dtsi | 19 --
> arch/arm/dts/armada-xp-maxbcm.dts | 1 -
> .../dts/armada-xp-synology-ds414-u-boot.dtsi | 9 ---
> arch/arm/dts/armada-xp-synology-ds414.dts | 1 -
> .../arm/dts/armada-xp-theadorable-u-boot.dtsi | 5
> arch/arm/dts/armada-xp-theadorable.dts| 4 ---
> arch/arm/dts/armada-xp.dtsi | 1 -
> arch/arm/dts/cn9130.dtsi | 3 +++
> arch/arm/dts/mvebu-u-boot.dtsi| 24 ++
> 31 files changed, 71 insertions(+), 142 deletions(-)
> create mode 100644 arch/arm/dts/armada-38x-controlcenterdc-u-boot.dtsi
> delete mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi
> delete mode 100644 arch/arm/dts/armada-xp-crs326-24g-2s-u-boot.dtsi
> delete mode 100644 arch/arm/dts/armada-xp-crs328-4c-20s-4s-u-boot.dtsi
> delete mode 100644 arch/arm/dts/armada-xp-gp-u-boot.dtsi
> delete mode 100644 arch/arm/dts/armada-xp-synology-ds414-u-boot.dtsi
> create mode 100644 arch/arm/dts/armada-xp-theadorable-u-boot.dtsi
> create mode 100644 arch/arm/dts/mvebu-u-boot.dtsi
>
> --
> 2.20.1
>
Re: [PATCH] arm: mvebu: spl: Always fallback to BootROM boot method
Hi Pali,
On Tue, Aug 2, 2022 at 3:00 PM Pali Rohár wrote:
>
> Hello! We have tested that A385 BootROM on Turris Omnia board is much
> slower when reading proper U-Boot from SPI NOR than native SPL SPI
> driver.
>
> If you have different test results on A385, could you check SPI speed
> used by U-Boot? I think that CONFIG_SF_DEFAULT_SPEED should define it.
> For Omnia we use CONFIG_SF_DEFAULT_SPEED=4000. Also check value of
> DT property spi-max-frequency. We have: spi-max-frequency = <4000>;
It seems the spi-max-frequency = <5000> in the DTS took precedence here?
#grep CONFIG_SF_DEFAULT_SPEED .config
CONFIG_SF_DEFAULT_SPEED=100
#grep spi-max-frequency arch/arm/dts/armada-385-synology-ds116.dts
spi-max-frequency = <5000>;
Thanks,
Tony
> On Tuesday 02 August 2022 14:50:32 Tony Dinh wrote:
> > Hi Pali,
> >
> > It works great!
> >
> > An observation: BootROM boot method is a lot faster than SPL SPI
> > driver method on this Armada 385 board. The BootROM took a fraction of
> > a second to load the u-boot image. SPL SPI driver took a few seconds
> > to load. Perhaps the SPI flash speed vs some probing code in SPL SPI
> > driver? I also include the boot log after signature.
> >
> > Tested-by: Tony Dinh
> >
> > Thanks,
> > Tony
> >
> >
> >
> > BootROM - 1.73
> > Booting from SPI flash
> >
> > U-Boot SPL 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 - 14:07:12
> > -0700)
> > High speed PHY - Version: 2.0
> > Detected Device ID 6820
> > board SerDes lanes topology details:
> > | Lane # | Speed | Type |
> >
> > | 0| 0 | SGMII0 |
> > | 1| 6 | SATA0 |
> > | 4| 5 | USB3 HOST0 |
> > | 5| 5 | USB3 HOST1 |
> >
> > High speed PHY - Ended Successfully
> > mv_ddr: 14.0.0
> > DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> > mv_ddr: completed successfully
> > Trying to boot from SPI
> > Invalid bus 0 (err=-19)
> > SPI probe failed.
> > Trying to boot from BOOTROM
> > Returning to BootROM (return address 0x05c4)...
> > BootROM: Image checksum verification PASSED
> >
> >
> > U-Boot 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 - 14:07:12 -0700)
> > Synology DS116
> >
> > SoC: MV88F6820-A0 at 1866 MHz
> > DRAM: 1 GiB (933 MHz, 32-bit, ECC not enabled)
> > Core: 41 devices, 18 uclasses, devicetree: separate
> > MMC:
> > Loading Environment from SPIFlash... SF: Detected mx25l6405d with page
> > size 256 Bytes, erase size 4 KiB, total 8 MiB
> > OK
> > Model: Synology DS116
> > Board: Synology DS116
> > Net: eth0: ethernet@7
> > Hit any key to stop autoboot: 0
> >
> >
> >
> >
> > On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár wrote:
> > >
> > > BootROM boot method should always work so always add it as fallback method
> > > to spl_boot_list. In case U-Boot SPI driver fails it is better to try
> > > using
> > > BootROM than hanging as by default only one boot method is specified.
> > >
> > > Signed-off-by: Pali Rohár
> > > ---
> > > arch/arm/mach-mvebu/spl.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> > > index 13c99913c380..bfcba2e73bab 100644
> > > --- a/arch/arm/mach-mvebu/spl.c
> > > +++ b/arch/arm/mach-mvebu/spl.c
> > > @@ -271,6 +271,13 @@ u32 spl_boot_device(void)
> > > }
> > > }
> > >
> > > +void board_boot_order(u32 *spl_boot_list)
> > > +{
> > > + spl_boot_list[0] = spl_boot_device();
> > > + if (spl_boot_list[0] != BOOT_DEVICE_BOOTROM)
> > > + spl_boot_list[1] = BOOT_DEVICE_BOOTROM;
> > > +}
> > > +
> > > #else
> > >
> > > u32 spl_boot_device(void)
> > > --
> > > 2.20.1
> > >
Re: [PATCH] arm: mvebu: spl: Always fallback to BootROM boot method
Hi Pali,
It works great!
An observation: BootROM boot method is a lot faster than SPL SPI
driver method on this Armada 385 board. The BootROM took a fraction of
a second to load the u-boot image. SPL SPI driver took a few seconds
to load. Perhaps the SPI flash speed vs some probing code in SPL SPI
driver? I also include the boot log after signature.
Tested-by: Tony Dinh
Thanks,
Tony
BootROM - 1.73
Booting from SPI flash
U-Boot SPL 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 - 14:07:12 -0700)
High speed PHY - Version: 2.0
Detected Device ID 6820
board SerDes lanes topology details:
| Lane # | Speed | Type |
| 0| 0 | SGMII0 |
| 1| 6 | SATA0 |
| 4| 5 | USB3 HOST0 |
| 5| 5 | USB3 HOST1 |
High speed PHY - Ended Successfully
mv_ddr: 14.0.0
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
Trying to boot from SPI
Invalid bus 0 (err=-19)
SPI probe failed.
Trying to boot from BOOTROM
Returning to BootROM (return address 0x05c4)...
BootROM: Image checksum verification PASSED
U-Boot 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 - 14:07:12 -0700)
Synology DS116
SoC: MV88F6820-A0 at 1866 MHz
DRAM: 1 GiB (933 MHz, 32-bit, ECC not enabled)
Core: 41 devices, 18 uclasses, devicetree: separate
MMC:
Loading Environment from SPIFlash... SF: Detected mx25l6405d with page
size 256 Bytes, erase size 4 KiB, total 8 MiB
OK
Model: Synology DS116
Board: Synology DS116
Net: eth0: ethernet@7
Hit any key to stop autoboot: 0
On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár wrote:
>
> BootROM boot method should always work so always add it as fallback method
> to spl_boot_list. In case U-Boot SPI driver fails it is better to try using
> BootROM than hanging as by default only one boot method is specified.
>
> Signed-off-by: Pali Rohár
> ---
> arch/arm/mach-mvebu/spl.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> index 13c99913c380..bfcba2e73bab 100644
> --- a/arch/arm/mach-mvebu/spl.c
> +++ b/arch/arm/mach-mvebu/spl.c
> @@ -271,6 +271,13 @@ u32 spl_boot_device(void)
> }
> }
>
> +void board_boot_order(u32 *spl_boot_list)
> +{
> + spl_boot_list[0] = spl_boot_device();
> + if (spl_boot_list[0] != BOOT_DEVICE_BOOTROM)
> + spl_boot_list[1] = BOOT_DEVICE_BOOTROM;
> +}
> +
> #else
>
> u32 spl_boot_device(void)
> --
> 2.20.1
>
Re: [MVEBU] SPI flash offset was depecrated?
Hi Pali,
Flashed to SPI and booted successfully! With CONFIG_SPL_SPI=y so SPL
loads u-boot payload.
My observation: dm-preloc is also required using SPL SPI driver method:
&spi0 {
u-boot,dm-pre-reloc;
};
Perhaps it should be implied in Kconfig with a DM_xxx symbol if possible.
Thanks,
Tony
On Sat, Jul 30, 2022 at 4:04 PM Tony Dinh wrote:
>
> Hi Pali,
>
> "flash u-boot.bin or spl.bin separately"
>
> That's what we used to do many years ago! glad that we have a single
> flashable image now, much more robust. Thanks for a clear and detailed
> explanation!
>
> Tony
>
> On Sat, Jul 30, 2022 at 3:41 PM Pali Rohár wrote:
> >
> > On Saturday 30 July 2022 15:13:05 Tony Dinh wrote:
> > > Hi Stefan and Pali,
> > >
> > > Sorry the question might be a bit trivial, but I could not find it in
> > > the source tree. It's been a long time and I'm not up to date on this
> > > subject. I recall a long time ago we needed to specify a SPI flash
> > > offset for the u-boot image so SPL would know where to load it from.
> >
> > Hello! Now upstream U-Boot build process does not need to know offset
> > where the proper U-Boot starts in SPI flash. SPL image determinate it at
> > runtime (by looking into kwbimage header stored in SPI flash) and load
> > proper U-Boot correctly.
> >
> > > I vaguely remember something about "return to BootROM and let the
> > > BootROM load the u-boot image"? Is this applicable only when we kwboot
> > > the u-boot-spl.kwb image, or also applicable to the u-boot payload on
> > > SPI flash?
> >
> > Now upstream SPL can load proper U-Boot from SPI flash directly (if SPI
> > flash driver is compiled into SPL) or it can "return to BootROM" and let
> > BootROM to load proper U-Boot into RAM.
> >
> > This is configurable by defconfig options at compile time. We have
> > tested that both options work fine. Using BootROM for loading U-Boot
> > from SPI flash is slower than using dedicated SPL drivers (probably
> > because BootROM read SPI at lower speed). But SPI flash drivers increase
> > SPL binary (usage of BootROM does not). So you can choose which option
> > you want -- either smaller SPL binary or faster U-Boot loading and
> > booting. To disable SPI flash drivers in SPL, just disable option
> > CONFIG_SPL_SPI.
> >
> > UART booting requires BootROM for loading proper U-Boot. But now
> > upstream U-Boot generates universal u-boot-spl.kwb image which can be
> > either flashed into SPI flash or booted via kwboot tool.
> >
> > You should _always_ flash u-boot-spl.kwb image into SPI flash memory. It
> > is combined image of SPL and proper U-Boot with Marvell kwbimage header
> > (required by BootROM). So never flash u-boot.bin or spl.bin separately.
> >
> > > I saw Stefan flashing instruction in board/Marvell/db-88f6820-gp/README
> > >
> > > Update from original Marvell U-Boot to mainline U-Boot:
> > > ---
> > > The resulting image including the SPL binary with the full DDR setup
> > > is "u-boot-spl.kwb".
> > > To update the SPI NOR flash, please use the following command:
> > > => sf probe; tftpboot 200 db-88f6820-gp/u-boot-spl.kwb;\
> > > sf update 200 0 6
> > > ...
> > >
> > > But building this board I got 642K u-boot-spl.kwb. So perhaps the
> > > instructions above are out of date, or 6 meant to be just an
> > > example to be adjusted to the real image size?
> >
> > 6 should be there just "example" and you should replace it by real
> > image size.
> >
> > > Could you point me in the right direction, ie. which Kconfig option
> > > deals with this at the moment, or is it automatically set when we
> > > build MVEBU -boot-spl.kwb?
> > >
> > > Thanks,
> > > Tony
> >
> > Default Kconfig options for u-boot-spl.kwb should produce flashable
> > SPI NOR image. It is option CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI.
Re: [MVEBU] SPI flash offset was depecrated?
Hi Pali, "flash u-boot.bin or spl.bin separately" That's what we used to do many years ago! glad that we have a single flashable image now, much more robust. Thanks for a clear and detailed explanation! Tony On Sat, Jul 30, 2022 at 3:41 PM Pali Rohár wrote: > > On Saturday 30 July 2022 15:13:05 Tony Dinh wrote: > > Hi Stefan and Pali, > > > > Sorry the question might be a bit trivial, but I could not find it in > > the source tree. It's been a long time and I'm not up to date on this > > subject. I recall a long time ago we needed to specify a SPI flash > > offset for the u-boot image so SPL would know where to load it from. > > Hello! Now upstream U-Boot build process does not need to know offset > where the proper U-Boot starts in SPI flash. SPL image determinate it at > runtime (by looking into kwbimage header stored in SPI flash) and load > proper U-Boot correctly. > > > I vaguely remember something about "return to BootROM and let the > > BootROM load the u-boot image"? Is this applicable only when we kwboot > > the u-boot-spl.kwb image, or also applicable to the u-boot payload on > > SPI flash? > > Now upstream SPL can load proper U-Boot from SPI flash directly (if SPI > flash driver is compiled into SPL) or it can "return to BootROM" and let > BootROM to load proper U-Boot into RAM. > > This is configurable by defconfig options at compile time. We have > tested that both options work fine. Using BootROM for loading U-Boot > from SPI flash is slower than using dedicated SPL drivers (probably > because BootROM read SPI at lower speed). But SPI flash drivers increase > SPL binary (usage of BootROM does not). So you can choose which option > you want -- either smaller SPL binary or faster U-Boot loading and > booting. To disable SPI flash drivers in SPL, just disable option > CONFIG_SPL_SPI. > > UART booting requires BootROM for loading proper U-Boot. But now > upstream U-Boot generates universal u-boot-spl.kwb image which can be > either flashed into SPI flash or booted via kwboot tool. > > You should _always_ flash u-boot-spl.kwb image into SPI flash memory. It > is combined image of SPL and proper U-Boot with Marvell kwbimage header > (required by BootROM). So never flash u-boot.bin or spl.bin separately. > > > I saw Stefan flashing instruction in board/Marvell/db-88f6820-gp/README > > > > Update from original Marvell U-Boot to mainline U-Boot: > > --- > > The resulting image including the SPL binary with the full DDR setup > > is "u-boot-spl.kwb". > > To update the SPI NOR flash, please use the following command: > > => sf probe; tftpboot 200 db-88f6820-gp/u-boot-spl.kwb;\ > > sf update 200 0 6 > > ... > > > > But building this board I got 642K u-boot-spl.kwb. So perhaps the > > instructions above are out of date, or 6 meant to be just an > > example to be adjusted to the real image size? > > 6 should be there just "example" and you should replace it by real > image size. > > > Could you point me in the right direction, ie. which Kconfig option > > deals with this at the moment, or is it automatically set when we > > build MVEBU -boot-spl.kwb? > > > > Thanks, > > Tony > > Default Kconfig options for u-boot-spl.kwb should produce flashable > SPI NOR image. It is option CONFIG_MVEBU_SPL_BOOT_DEVICE_SPI.
[MVEBU] SPI flash offset was depecrated?
Hi Stefan and Pali, Sorry the question might be a bit trivial, but I could not find it in the source tree. It's been a long time and I'm not up to date on this subject. I recall a long time ago we needed to specify a SPI flash offset for the u-boot image so SPL would know where to load it from. I vaguely remember something about "return to BootROM and let the BootROM load the u-boot image"? Is this applicable only when we kwboot the u-boot-spl.kwb image, or also applicable to the u-boot payload on SPI flash? I saw Stefan flashing instruction in board/Marvell/db-88f6820-gp/README Update from original Marvell U-Boot to mainline U-Boot: --- The resulting image including the SPL binary with the full DDR setup is "u-boot-spl.kwb". To update the SPI NOR flash, please use the following command: => sf probe; tftpboot 200 db-88f6820-gp/u-boot-spl.kwb;\ sf update 200 0 6 ... But building this board I got 642K u-boot-spl.kwb. So perhaps the instructions above are out of date, or 6 meant to be just an example to be adjusted to the real image size? Could you point me in the right direction, ie. which Kconfig option deals with this at the moment, or is it automatically set when we build MVEBU -boot-spl.kwb? Thanks, Tony
