| Message ID | 20230201011116.17699-1-mibodhi@gmail.com |
|---|---|
| State | Superseded |
| Delegated to: | Stefan Roese |
| Headers | show |
| Series | arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards | expand |
(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 <mibodhi@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de> 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-sjg@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 0000000000..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 <mibodhi@gmail.com> > + */ > +&uart0 { > + u-boot,dm-pre-reloc; > +}; Viele Grüße, Stefan Roese
Thanks Stefan! Tony On Tue, Jan 31, 2023 at 10:30 PM Stefan Roese <sr@denx.de> 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 <mibodhi@gmail.com> > > Reviewed-by: Stefan Roese <sr@denx.de> > > 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-sjg@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 0000000000..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 <mibodhi@gmail.com> > > + */ > > +&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: sr@denx.de
Hi Tony, Am 2023-02-01 02:11, schrieb Tony Dinh: > 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. 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? > > Signed-off-by: Tony Dinh <mibodhi@gmail.com> > --- > > 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 <boardname>-u-boot.dtsi is included automatically. -michael
On Wednesday 01 February 2023 08:53:55 Michael Walle wrote: > Hi Tony, > > Am 2023-02-01 02:11, schrieb Tony Dinh: > > 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). > 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. > > > > Signed-off-by: Tony Dinh <mibodhi@gmail.com> > > --- > > > > 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 <boardname>-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/
>> > 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 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. >> > >> > Signed-off-by: Tony Dinh <mibodhi@gmail.com> >> > --- >> > >> > 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 <boardname>-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
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. > 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. > > > > > > > > > Signed-off-by: Tony Dinh <mibodhi@gmail.com> > > > > --- > > > > > > > > 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 <boardname>-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 >
Hi all, On Wed, Feb 1, 2023 at 11:05 AM Pali Rohár <pali@kernel.org> 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 <mibodhi@gmail.com> > > > > > --- > > > > > > > > > > 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 <boardname>-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 > >
Added Simon to the discussion. On Wed, Feb 1, 2023 at 1:13 PM Tony Dinh <mibodhi@gmail.com> wrote: > > Hi all, > > On Wed, Feb 1, 2023 at 11:05 AM Pali Rohár <pali@kernel.org> 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 <mibodhi@gmail.com> > > > > > > --- > > > > > > > > > > > > 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 <boardname>-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 > > >
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 <pali@kernel.org> 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.
Hi all, On Thu, Feb 2, 2023 at 10:04 AM Pali Rohár <pali@kernel.org> 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 <pali@kernel.org> 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@5a090000 { 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
Hi all, On Thu, Feb 2, 2023 at 3:59 PM Tony Dinh <mibodhi@gmail.com> wrote: > > Hi all, > > On Thu, Feb 2, 2023 at 10:04 AM Pali Rohár <pali@kernel.org> 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 <pali@kernel.org> 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@5a090000 { > 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? Well, after giving it some thought I think my reasoning is not sound. There must be a bug somewhere that the Pogo V4 triggers (the board that has a silent console, and then freezes, when dm-pre-reloc is not used for uart0). Because, even if the serial driver is not bound to the uclass, it should boot with the silent console regardless? and after relocation, u-boot should bind the serial driver, and we'd just lose the banner part? Confusedly yours, Tony
Hi Stefan, On Thu, Feb 2, 2023 at 8:28 PM Tony Dinh <mibodhi@gmail.com> wrote: > > Hi all, > > On Thu, Feb 2, 2023 at 3:59 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > Hi all, > > > > On Thu, Feb 2, 2023 at 10:04 AM Pali Rohár <pali@kernel.org> 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 <pali@kernel.org> 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@5a090000 { > > 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? > > Well, after giving it some thought I think my reasoning is not sound. > There must be a bug somewhere that the Pogo V4 triggers (the board > that has a silent console, and then freezes, when dm-pre-reloc is not > used for uart0). > > Because, even if the serial driver is not bound to the uclass, it > should boot with the silent console regardless? and after relocation, > u-boot should bind the serial driver, and we'd just lose the banner > part? > I'm withdrawing this patch :) I've run the kwboot test on another Kirkwood board (NSA310S) without the u-boot,dm-pre-reloc tag, and it booted flawlessly! In fact, I could not cause it to hang like the Pogo V4. U-boot banner and everything was output as it normally would be. So the unsolved problem is specific to the Pogo V4, and the u-boot,dm-pre-reloc tag just happened to fix it. I'll run with DEBUG_UART to see if I can see a bit more clearly. The documentation for DM serial in doc/develop/driver-model/serial-howto.rst is probably somewhat obsolete. At least it is not applicable to some Kirkwood boards. All the best, Tony
On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot md command it is possible to dump it over console. Or via ext4write command store it so ext4 fs on sd card / sata disk.
Hi Pali, On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > md command it is possible to dump it over console. Or via ext4write > command store it so ext4 fs on sd card / sata disk. Thanks for the info. It will be a while before I can get back to this BootROM 1.1 vs 1.2 topic. All the best, Tony
Hi Stefan, On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > Hi Pali, > > On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > > > On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > > > BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > md command it is possible to dump it over console. Or via ext4write > > command store it so ext4 fs on sd card / sata disk. > > Thanks for the info. It will be a while before I can get back to this > BootROM 1.1 vs 1.2 topic. > I have run some more tests, and am quite positive that if the uart0 node exists in the DTS, it must be tagged with dm,pre-reloc. That is consistent with the serial documentation in doc/develop/driver-model/serial-howto.rst. The issue is whether the uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag must also be used. To prove my theory, I've modified the Pogo V4 DTS to look exactly like the NSA310S, as far as uart0 is concerned. The NSA310S does not even have a uart0 node! and DM_SERIAL boots fine with this box. With the patch below, the Pogo V4 can be kwboot and run normally. No dm-pre-reloc tag is needed. diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts b/arch/arm/dts/kirkwood-pogoplug-series-4.dts index 5aa4669ae2..227d5ff802 100644 --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts @@ -24,7 +24,8 @@ }; chosen { - stdout-path = "uart0:115200n8"; + bootargs = "console=ttyS0,115200"; + stdout-path = &uart0; }; gpio_keys { @@ -97,10 +98,6 @@ }; }; -&uart0 { - status = "okay"; -}; - /* * This PCIE controller has a USB 3.0 XHCI controller at 1,0 */ Also, note that just enabling DEBUG_UART would always make the board frozen when u-boot starts. So this was another factor why it took me so long to figure this out :) I've just restored everything and removed the uart0 node from the Pogo V4 DTS like above and it is working. But of course, we don't want to change the Pogo V4 DTS, so I will submit another patch just for the Pogo V4 to add -u-boot.dtsi for this box to enable the dm-pre-reloc tag for uart0. Thanks, Tony
Hi Tony, On 2/9/23 04:17, Tony Dinh wrote: > Hi Stefan, > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: >> >> Hi Pali, >> >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: >>> >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. >>> >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot >>> md command it is possible to dump it over console. Or via ext4write >>> command store it so ext4 fs on sd card / sata disk. >> >> Thanks for the info. It will be a while before I can get back to this >> BootROM 1.1 vs 1.2 topic. >> > > I have run some more tests, and am quite positive that if the uart0 > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > consistent with the serial documentation in > doc/develop/driver-model/serial-howto.rst. The issue is whether the > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > must also be used. > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > have a uart0 node! and DM_SERIAL boots fine with this box. With the > patch below, the Pogo V4 can be kwboot and run normally. No > dm-pre-reloc tag is needed. > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > index 5aa4669ae2..227d5ff802 100644 > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > @@ -24,7 +24,8 @@ > }; > > chosen { > - stdout-path = "uart0:115200n8"; > + bootargs = "console=ttyS0,115200"; > + stdout-path = &uart0; > }; > > gpio_keys { > @@ -97,10 +98,6 @@ > }; > }; > > -&uart0 { > - status = "okay"; > -}; > - > /* > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > */ FWIU, you are hitting a bug in the early serial console code, perhaps in serial_check_stdout()? Could you please check if Pogo V4 boots with CONFIG_REQUIRE_SERIAL_CONSOLE unset? > Also, note that just enabling DEBUG_UART would always make the board > frozen when u-boot starts. This should not be the case of course. Are you sure you've correctly configured the DEBUG UART? > So this was another factor why it took me > so long to figure this out :) I've just restored everything and > removed the uart0 node from the Pogo V4 DTS like above and it is > working. > > But of course, we don't want to change the Pogo V4 DTS, so I will > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > box to enable the dm-pre-reloc tag for uart0. Understood. Thanks, Stefan
Hi Stefan, On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > Hi Tony, > > On 2/9/23 04:17, Tony Dinh wrote: > > Hi Stefan, > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > >> > >> Hi Pali, > >> > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > >>> > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > >>> > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > >>> md command it is possible to dump it over console. Or via ext4write > >>> command store it so ext4 fs on sd card / sata disk. > >> > >> Thanks for the info. It will be a while before I can get back to this > >> BootROM 1.1 vs 1.2 topic. > >> > > > > I have run some more tests, and am quite positive that if the uart0 > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > consistent with the serial documentation in > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > must also be used. > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > patch below, the Pogo V4 can be kwboot and run normally. No > > dm-pre-reloc tag is needed. > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > index 5aa4669ae2..227d5ff802 100644 > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > @@ -24,7 +24,8 @@ > > }; > > > > chosen { > > - stdout-path = "uart0:115200n8"; > > + bootargs = "console=ttyS0,115200"; > > + stdout-path = &uart0; > > }; > > > > gpio_keys { > > @@ -97,10 +98,6 @@ > > }; > > }; > > > > -&uart0 { > > - status = "okay"; > > -}; > > - > > /* > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > */ > > FWIU, you are hitting a bug in the early serial console code, perhaps > in serial_check_stdout()? Quite possible. But I recall trying the same stdout path as the NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not the reason. Perhaps the bug is in another part of the function. > > Could you please check if Pogo V4 boots with > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted normally with kwboot, all serial input/outputs are OK. > > Also, note that just enabling DEBUG_UART would always make the board > > frozen when u-boot starts. > > This should not be the case of course. Are you sure you've correctly > configured the DEBUG UART? I think I did that correctly (we've used that to debug the orion_timer issue previously). Here is how I've configured it: +CONFIG_DEBUG_UART_BASE=0xf1012000 +CONFIG_DEBUG_UART_CLOCK=250000000 +CONFIG_DEBUG_UART=y > > So this was another factor why it took me > > so long to figure this out :) I've just restored everything and > > removed the uart0 node from the Pogo V4 DTS like above and it is > > working. > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > box to enable the dm-pre-reloc tag for uart0. > > Understood. Thanks, Tony > > Thanks, > Stefan
On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > Hi Stefan, > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > > > Hi Tony, > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > Hi Stefan, > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > >> > > >> Hi Pali, > > >> > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > >>> > > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > >>> > > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > >>> md command it is possible to dump it over console. Or via ext4write > > >>> command store it so ext4 fs on sd card / sata disk. > > >> > > >> Thanks for the info. It will be a while before I can get back to this > > >> BootROM 1.1 vs 1.2 topic. > > >> > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > consistent with the serial documentation in > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > must also be used. > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > dm-pre-reloc tag is needed. > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > index 5aa4669ae2..227d5ff802 100644 > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > @@ -24,7 +24,8 @@ > > > }; > > > > > > chosen { > > > - stdout-path = "uart0:115200n8"; > > > + bootargs = "console=ttyS0,115200"; > > > + stdout-path = &uart0; > > > }; > > > > > > gpio_keys { > > > @@ -97,10 +98,6 @@ > > > }; > > > }; > > > > > > -&uart0 { > > > - status = "okay"; > > > -}; > > > - > > > /* > > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > > */ > > > > FWIU, you are hitting a bug in the early serial console code, perhaps > > in serial_check_stdout()? > > Quite possible. But I recall trying the same stdout path as the > NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not > the reason. Perhaps the bug is in another part of the function. > > > > > Could you please check if Pogo V4 boots with > > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > > > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the > Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted > normally with kwboot, all serial input/outputs are OK. > > > > Also, note that just enabling DEBUG_UART would always make the board > > > frozen when u-boot starts. > > > > This should not be the case of course. Are you sure you've correctly > > configured the DEBUG UART? > > I think I did that correctly (we've used that to debug the orion_timer > issue previously). Here is how I've configured it: > > +CONFIG_DEBUG_UART_BASE=0xf1012000 > +CONFIG_DEBUG_UART_CLOCK=250000000 > +CONFIG_DEBUG_UART=y Maybe you hit same issue in mach-kirkwood as me in the past for mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base register address (0xf1012000) when U-Boot was still using the _old_ base register address (0xd0012000). I fixed it by moving code which changes base register address from arch_cpu_init() function to arch_very_early_init() function in commit: https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 > > > So this was another factor why it took me > > > so long to figure this out :) I've just restored everything and > > > removed the uart0 node from the Pogo V4 DTS like above and it is > > > working. > > > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > > box to enable the dm-pre-reloc tag for uart0. > > > > Understood. > > Thanks, > Tony > > > > > Thanks, > > Stefan
Hi Pali, On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár <pali@kernel.org> wrote: > > On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > > Hi Stefan, > > > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > > > > > Hi Tony, > > > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > > Hi Stefan, > > > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > >> > > > >> Hi Pali, > > > >> > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > > >>> > > > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > > >>> > > > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > > >>> md command it is possible to dump it over console. Or via ext4write > > > >>> command store it so ext4 fs on sd card / sata disk. > > > >> > > > >> Thanks for the info. It will be a while before I can get back to this > > > >> BootROM 1.1 vs 1.2 topic. > > > >> > > > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > > consistent with the serial documentation in > > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > > must also be used. > > > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > > dm-pre-reloc tag is needed. > > > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > index 5aa4669ae2..227d5ff802 100644 > > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > @@ -24,7 +24,8 @@ > > > > }; > > > > > > > > chosen { > > > > - stdout-path = "uart0:115200n8"; > > > > + bootargs = "console=ttyS0,115200"; > > > > + stdout-path = &uart0; > > > > }; > > > > > > > > gpio_keys { > > > > @@ -97,10 +98,6 @@ > > > > }; > > > > }; > > > > > > > > -&uart0 { > > > > - status = "okay"; > > > > -}; > > > > - > > > > /* > > > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > > > */ > > > > > > FWIU, you are hitting a bug in the early serial console code, perhaps > > > in serial_check_stdout()? > > > > Quite possible. But I recall trying the same stdout path as the > > NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not > > the reason. Perhaps the bug is in another part of the function. > > > > > > > > Could you please check if Pogo V4 boots with > > > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > > > > > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the > > Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted > > normally with kwboot, all serial input/outputs are OK. > > > > > > Also, note that just enabling DEBUG_UART would always make the board > > > > frozen when u-boot starts. > > > > > > This should not be the case of course. Are you sure you've correctly > > > configured the DEBUG UART? > > > > I think I did that correctly (we've used that to debug the orion_timer > > issue previously). Here is how I've configured it: > > > > +CONFIG_DEBUG_UART_BASE=0xf1012000 > > +CONFIG_DEBUG_UART_CLOCK=250000000 > > +CONFIG_DEBUG_UART=y > > Maybe you hit same issue in mach-kirkwood as me in the past for > mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base > register address (0xf1012000) when U-Boot was still using the _old_ base > register address (0xd0012000). > > I fixed it by moving code which changes base register address from > arch_cpu_init() function to arch_very_early_init() function in commit: > https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 Thanks for the info! Looking at that patch, I think I'm out of my depth :) For now I will fix this Pogo V4 with the -u-boot.dtsi, so as not to mess up anybody who might try UART booting with kwboot. Thanks, Tony > > > > So this was another factor why it took me > > > > so long to figure this out :) I've just restored everything and > > > > removed the uart0 node from the Pogo V4 DTS like above and it is > > > > working. > > > > > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > > > box to enable the dm-pre-reloc tag for uart0. > > > > > > Understood. > > > > Thanks, > > Tony > > > > > > > > Thanks, > > > Stefan
Hi Tony, Hi Pali, On 2/10/23 02:37, Tony Dinh wrote: <snip> >>>> Could you please check if Pogo V4 boots with >>>> CONFIG_REQUIRE_SERIAL_CONSOLE unset? >>>> >>> Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the >>> Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted >>> normally with kwboot, all serial input/outputs are OK. >>> >>>>> Also, note that just enabling DEBUG_UART would always make the board >>>>> frozen when u-boot starts. >>>> >>>> This should not be the case of course. Are you sure you've correctly >>>> configured the DEBUG UART? >>> >>> I think I did that correctly (we've used that to debug the orion_timer >>> issue previously). Here is how I've configured it: >>> >>> +CONFIG_DEBUG_UART_BASE=0xf1012000 >>> +CONFIG_DEBUG_UART_CLOCK=250000000 >>> +CONFIG_DEBUG_UART=y >> >> Maybe you hit same issue in mach-kirkwood as me in the past for >> mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base >> register address (0xf1012000) when U-Boot was still using the _old_ base >> register address (0xd0012000). >> >> I fixed it by moving code which changes base register address from >> arch_cpu_init() function to arch_very_early_init() function in commit: >> https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 Thanks Pali, this is very likely the root cause here. > Thanks for the info! Looking at that patch, I think I'm out of my > depth :) Here the line for Kirkwood, re-configuring the base address of the internal registers: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-kirkwood/cpu.c#L193 You need to make sure, that this configuration is done before you use the DEBUG UART with base address 0xf1xx.xxxx. If you use the DEBUG UART before this, which is very likely, then you could also test if this works for you: CONFIG_DEBUG_UART_BASE=0xd0012000 > For now I will fix this Pogo V4 with the -u-boot.dtsi, so as > not to mess up anybody who might try UART booting with kwboot. Sure, please go ahead this way for now. BTW: Many years ago my intention was to include the Kirkwood support into the "common" Marvell MVEBU support in mach-mvebu. So that mach-kirkwood and it's special handling could be dropped. It's great to see that Kirkwood is getting attention now. Perhaps this move into mach-mvebu could be addressed at some point. Thanks, Stefan > Thanks, > Tony > >>>>> So this was another factor why it took me >>>>> so long to figure this out :) I've just restored everything and >>>>> removed the uart0 node from the Pogo V4 DTS like above and it is >>>>> working. >>>>> >>>>> But of course, we don't want to change the Pogo V4 DTS, so I will >>>>> submit another patch just for the Pogo V4 to add -u-boot.dtsi for this >>>>> box to enable the dm-pre-reloc tag for uart0. >>>> >>>> Understood. >>> >>> Thanks, >>> Tony >>> >>>> >>>> Thanks, >>>> Stefan Viele Grüße, Stefan Roese
On Thursday 09 February 2023 17:37:54 Tony Dinh wrote: > Hi Pali, > > On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár <pali@kernel.org> wrote: > > > > On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > > > Hi Stefan, > > > > > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > > > > > > > Hi Tony, > > > > > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > > > Hi Stefan, > > > > > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > >> > > > > >> Hi Pali, > > > > >> > > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > > > >>> > > > > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > > > >>> > > > > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > > > >>> md command it is possible to dump it over console. Or via ext4write > > > > >>> command store it so ext4 fs on sd card / sata disk. > > > > >> > > > > >> Thanks for the info. It will be a while before I can get back to this > > > > >> BootROM 1.1 vs 1.2 topic. > > > > >> > > > > > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > > > consistent with the serial documentation in > > > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > > > must also be used. > > > > > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > > > dm-pre-reloc tag is needed. > > > > > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > index 5aa4669ae2..227d5ff802 100644 > > > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > @@ -24,7 +24,8 @@ > > > > > }; > > > > > > > > > > chosen { > > > > > - stdout-path = "uart0:115200n8"; > > > > > + bootargs = "console=ttyS0,115200"; > > > > > + stdout-path = &uart0; > > > > > }; > > > > > > > > > > gpio_keys { > > > > > @@ -97,10 +98,6 @@ > > > > > }; > > > > > }; > > > > > > > > > > -&uart0 { > > > > > - status = "okay"; > > > > > -}; > > > > > - > > > > > /* > > > > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > > > > */ > > > > > > > > FWIU, you are hitting a bug in the early serial console code, perhaps > > > > in serial_check_stdout()? > > > > > > Quite possible. But I recall trying the same stdout path as the > > > NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not > > > the reason. Perhaps the bug is in another part of the function. > > > > > > > > > > > Could you please check if Pogo V4 boots with > > > > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > > > > > > > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the > > > Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted > > > normally with kwboot, all serial input/outputs are OK. > > > > > > > > Also, note that just enabling DEBUG_UART would always make the board > > > > > frozen when u-boot starts. > > > > > > > > This should not be the case of course. Are you sure you've correctly > > > > configured the DEBUG UART? > > > > > > I think I did that correctly (we've used that to debug the orion_timer > > > issue previously). Here is how I've configured it: > > > > > > +CONFIG_DEBUG_UART_BASE=0xf1012000 > > > +CONFIG_DEBUG_UART_CLOCK=250000000 > > > +CONFIG_DEBUG_UART=y > > > > Maybe you hit same issue in mach-kirkwood as me in the past for > > mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base > > register address (0xf1012000) when U-Boot was still using the _old_ base > > register address (0xd0012000). > > > > I fixed it by moving code which changes base register address from > > arch_cpu_init() function to arch_very_early_init() function in commit: > > https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 > > Thanks for the info! Looking at that patch, I think I'm out of my > depth :) That is pretty simple. It is something like this: diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig index c8a193dd4cdf..ba39e9ae416e 100644 --- a/arch/arm/mach-kirkwood/Kconfig +++ b/arch/arm/mach-kirkwood/Kconfig @@ -5,9 +5,11 @@ config FEROCEON_88FR131 config KW88F6192 bool + select ARCH_VERY_EARLY_INIT config KW88F6281 bool + select ARCH_VERY_EARLY_INIT config SHEEVA_88SV131 bool diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile index 3b2eef8d5419..0fb5a2326f5f 100644 --- a/arch/arm/mach-kirkwood/Makefile +++ b/arch/arm/mach-kirkwood/Makefile @@ -6,6 +6,7 @@ obj-y = cpu.o obj-y += cache.o +obj-y += lowlevel.o obj-y += mpp.o # cpu.o and cache.o contain CP15 instructions which cannot be run in diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c index df3e8f11782a..2b493b36c20d 100644 --- a/arch/arm/mach-kirkwood/cpu.c +++ b/arch/arm/mach-kirkwood/cpu.c @@ -189,9 +189,6 @@ int arch_cpu_init(void) struct kwcpu_registers *cpureg = (struct kwcpu_registers *)KW_CPU_REG_BASE; - /* Linux expects the internal registers to be at 0xf1000000 */ - writel(KW_REGS_PHY_BASE, KW_OFFSET_REG); - /* Enable and invalidate L2 cache in write through mode */ writel(readl(&cpureg->l2_cfg) | 0x18, &cpureg->l2_cfg); invalidate_l2_cache(); diff --git a/arch/arm/mach-kirkwood/lowlevel.S b/arch/arm/mach-kirkwood/lowlevel.S index e69de29bb2d1..3b339f97f056 100644 --- a/arch/arm/mach-kirkwood/lowlevel.S +++ b/arch/arm/mach-kirkwood/lowlevel.S @@ -0,0 +1,12 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ + +#include <config.h> +#include <linux/linkage.h> + +ENTRY(arch_very_early_init) + /* Move internal registers from KW_OFFSET_REG to KW_REGS_PHY_BASE */ + ldr r0, =KW_REGS_PHY_BASE + ldr r1, =KW_OFFSET_REG + str r0, [r1] + bx lr +ENDPROC(arch_very_early_init) > For now I will fix this Pogo V4 with the -u-boot.dtsi, so as > not to mess up anybody who might try UART booting with kwboot. > > Thanks, > Tony > > > > > > So this was another factor why it took me > > > > > so long to figure this out :) I've just restored everything and > > > > > removed the uart0 node from the Pogo V4 DTS like above and it is > > > > > working. > > > > > > > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > > > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > > > > box to enable the dm-pre-reloc tag for uart0. > > > > > > > > Understood. > > > > > > Thanks, > > > Tony > > > > > > > > > > > Thanks, > > > > Stefan
Hi Stefan, Hi Pali, On Fri, Feb 10, 2023 at 9:29 AM Pali Rohár <pali@kernel.org> wrote: > > On Thursday 09 February 2023 17:37:54 Tony Dinh wrote: > > Hi Pali, > > > > On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > > > > Hi Stefan, > > > > > > > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > > > > > > > > > Hi Tony, > > > > > > > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > > > > Hi Stefan, > > > > > > > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > >> > > > > > >> Hi Pali, > > > > > >> > > > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > > > > >>> > > > > > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > > > > >>> > > > > > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > > > > >>> md command it is possible to dump it over console. Or via ext4write > > > > > >>> command store it so ext4 fs on sd card / sata disk. > > > > > >> > > > > > >> Thanks for the info. It will be a while before I can get back to this > > > > > >> BootROM 1.1 vs 1.2 topic. > > > > > >> > > > > > > > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > > > > consistent with the serial documentation in > > > > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > > > > must also be used. > > > > > > > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > > > > dm-pre-reloc tag is needed. > > > > > > > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > index 5aa4669ae2..227d5ff802 100644 > > > > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > @@ -24,7 +24,8 @@ > > > > > > }; > > > > > > > > > > > > chosen { > > > > > > - stdout-path = "uart0:115200n8"; > > > > > > + bootargs = "console=ttyS0,115200"; > > > > > > + stdout-path = &uart0; > > > > > > }; > > > > > > > > > > > > gpio_keys { > > > > > > @@ -97,10 +98,6 @@ > > > > > > }; > > > > > > }; > > > > > > > > > > > > -&uart0 { > > > > > > - status = "okay"; > > > > > > -}; > > > > > > - > > > > > > /* > > > > > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > > > > > */ > > > > > > > > > > FWIU, you are hitting a bug in the early serial console code, perhaps > > > > > in serial_check_stdout()? > > > > > > > > Quite possible. But I recall trying the same stdout path as the > > > > NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not > > > > the reason. Perhaps the bug is in another part of the function. > > > > > > > > > > > > > > Could you please check if Pogo V4 boots with > > > > > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > > > > > > > > > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the > > > > Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted > > > > normally with kwboot, all serial input/outputs are OK. > > > > > > > > > > Also, note that just enabling DEBUG_UART would always make the board > > > > > > frozen when u-boot starts. > > > > > > > > > > This should not be the case of course. Are you sure you've correctly > > > > > configured the DEBUG UART? > > > > > > > > I think I did that correctly (we've used that to debug the orion_timer > > > > issue previously). Here is how I've configured it: > > > > > > > > +CONFIG_DEBUG_UART_BASE=0xf1012000 > > > > +CONFIG_DEBUG_UART_CLOCK=250000000 > > > > +CONFIG_DEBUG_UART=y > > > > > > Maybe you hit same issue in mach-kirkwood as me in the past for > > > mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base > > > register address (0xf1012000) when U-Boot was still using the _old_ base > > > register address (0xd0012000). > > > > > > I fixed it by moving code which changes base register address from > > > arch_cpu_init() function to arch_very_early_init() function in commit: > > > https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 > > > > Thanks for the info! Looking at that patch, I think I'm out of my > > depth :) > > That is pretty simple. It is something like this: > > diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig > index c8a193dd4cdf..ba39e9ae416e 100644 > --- a/arch/arm/mach-kirkwood/Kconfig > +++ b/arch/arm/mach-kirkwood/Kconfig > @@ -5,9 +5,11 @@ config FEROCEON_88FR131 > > config KW88F6192 > bool > + select ARCH_VERY_EARLY_INIT > > config KW88F6281 > bool > + select ARCH_VERY_EARLY_INIT > > config SHEEVA_88SV131 > bool > diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile > index 3b2eef8d5419..0fb5a2326f5f 100644 > --- a/arch/arm/mach-kirkwood/Makefile > +++ b/arch/arm/mach-kirkwood/Makefile > @@ -6,6 +6,7 @@ > > obj-y = cpu.o > obj-y += cache.o > +obj-y += lowlevel.o > obj-y += mpp.o > > # cpu.o and cache.o contain CP15 instructions which cannot be run in > diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c > index df3e8f11782a..2b493b36c20d 100644 > --- a/arch/arm/mach-kirkwood/cpu.c > +++ b/arch/arm/mach-kirkwood/cpu.c > @@ -189,9 +189,6 @@ int arch_cpu_init(void) > struct kwcpu_registers *cpureg = > (struct kwcpu_registers *)KW_CPU_REG_BASE; > > - /* Linux expects the internal registers to be at 0xf1000000 */ > - writel(KW_REGS_PHY_BASE, KW_OFFSET_REG); > - > /* Enable and invalidate L2 cache in write through mode */ > writel(readl(&cpureg->l2_cfg) | 0x18, &cpureg->l2_cfg); > invalidate_l2_cache(); > diff --git a/arch/arm/mach-kirkwood/lowlevel.S b/arch/arm/mach-kirkwood/lowlevel.S > index e69de29bb2d1..3b339f97f056 100644 > --- a/arch/arm/mach-kirkwood/lowlevel.S > +++ b/arch/arm/mach-kirkwood/lowlevel.S > @@ -0,0 +1,12 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > + > +#include <config.h> > +#include <linux/linkage.h> > + > +ENTRY(arch_very_early_init) > + /* Move internal registers from KW_OFFSET_REG to KW_REGS_PHY_BASE */ > + ldr r0, =KW_REGS_PHY_BASE > + ldr r1, =KW_OFFSET_REG > + str r0, [r1] > + bx lr > +ENDPROC(arch_very_early_init) Thanks! I'll try this eventually. But please see my response to Stefan below. Would the forced setting CONFIG_DEBUG_UART_BASE=0xd0012000 give us some output from uart0 before arch_early_init ? > > For now I will fix this Pogo V4 with the -u-boot.dtsi, so as > > not to mess up anybody who might try UART booting with kwboot. > > > > Thanks, > > Tony > > > > > > > > So this was another factor why it took me > > > > > > so long to figure this out :) I've just restored everything and > > > > > > removed the uart0 node from the Pogo V4 DTS like above and it is > > > > > > working. > > > > > > > > > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > > > > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > > > > > box to enable the dm-pre-reloc tag for uart0. > > > > > > > > > > Understood. Regarding Stefan's suggestion about trying using CONFIG_DEBUG_UART_BASE=0xd0012000. Yes, I also tried that address (I'm aware of this address while building kernels for some old Armada 370 boards such as the Mirabox and Netgear RN102). I suspect for some reason, i.e. bug, at the pre-relocation phase we don't even have the uart0 device so DEBUG UART printch() just hangs. Thanks, Tony
On Friday 10 February 2023 13:38:44 Tony Dinh wrote: > Hi Stefan, > Hi Pali, > > On Fri, Feb 10, 2023 at 9:29 AM Pali Rohár <pali@kernel.org> wrote: > > > > On Thursday 09 February 2023 17:37:54 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > > > > > Hi Stefan, > > > > > > > > > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > > > > > Hi Stefan, > > > > > > > > > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > > >> > > > > > > >> Hi Pali, > > > > > > >> > > > > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > >>> > > > > > > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > > > > > >>> > > > > > > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > > > > > >>> md command it is possible to dump it over console. Or via ext4write > > > > > > >>> command store it so ext4 fs on sd card / sata disk. > > > > > > >> > > > > > > >> Thanks for the info. It will be a while before I can get back to this > > > > > > >> BootROM 1.1 vs 1.2 topic. > > > > > > >> > > > > > > > > > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > > > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > > > > > consistent with the serial documentation in > > > > > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > > > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > > > > > must also be used. > > > > > > > > > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > > > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > > > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > > > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > > > > > dm-pre-reloc tag is needed. > > > > > > > > > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > index 5aa4669ae2..227d5ff802 100644 > > > > > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > @@ -24,7 +24,8 @@ > > > > > > > }; > > > > > > > > > > > > > > chosen { > > > > > > > - stdout-path = "uart0:115200n8"; > > > > > > > + bootargs = "console=ttyS0,115200"; > > > > > > > + stdout-path = &uart0; > > > > > > > }; > > > > > > > > > > > > > > gpio_keys { > > > > > > > @@ -97,10 +98,6 @@ > > > > > > > }; > > > > > > > }; > > > > > > > > > > > > > > -&uart0 { > > > > > > > - status = "okay"; > > > > > > > -}; > > > > > > > - > > > > > > > /* > > > > > > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > > > > > > */ > > > > > > > > > > > > FWIU, you are hitting a bug in the early serial console code, perhaps > > > > > > in serial_check_stdout()? > > > > > > > > > > Quite possible. But I recall trying the same stdout path as the > > > > > NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not > > > > > the reason. Perhaps the bug is in another part of the function. > > > > > > > > > > > > > > > > > Could you please check if Pogo V4 boots with > > > > > > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > > > > > > > > > > > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the > > > > > Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted > > > > > normally with kwboot, all serial input/outputs are OK. > > > > > > > > > > > > Also, note that just enabling DEBUG_UART would always make the board > > > > > > > frozen when u-boot starts. > > > > > > > > > > > > This should not be the case of course. Are you sure you've correctly > > > > > > configured the DEBUG UART? > > > > > > > > > > I think I did that correctly (we've used that to debug the orion_timer > > > > > issue previously). Here is how I've configured it: > > > > > > > > > > +CONFIG_DEBUG_UART_BASE=0xf1012000 > > > > > +CONFIG_DEBUG_UART_CLOCK=250000000 > > > > > +CONFIG_DEBUG_UART=y > > > > > > > > Maybe you hit same issue in mach-kirkwood as me in the past for > > > > mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base > > > > register address (0xf1012000) when U-Boot was still using the _old_ base > > > > register address (0xd0012000). > > > > > > > > I fixed it by moving code which changes base register address from > > > > arch_cpu_init() function to arch_very_early_init() function in commit: > > > > https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 > > > > > > Thanks for the info! Looking at that patch, I think I'm out of my > > > depth :) > > > > That is pretty simple. It is something like this: > > > > diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig > > index c8a193dd4cdf..ba39e9ae416e 100644 > > --- a/arch/arm/mach-kirkwood/Kconfig > > +++ b/arch/arm/mach-kirkwood/Kconfig > > @@ -5,9 +5,11 @@ config FEROCEON_88FR131 > > > > config KW88F6192 > > bool > > + select ARCH_VERY_EARLY_INIT > > > > config KW88F6281 > > bool > > + select ARCH_VERY_EARLY_INIT > > > > config SHEEVA_88SV131 > > bool > > diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile > > index 3b2eef8d5419..0fb5a2326f5f 100644 > > --- a/arch/arm/mach-kirkwood/Makefile > > +++ b/arch/arm/mach-kirkwood/Makefile > > @@ -6,6 +6,7 @@ > > > > obj-y = cpu.o > > obj-y += cache.o > > +obj-y += lowlevel.o > > obj-y += mpp.o > > > > # cpu.o and cache.o contain CP15 instructions which cannot be run in > > diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c > > index df3e8f11782a..2b493b36c20d 100644 > > --- a/arch/arm/mach-kirkwood/cpu.c > > +++ b/arch/arm/mach-kirkwood/cpu.c > > @@ -189,9 +189,6 @@ int arch_cpu_init(void) > > struct kwcpu_registers *cpureg = > > (struct kwcpu_registers *)KW_CPU_REG_BASE; > > > > - /* Linux expects the internal registers to be at 0xf1000000 */ > > - writel(KW_REGS_PHY_BASE, KW_OFFSET_REG); > > - > > /* Enable and invalidate L2 cache in write through mode */ > > writel(readl(&cpureg->l2_cfg) | 0x18, &cpureg->l2_cfg); > > invalidate_l2_cache(); > > diff --git a/arch/arm/mach-kirkwood/lowlevel.S b/arch/arm/mach-kirkwood/lowlevel.S > > index e69de29bb2d1..3b339f97f056 100644 > > --- a/arch/arm/mach-kirkwood/lowlevel.S > > +++ b/arch/arm/mach-kirkwood/lowlevel.S > > @@ -0,0 +1,12 @@ > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > + > > +#include <config.h> > > +#include <linux/linkage.h> > > + > > +ENTRY(arch_very_early_init) > > + /* Move internal registers from KW_OFFSET_REG to KW_REGS_PHY_BASE */ > > + ldr r0, =KW_REGS_PHY_BASE > > + ldr r1, =KW_OFFSET_REG > > + str r0, [r1] > > + bx lr > > +ENDPROC(arch_very_early_init) > > Thanks! I'll try this eventually. But please see my response to Stefan > below. Would the forced setting CONFIG_DEBUG_UART_BASE=0xd0012000 give > us some output from uart0 before arch_early_init ? I do not know if it gives us any output. It depends on when u-boot start printing something on UART. Beware that initialization of UART can be more earlier than printing something. Note that after arch_cpu_init() is 0xd0012000 invalid. So if initialization happens before arch_cpu_init() but printing starts after arch_cpu_init() then nothing would be visible and it will always fail. > > > For now I will fix this Pogo V4 with the -u-boot.dtsi, so as > > > not to mess up anybody who might try UART booting with kwboot. > > > > > > Thanks, > > > Tony > > > > > > > > > > So this was another factor why it took me > > > > > > > so long to figure this out :) I've just restored everything and > > > > > > > removed the uart0 node from the Pogo V4 DTS like above and it is > > > > > > > working. > > > > > > > > > > > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > > > > > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > > > > > > box to enable the dm-pre-reloc tag for uart0. > > > > > > > > > > > > Understood. > > Regarding Stefan's suggestion about trying using > CONFIG_DEBUG_UART_BASE=0xd0012000. Yes, I also tried that address (I'm > aware of this address while building kernels for some old Armada 370 > boards such as the Mirabox and Netgear RN102). I suspect for some > reason, i.e. bug, at the pre-relocation phase we don't even have the > uart0 device so DEBUG UART printch() just hangs. > > Thanks, > Tony DEBUG UART does not use DM / DT devices like uart0. DEBUG UART does not use DTS file. So even with broken DTS file DEBUG UART should work fine.
Hi Pali, On Fri, Feb 10, 2023 at 1:44 PM Pali Rohár <pali@kernel.org> wrote: > > On Friday 10 February 2023 13:38:44 Tony Dinh wrote: > > Hi Stefan, > > Hi Pali, > > > > On Fri, Feb 10, 2023 at 9:29 AM Pali Rohár <pali@kernel.org> wrote: > > > > > > On Thursday 09 February 2023 17:37:54 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > > > > > > Hi Stefan, > > > > > > > > > > > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > > > > > > Hi Stefan, > > > > > > > > > > > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > > > >> > > > > > > > >> Hi Pali, > > > > > > > >> > > > > > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > >>> > > > > > > > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > > > > > > >>> > > > > > > > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > > > > > > >>> md command it is possible to dump it over console. Or via ext4write > > > > > > > >>> command store it so ext4 fs on sd card / sata disk. > > > > > > > >> > > > > > > > >> Thanks for the info. It will be a while before I can get back to this > > > > > > > >> BootROM 1.1 vs 1.2 topic. > > > > > > > >> > > > > > > > > > > > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > > > > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > > > > > > consistent with the serial documentation in > > > > > > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > > > > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > > > > > > must also be used. > > > > > > > > > > > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > > > > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > > > > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > > > > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > > > > > > dm-pre-reloc tag is needed. > > > > > > > > > > > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > index 5aa4669ae2..227d5ff802 100644 > > > > > > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > @@ -24,7 +24,8 @@ > > > > > > > > }; > > > > > > > > > > > > > > > > chosen { > > > > > > > > - stdout-path = "uart0:115200n8"; > > > > > > > > + bootargs = "console=ttyS0,115200"; > > > > > > > > + stdout-path = &uart0; > > > > > > > > }; > > > > > > > > > > > > > > > > gpio_keys { > > > > > > > > @@ -97,10 +98,6 @@ > > > > > > > > }; > > > > > > > > }; > > > > > > > > > > > > > > > > -&uart0 { > > > > > > > > - status = "okay"; > > > > > > > > -}; > > > > > > > > - > > > > > > > > /* > > > > > > > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > > > > > > > */ > > > > > > > > > > > > > > FWIU, you are hitting a bug in the early serial console code, perhaps > > > > > > > in serial_check_stdout()? > > > > > > > > > > > > Quite possible. But I recall trying the same stdout path as the > > > > > > NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not > > > > > > the reason. Perhaps the bug is in another part of the function. > > > > > > > > > > > > > > > > > > > > Could you please check if Pogo V4 boots with > > > > > > > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > > > > > > > > > > > > > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the > > > > > > Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted > > > > > > normally with kwboot, all serial input/outputs are OK. > > > > > > > > > > > > > > Also, note that just enabling DEBUG_UART would always make the board > > > > > > > > frozen when u-boot starts. > > > > > > > > > > > > > > This should not be the case of course. Are you sure you've correctly > > > > > > > configured the DEBUG UART? > > > > > > > > > > > > I think I did that correctly (we've used that to debug the orion_timer > > > > > > issue previously). Here is how I've configured it: > > > > > > > > > > > > +CONFIG_DEBUG_UART_BASE=0xf1012000 > > > > > > +CONFIG_DEBUG_UART_CLOCK=250000000 > > > > > > +CONFIG_DEBUG_UART=y > > > > > > > > > > Maybe you hit same issue in mach-kirkwood as me in the past for > > > > > mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base > > > > > register address (0xf1012000) when U-Boot was still using the _old_ base > > > > > register address (0xd0012000). > > > > > > > > > > I fixed it by moving code which changes base register address from > > > > > arch_cpu_init() function to arch_very_early_init() function in commit: > > > > > https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 > > > > > > > > Thanks for the info! Looking at that patch, I think I'm out of my > > > > depth :) > > > > > > That is pretty simple. It is something like this: > > > > > > diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig > > > index c8a193dd4cdf..ba39e9ae416e 100644 > > > --- a/arch/arm/mach-kirkwood/Kconfig > > > +++ b/arch/arm/mach-kirkwood/Kconfig > > > @@ -5,9 +5,11 @@ config FEROCEON_88FR131 > > > > > > config KW88F6192 > > > bool > > > + select ARCH_VERY_EARLY_INIT > > > > > > config KW88F6281 > > > bool > > > + select ARCH_VERY_EARLY_INIT > > > > > > config SHEEVA_88SV131 > > > bool > > > diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile > > > index 3b2eef8d5419..0fb5a2326f5f 100644 > > > --- a/arch/arm/mach-kirkwood/Makefile > > > +++ b/arch/arm/mach-kirkwood/Makefile > > > @@ -6,6 +6,7 @@ > > > > > > obj-y = cpu.o > > > obj-y += cache.o > > > +obj-y += lowlevel.o > > > obj-y += mpp.o > > > > > > # cpu.o and cache.o contain CP15 instructions which cannot be run in > > > diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c > > > index df3e8f11782a..2b493b36c20d 100644 > > > --- a/arch/arm/mach-kirkwood/cpu.c > > > +++ b/arch/arm/mach-kirkwood/cpu.c > > > @@ -189,9 +189,6 @@ int arch_cpu_init(void) > > > struct kwcpu_registers *cpureg = > > > (struct kwcpu_registers *)KW_CPU_REG_BASE; > > > > > > - /* Linux expects the internal registers to be at 0xf1000000 */ > > > - writel(KW_REGS_PHY_BASE, KW_OFFSET_REG); > > > - > > > /* Enable and invalidate L2 cache in write through mode */ > > > writel(readl(&cpureg->l2_cfg) | 0x18, &cpureg->l2_cfg); > > > invalidate_l2_cache(); > > > diff --git a/arch/arm/mach-kirkwood/lowlevel.S b/arch/arm/mach-kirkwood/lowlevel.S > > > index e69de29bb2d1..3b339f97f056 100644 > > > --- a/arch/arm/mach-kirkwood/lowlevel.S > > > +++ b/arch/arm/mach-kirkwood/lowlevel.S > > > @@ -0,0 +1,12 @@ > > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > > + > > > +#include <config.h> > > > +#include <linux/linkage.h> > > > + > > > +ENTRY(arch_very_early_init) > > > + /* Move internal registers from KW_OFFSET_REG to KW_REGS_PHY_BASE */ > > > + ldr r0, =KW_REGS_PHY_BASE > > > + ldr r1, =KW_OFFSET_REG > > > + str r0, [r1] > > > + bx lr > > > +ENDPROC(arch_very_early_init) > > > > Thanks! I'll try this eventually. But please see my response to Stefan > > below. Would the forced setting CONFIG_DEBUG_UART_BASE=0xd0012000 give > > us some output from uart0 before arch_early_init ? > > I do not know if it gives us any output. It depends on when u-boot start > printing something on UART. Beware that initialization of UART can be > more earlier than printing something. Note that after arch_cpu_init() is > 0xd0012000 invalid. So if initialization happens before arch_cpu_init() > but printing starts after arch_cpu_init() then nothing would be visible > and it will always fail. > > > > > For now I will fix this Pogo V4 with the -u-boot.dtsi, so as > > > > not to mess up anybody who might try UART booting with kwboot. > > > > > > > > Thanks, > > > > Tony > > > > > > > > > > > > So this was another factor why it took me > > > > > > > > so long to figure this out :) I've just restored everything and > > > > > > > > removed the uart0 node from the Pogo V4 DTS like above and it is > > > > > > > > working. > > > > > > > > > > > > > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > > > > > > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > > > > > > > box to enable the dm-pre-reloc tag for uart0. > > > > > > > > > > > > > > Understood. > > > > Regarding Stefan's suggestion about trying using > > CONFIG_DEBUG_UART_BASE=0xd0012000. Yes, I also tried that address (I'm > > aware of this address while building kernels for some old Armada 370 > > boards such as the Mirabox and Netgear RN102). I suspect for some > > reason, i.e. bug, at the pre-relocation phase we don't even have the > > uart0 device so DEBUG UART printch() just hangs. > > > > Thanks, > > Tony > > DEBUG UART does not use DM / DT devices like uart0. DEBUG UART does not > use DTS file. So even with broken DTS file DEBUG UART should work fine. Sorry, I meant the serial device that DEBUG UART uses, not the specific uart0! I think that device does not exist at that point. Anyway, I tried your patch for ARCH_VERY_EARLY_INIT, and the behavior is the same. Subsequently, with this patch I also tried taking out all printch() calls (to make sure nothing is output). The board is just frozen right when u-boot starts. I think I'll let this problem stew for a while, and come back later. I will turn off DM_SERIAL and run some tests then. In the meantime, if anybody has any Marvell SoC defconfig in which DEBUG_UART was working with DM_SERIAL, I'd appreciate it if you can send that defconfig. Thanks, Tony
Hi all, I'm closing the loop on this thread. Please see below. On Fri, Feb 10, 2023 at 6:29 PM Tony Dinh <mibodhi@gmail.com> wrote: > > Hi Pali, > > On Fri, Feb 10, 2023 at 1:44 PM Pali Rohár <pali@kernel.org> wrote: > > > > On Friday 10 February 2023 13:38:44 Tony Dinh wrote: > > > Hi Stefan, > > > Hi Pali, > > > > > > On Fri, Feb 10, 2023 at 9:29 AM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > On Thursday 09 February 2023 17:37:54 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > > > On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > > > > > > > Hi Stefan, > > > > > > > > > > > > > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > > > > > > > Hi Stefan, > > > > > > > > > > > > > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > > > > >> > > > > > > > > >> Hi Pali, > > > > > > > > >> > > > > > > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > >>> > > > > > > > > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > > > > > > > >>> > > > > > > > > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > > > > > > > >>> md command it is possible to dump it over console. Or via ext4write > > > > > > > > >>> command store it so ext4 fs on sd card / sata disk. > > > > > > > > >> > > > > > > > > >> Thanks for the info. It will be a while before I can get back to this > > > > > > > > >> BootROM 1.1 vs 1.2 topic. > > > > > > > > >> > > > > > > > > > > > > > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > > > > > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > > > > > > > consistent with the serial documentation in > > > > > > > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > > > > > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > > > > > > > must also be used. > > > > > > > > > > > > > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > > > > > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > > > > > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > > > > > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > > > > > > > dm-pre-reloc tag is needed. > > > > > > > > > > > > > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > index 5aa4669ae2..227d5ff802 100644 > > > > > > > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > @@ -24,7 +24,8 @@ > > > > > > > > > }; > > > > > > > > > > > > > > > > > > chosen { > > > > > > > > > - stdout-path = "uart0:115200n8"; > > > > > > > > > + bootargs = "console=ttyS0,115200"; > > > > > > > > > + stdout-path = &uart0; > > > > > > > > > }; > > > > > > > > > > > > > > > > > > gpio_keys { > > > > > > > > > @@ -97,10 +98,6 @@ > > > > > > > > > }; > > > > > > > > > }; > > > > > > > > > > > > > > > > > > -&uart0 { > > > > > > > > > - status = "okay"; > > > > > > > > > -}; > > > > > > > > > - > > > > > > > > > /* > > > > > > > > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > > > > > > > > */ > > > > > > > > > > > > > > > > FWIU, you are hitting a bug in the early serial console code, perhaps > > > > > > > > in serial_check_stdout()? > > > > > > > > > > > > > > Quite possible. But I recall trying the same stdout path as the > > > > > > > NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not > > > > > > > the reason. Perhaps the bug is in another part of the function. > > > > > > > > > > > > > > > > > > > > > > > Could you please check if Pogo V4 boots with > > > > > > > > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > > > > > > > > > > > > > > > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the > > > > > > > Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted > > > > > > > normally with kwboot, all serial input/outputs are OK. > > > > > > > > > > > > > > > > Also, note that just enabling DEBUG_UART would always make the board > > > > > > > > > frozen when u-boot starts. > > > > > > > > > > > > > > > > This should not be the case of course. Are you sure you've correctly > > > > > > > > configured the DEBUG UART? > > > > > > > > > > > > > > I think I did that correctly (we've used that to debug the orion_timer > > > > > > > issue previously). Here is how I've configured it: > > > > > > > > > > > > > > +CONFIG_DEBUG_UART_BASE=0xf1012000 > > > > > > > +CONFIG_DEBUG_UART_CLOCK=250000000 > > > > > > > +CONFIG_DEBUG_UART=y > > > > > > > > > > > > Maybe you hit same issue in mach-kirkwood as me in the past for > > > > > > mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base > > > > > > register address (0xf1012000) when U-Boot was still using the _old_ base > > > > > > register address (0xd0012000). > > > > > > > > > > > > I fixed it by moving code which changes base register address from > > > > > > arch_cpu_init() function to arch_very_early_init() function in commit: > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 > > > > > > > > > > Thanks for the info! Looking at that patch, I think I'm out of my > > > > > depth :) > > > > > > > > That is pretty simple. It is something like this: > > > > > > > > diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig > > > > index c8a193dd4cdf..ba39e9ae416e 100644 > > > > --- a/arch/arm/mach-kirkwood/Kconfig > > > > +++ b/arch/arm/mach-kirkwood/Kconfig > > > > @@ -5,9 +5,11 @@ config FEROCEON_88FR131 > > > > > > > > config KW88F6192 > > > > bool > > > > + select ARCH_VERY_EARLY_INIT > > > > > > > > config KW88F6281 > > > > bool > > > > + select ARCH_VERY_EARLY_INIT > > > > > > > > config SHEEVA_88SV131 > > > > bool > > > > diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile > > > > index 3b2eef8d5419..0fb5a2326f5f 100644 > > > > --- a/arch/arm/mach-kirkwood/Makefile > > > > +++ b/arch/arm/mach-kirkwood/Makefile > > > > @@ -6,6 +6,7 @@ > > > > > > > > obj-y = cpu.o > > > > obj-y += cache.o > > > > +obj-y += lowlevel.o > > > > obj-y += mpp.o > > > > > > > > # cpu.o and cache.o contain CP15 instructions which cannot be run in > > > > diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c > > > > index df3e8f11782a..2b493b36c20d 100644 > > > > --- a/arch/arm/mach-kirkwood/cpu.c > > > > +++ b/arch/arm/mach-kirkwood/cpu.c > > > > @@ -189,9 +189,6 @@ int arch_cpu_init(void) > > > > struct kwcpu_registers *cpureg = > > > > (struct kwcpu_registers *)KW_CPU_REG_BASE; > > > > > > > > - /* Linux expects the internal registers to be at 0xf1000000 */ > > > > - writel(KW_REGS_PHY_BASE, KW_OFFSET_REG); > > > > - > > > > /* Enable and invalidate L2 cache in write through mode */ > > > > writel(readl(&cpureg->l2_cfg) | 0x18, &cpureg->l2_cfg); > > > > invalidate_l2_cache(); > > > > diff --git a/arch/arm/mach-kirkwood/lowlevel.S b/arch/arm/mach-kirkwood/lowlevel.S > > > > index e69de29bb2d1..3b339f97f056 100644 > > > > --- a/arch/arm/mach-kirkwood/lowlevel.S > > > > +++ b/arch/arm/mach-kirkwood/lowlevel.S > > > > @@ -0,0 +1,12 @@ > > > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > > > + > > > > +#include <config.h> > > > > +#include <linux/linkage.h> > > > > + > > > > +ENTRY(arch_very_early_init) > > > > + /* Move internal registers from KW_OFFSET_REG to KW_REGS_PHY_BASE */ > > > > + ldr r0, =KW_REGS_PHY_BASE > > > > + ldr r1, =KW_OFFSET_REG > > > > + str r0, [r1] > > > > + bx lr > > > > +ENDPROC(arch_very_early_init) > > > > > > Thanks! I'll try this eventually. But please see my response to Stefan > > > below. Would the forced setting CONFIG_DEBUG_UART_BASE=0xd0012000 give > > > us some output from uart0 before arch_early_init ? > > > > I do not know if it gives us any output. It depends on when u-boot start > > printing something on UART. Beware that initialization of UART can be > > more earlier than printing something. Note that after arch_cpu_init() is > > 0xd0012000 invalid. So if initialization happens before arch_cpu_init() > > but printing starts after arch_cpu_init() then nothing would be visible > > and it will always fail. > > > > > > > For now I will fix this Pogo V4 with the -u-boot.dtsi, so as > > > > > not to mess up anybody who might try UART booting with kwboot. > > > > > > > > > > Thanks, > > > > > Tony > > > > > > > > > > > > > > So this was another factor why it took me > > > > > > > > > so long to figure this out :) I've just restored everything and > > > > > > > > > removed the uart0 node from the Pogo V4 DTS like above and it is > > > > > > > > > working. > > > > > > > > > > > > > > > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > > > > > > > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > > > > > > > > box to enable the dm-pre-reloc tag for uart0. > > > > > > > > > > > > > > > > Understood. > > > > > > Regarding Stefan's suggestion about trying using > > > CONFIG_DEBUG_UART_BASE=0xd0012000. Yes, I also tried that address (I'm > > > aware of this address while building kernels for some old Armada 370 > > > boards such as the Mirabox and Netgear RN102). I suspect for some > > > reason, i.e. bug, at the pre-relocation phase we don't even have the > > > uart0 device so DEBUG UART printch() just hangs. > > > > > > Thanks, > > > Tony > > > > DEBUG UART does not use DM / DT devices like uart0. DEBUG UART does not > > use DTS file. So even with broken DTS file DEBUG UART should work fine. > > Sorry, I meant the serial device that DEBUG UART uses, not the > specific uart0! I think that device does not exist at that point. > > Anyway, I tried your patch for ARCH_VERY_EARLY_INIT, and the behavior > is the same. Subsequently, with this patch I also tried taking out all > printch() calls (to make sure nothing is output). The board is just > frozen right when u-boot starts. > > I think I'll let this problem stew for a while, and come back later. I > will turn off DM_SERIAL and run some tests then. > > In the meantime, if anybody has any Marvell SoC defconfig in which > DEBUG_UART was working with DM_SERIAL, I'd appreciate it if you can > send that defconfig. OK so finally Debug UART is working on this board. Thanks to Pali's "[PATCH RFC u-boot-mvebu] arm: kirkwood: Move internal registers in arch_very_early_init() function" here: https://lists.denx.de/pipermail/u-boot/2023-March/511973.html The reason that among the Kirkwood boards, only this board seems to be frozen upon starting was this sequence: 1. The stdout-path = "uart0:115200n8" was not recognized as a valid path by serial_check_stdout() (in drivers/serial/serial-uclass.c). So it failed to initialize the serial uclass, and invoke panic_str(). We knew that was what happened, but it should have reset the board when panic was called. 2. The panic_finish() and do_reset() functions did not work correctly in this scenario, because it is too early to have a timer running. So u-boot went into a seemingly infinite loop, because the timer getcount failed at each increment. https://github.com/u-boot/u-boot/blob/master/lib/panic.c#L27 https://github.com/u-boot/u-boot/blob/master/arch/arm/lib/reset.c#L37 IMO, it is unnecessary to sleep to flush the text outputs "No serial driver found" and "resetting ...". When Debug UART is enabled, the text always comes out OK. It is just a precaution, which we might want to do when there is a lot going on after relocation. But it seems a bit overkill and not working in the early phase. I'd suggest that we either remove these sleep periods, or find some way to enable it only after relocation. Thanks, Tony
On Tuesday 14 March 2023 13:59:21 Tony Dinh wrote: > Hi all, > > I'm closing the loop on this thread. Please see below. > > On Fri, Feb 10, 2023 at 6:29 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > Hi Pali, > > > > On Fri, Feb 10, 2023 at 1:44 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > On Friday 10 February 2023 13:38:44 Tony Dinh wrote: > > > > Hi Stefan, > > > > Hi Pali, > > > > > > > > On Fri, Feb 10, 2023 at 9:29 AM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > On Thursday 09 February 2023 17:37:54 Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > > > > > > > On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > > > > > On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > > > > > > > > Hi Stefan, > > > > > > > > > > > > > > > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > > > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > > > > > > > > Hi Stefan, > > > > > > > > > > > > > > > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > > > > > >> > > > > > > > > > >> Hi Pali, > > > > > > > > > >> > > > > > > > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > >>> > > > > > > > > > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > > > > > > > > >>> > > > > > > > > > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > > > > > > > > >>> md command it is possible to dump it over console. Or via ext4write > > > > > > > > > >>> command store it so ext4 fs on sd card / sata disk. > > > > > > > > > >> > > > > > > > > > >> Thanks for the info. It will be a while before I can get back to this > > > > > > > > > >> BootROM 1.1 vs 1.2 topic. > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > > > > > > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > > > > > > > > consistent with the serial documentation in > > > > > > > > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > > > > > > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > > > > > > > > must also be used. > > > > > > > > > > > > > > > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > > > > > > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > > > > > > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > > > > > > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > > > > > > > > dm-pre-reloc tag is needed. > > > > > > > > > > > > > > > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > index 5aa4669ae2..227d5ff802 100644 > > > > > > > > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > @@ -24,7 +24,8 @@ > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > chosen { > > > > > > > > > > - stdout-path = "uart0:115200n8"; > > > > > > > > > > + bootargs = "console=ttyS0,115200"; > > > > > > > > > > + stdout-path = &uart0; > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > gpio_keys { > > > > > > > > > > @@ -97,10 +98,6 @@ > > > > > > > > > > }; > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > -&uart0 { > > > > > > > > > > - status = "okay"; > > > > > > > > > > -}; > > > > > > > > > > - > > > > > > > > > > /* > > > > > > > > > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > > > > > > > > > */ > > > > > > > > > > > > > > > > > > FWIU, you are hitting a bug in the early serial console code, perhaps > > > > > > > > > in serial_check_stdout()? > > > > > > > > > > > > > > > > Quite possible. But I recall trying the same stdout path as the > > > > > > > > NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not > > > > > > > > the reason. Perhaps the bug is in another part of the function. > > > > > > > > > > > > > > > > > > > > > > > > > > Could you please check if Pogo V4 boots with > > > > > > > > > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > > > > > > > > > > > > > > > > > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the > > > > > > > > Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted > > > > > > > > normally with kwboot, all serial input/outputs are OK. > > > > > > > > > > > > > > > > > > Also, note that just enabling DEBUG_UART would always make the board > > > > > > > > > > frozen when u-boot starts. > > > > > > > > > > > > > > > > > > This should not be the case of course. Are you sure you've correctly > > > > > > > > > configured the DEBUG UART? > > > > > > > > > > > > > > > > I think I did that correctly (we've used that to debug the orion_timer > > > > > > > > issue previously). Here is how I've configured it: > > > > > > > > > > > > > > > > +CONFIG_DEBUG_UART_BASE=0xf1012000 > > > > > > > > +CONFIG_DEBUG_UART_CLOCK=250000000 > > > > > > > > +CONFIG_DEBUG_UART=y > > > > > > > > > > > > > > Maybe you hit same issue in mach-kirkwood as me in the past for > > > > > > > mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base > > > > > > > register address (0xf1012000) when U-Boot was still using the _old_ base > > > > > > > register address (0xd0012000). > > > > > > > > > > > > > > I fixed it by moving code which changes base register address from > > > > > > > arch_cpu_init() function to arch_very_early_init() function in commit: > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 > > > > > > > > > > > > Thanks for the info! Looking at that patch, I think I'm out of my > > > > > > depth :) > > > > > > > > > > That is pretty simple. It is something like this: > > > > > > > > > > diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig > > > > > index c8a193dd4cdf..ba39e9ae416e 100644 > > > > > --- a/arch/arm/mach-kirkwood/Kconfig > > > > > +++ b/arch/arm/mach-kirkwood/Kconfig > > > > > @@ -5,9 +5,11 @@ config FEROCEON_88FR131 > > > > > > > > > > config KW88F6192 > > > > > bool > > > > > + select ARCH_VERY_EARLY_INIT > > > > > > > > > > config KW88F6281 > > > > > bool > > > > > + select ARCH_VERY_EARLY_INIT > > > > > > > > > > config SHEEVA_88SV131 > > > > > bool > > > > > diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile > > > > > index 3b2eef8d5419..0fb5a2326f5f 100644 > > > > > --- a/arch/arm/mach-kirkwood/Makefile > > > > > +++ b/arch/arm/mach-kirkwood/Makefile > > > > > @@ -6,6 +6,7 @@ > > > > > > > > > > obj-y = cpu.o > > > > > obj-y += cache.o > > > > > +obj-y += lowlevel.o > > > > > obj-y += mpp.o > > > > > > > > > > # cpu.o and cache.o contain CP15 instructions which cannot be run in > > > > > diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c > > > > > index df3e8f11782a..2b493b36c20d 100644 > > > > > --- a/arch/arm/mach-kirkwood/cpu.c > > > > > +++ b/arch/arm/mach-kirkwood/cpu.c > > > > > @@ -189,9 +189,6 @@ int arch_cpu_init(void) > > > > > struct kwcpu_registers *cpureg = > > > > > (struct kwcpu_registers *)KW_CPU_REG_BASE; > > > > > > > > > > - /* Linux expects the internal registers to be at 0xf1000000 */ > > > > > - writel(KW_REGS_PHY_BASE, KW_OFFSET_REG); > > > > > - > > > > > /* Enable and invalidate L2 cache in write through mode */ > > > > > writel(readl(&cpureg->l2_cfg) | 0x18, &cpureg->l2_cfg); > > > > > invalidate_l2_cache(); > > > > > diff --git a/arch/arm/mach-kirkwood/lowlevel.S b/arch/arm/mach-kirkwood/lowlevel.S > > > > > index e69de29bb2d1..3b339f97f056 100644 > > > > > --- a/arch/arm/mach-kirkwood/lowlevel.S > > > > > +++ b/arch/arm/mach-kirkwood/lowlevel.S > > > > > @@ -0,0 +1,12 @@ > > > > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > > > > + > > > > > +#include <config.h> > > > > > +#include <linux/linkage.h> > > > > > + > > > > > +ENTRY(arch_very_early_init) > > > > > + /* Move internal registers from KW_OFFSET_REG to KW_REGS_PHY_BASE */ > > > > > + ldr r0, =KW_REGS_PHY_BASE > > > > > + ldr r1, =KW_OFFSET_REG > > > > > + str r0, [r1] > > > > > + bx lr > > > > > +ENDPROC(arch_very_early_init) > > > > > > > > Thanks! I'll try this eventually. But please see my response to Stefan > > > > below. Would the forced setting CONFIG_DEBUG_UART_BASE=0xd0012000 give > > > > us some output from uart0 before arch_early_init ? > > > > > > I do not know if it gives us any output. It depends on when u-boot start > > > printing something on UART. Beware that initialization of UART can be > > > more earlier than printing something. Note that after arch_cpu_init() is > > > 0xd0012000 invalid. So if initialization happens before arch_cpu_init() > > > but printing starts after arch_cpu_init() then nothing would be visible > > > and it will always fail. > > > > > > > > > For now I will fix this Pogo V4 with the -u-boot.dtsi, so as > > > > > > not to mess up anybody who might try UART booting with kwboot. > > > > > > > > > > > > Thanks, > > > > > > Tony > > > > > > > > > > > > > > > > So this was another factor why it took me > > > > > > > > > > so long to figure this out :) I've just restored everything and > > > > > > > > > > removed the uart0 node from the Pogo V4 DTS like above and it is > > > > > > > > > > working. > > > > > > > > > > > > > > > > > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > > > > > > > > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > > > > > > > > > box to enable the dm-pre-reloc tag for uart0. > > > > > > > > > > > > > > > > > > Understood. > > > > > > > > Regarding Stefan's suggestion about trying using > > > > CONFIG_DEBUG_UART_BASE=0xd0012000. Yes, I also tried that address (I'm > > > > aware of this address while building kernels for some old Armada 370 > > > > boards such as the Mirabox and Netgear RN102). I suspect for some > > > > reason, i.e. bug, at the pre-relocation phase we don't even have the > > > > uart0 device so DEBUG UART printch() just hangs. > > > > > > > > Thanks, > > > > Tony > > > > > > DEBUG UART does not use DM / DT devices like uart0. DEBUG UART does not > > > use DTS file. So even with broken DTS file DEBUG UART should work fine. > > > > Sorry, I meant the serial device that DEBUG UART uses, not the > > specific uart0! I think that device does not exist at that point. > > > > Anyway, I tried your patch for ARCH_VERY_EARLY_INIT, and the behavior > > is the same. Subsequently, with this patch I also tried taking out all > > printch() calls (to make sure nothing is output). The board is just > > frozen right when u-boot starts. > > > > I think I'll let this problem stew for a while, and come back later. I > > will turn off DM_SERIAL and run some tests then. > > > > In the meantime, if anybody has any Marvell SoC defconfig in which > > DEBUG_UART was working with DM_SERIAL, I'd appreciate it if you can > > send that defconfig. > > OK so finally Debug UART is working on this board. Thanks to Pali's > "[PATCH RFC u-boot-mvebu] arm: kirkwood: Move internal registers in > arch_very_early_init() function" here: > https://lists.denx.de/pipermail/u-boot/2023-March/511973.html > > The reason that among the Kirkwood boards, only this board seems to be > frozen upon starting was this sequence: > > 1. The stdout-path = "uart0:115200n8" was not recognized as a valid > path by serial_check_stdout() (in drivers/serial/serial-uclass.c). So > it failed to initialize the serial uclass, and invoke panic_str(). We > knew that was what happened, but it should have reset the board when > panic was called. > > 2. The panic_finish() and do_reset() functions did not work correctly > in this scenario, because it is too early to have a timer running. So > u-boot went into a seemingly infinite loop, because the timer getcount > failed at each increment. > > https://github.com/u-boot/u-boot/blob/master/lib/panic.c#L27 > https://github.com/u-boot/u-boot/blob/master/arch/arm/lib/reset.c#L37 > > IMO, it is unnecessary to sleep to flush the text outputs "No serial > driver found" and "resetting ...". When Debug UART is enabled, the > text always comes out OK. It is just a precaution, which we might want > to do when there is a lot going on after relocation. But it seems a > bit overkill and not working in the early phase. > > I'd suggest that we either remove these sleep periods, or find some > way to enable it only after relocation. > > Thanks, > Tony Decision is not "after relocation" but rather "full-feature UART driver is in use". Moreover there is already new function named flush() which does "wait until stdout message was sent" and can be used instead of those sleeps. I have already did it on some places (see git history for flush function) but seems that you find some more. And flush() should be compatible also with early UART (and if not then it can be fixed).
Hi Pali, On Tue, Mar 14, 2023 at 2:09 PM Pali Rohár <pali@kernel.org> wrote: > > On Tuesday 14 March 2023 13:59:21 Tony Dinh wrote: > > Hi all, > > > > I'm closing the loop on this thread. Please see below. > > > > On Fri, Feb 10, 2023 at 6:29 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > > Hi Pali, > > > > > > On Fri, Feb 10, 2023 at 1:44 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > On Friday 10 February 2023 13:38:44 Tony Dinh wrote: > > > > > Hi Stefan, > > > > > Hi Pali, > > > > > > > > > > On Fri, Feb 10, 2023 at 9:29 AM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > > > On Thursday 09 February 2023 17:37:54 Tony Dinh wrote: > > > > > > > Hi Pali, > > > > > > > > > > > > > > On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > > > > > > > On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > > > > > > > > > Hi Stefan, > > > > > > > > > > > > > > > > > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > > > > > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > > > > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > > > > > > > > > Hi Stefan, > > > > > > > > > > > > > > > > > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > > > > > > >> > > > > > > > > > > >> Hi Pali, > > > > > > > > > > >> > > > > > > > > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > >>> > > > > > > > > > > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > > > > > > > > > >>> > > > > > > > > > > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > > > > > > > > > >>> md command it is possible to dump it over console. Or via ext4write > > > > > > > > > > >>> command store it so ext4 fs on sd card / sata disk. > > > > > > > > > > >> > > > > > > > > > > >> Thanks for the info. It will be a while before I can get back to this > > > > > > > > > > >> BootROM 1.1 vs 1.2 topic. > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > > > > > > > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > > > > > > > > > consistent with the serial documentation in > > > > > > > > > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > > > > > > > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > > > > > > > > > must also be used. > > > > > > > > > > > > > > > > > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > > > > > > > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > > > > > > > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > > > > > > > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > > > > > > > > > dm-pre-reloc tag is needed. > > > > > > > > > > > > > > > > > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > > index 5aa4669ae2..227d5ff802 100644 > > > > > > > > > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > > @@ -24,7 +24,8 @@ > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > chosen { > > > > > > > > > > > - stdout-path = "uart0:115200n8"; > > > > > > > > > > > + bootargs = "console=ttyS0,115200"; > > > > > > > > > > > + stdout-path = &uart0; > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > gpio_keys { > > > > > > > > > > > @@ -97,10 +98,6 @@ > > > > > > > > > > > }; > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > -&uart0 { > > > > > > > > > > > - status = "okay"; > > > > > > > > > > > -}; > > > > > > > > > > > - > > > > > > > > > > > /* > > > > > > > > > > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > > > > > > > > > > */ > > > > > > > > > > > > > > > > > > > > FWIU, you are hitting a bug in the early serial console code, perhaps > > > > > > > > > > in serial_check_stdout()? > > > > > > > > > > > > > > > > > > Quite possible. But I recall trying the same stdout path as the > > > > > > > > > NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not > > > > > > > > > the reason. Perhaps the bug is in another part of the function. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could you please check if Pogo V4 boots with > > > > > > > > > > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > > > > > > > > > > > > > > > > > > > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the > > > > > > > > > Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted > > > > > > > > > normally with kwboot, all serial input/outputs are OK. > > > > > > > > > > > > > > > > > > > > Also, note that just enabling DEBUG_UART would always make the board > > > > > > > > > > > frozen when u-boot starts. > > > > > > > > > > > > > > > > > > > > This should not be the case of course. Are you sure you've correctly > > > > > > > > > > configured the DEBUG UART? > > > > > > > > > > > > > > > > > > I think I did that correctly (we've used that to debug the orion_timer > > > > > > > > > issue previously). Here is how I've configured it: > > > > > > > > > > > > > > > > > > +CONFIG_DEBUG_UART_BASE=0xf1012000 > > > > > > > > > +CONFIG_DEBUG_UART_CLOCK=250000000 > > > > > > > > > +CONFIG_DEBUG_UART=y > > > > > > > > > > > > > > > > Maybe you hit same issue in mach-kirkwood as me in the past for > > > > > > > > mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base > > > > > > > > register address (0xf1012000) when U-Boot was still using the _old_ base > > > > > > > > register address (0xd0012000). > > > > > > > > > > > > > > > > I fixed it by moving code which changes base register address from > > > > > > > > arch_cpu_init() function to arch_very_early_init() function in commit: > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 > > > > > > > > > > > > > > Thanks for the info! Looking at that patch, I think I'm out of my > > > > > > > depth :) > > > > > > > > > > > > That is pretty simple. It is something like this: > > > > > > > > > > > > diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig > > > > > > index c8a193dd4cdf..ba39e9ae416e 100644 > > > > > > --- a/arch/arm/mach-kirkwood/Kconfig > > > > > > +++ b/arch/arm/mach-kirkwood/Kconfig > > > > > > @@ -5,9 +5,11 @@ config FEROCEON_88FR131 > > > > > > > > > > > > config KW88F6192 > > > > > > bool > > > > > > + select ARCH_VERY_EARLY_INIT > > > > > > > > > > > > config KW88F6281 > > > > > > bool > > > > > > + select ARCH_VERY_EARLY_INIT > > > > > > > > > > > > config SHEEVA_88SV131 > > > > > > bool > > > > > > diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile > > > > > > index 3b2eef8d5419..0fb5a2326f5f 100644 > > > > > > --- a/arch/arm/mach-kirkwood/Makefile > > > > > > +++ b/arch/arm/mach-kirkwood/Makefile > > > > > > @@ -6,6 +6,7 @@ > > > > > > > > > > > > obj-y = cpu.o > > > > > > obj-y += cache.o > > > > > > +obj-y += lowlevel.o > > > > > > obj-y += mpp.o > > > > > > > > > > > > # cpu.o and cache.o contain CP15 instructions which cannot be run in > > > > > > diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c > > > > > > index df3e8f11782a..2b493b36c20d 100644 > > > > > > --- a/arch/arm/mach-kirkwood/cpu.c > > > > > > +++ b/arch/arm/mach-kirkwood/cpu.c > > > > > > @@ -189,9 +189,6 @@ int arch_cpu_init(void) > > > > > > struct kwcpu_registers *cpureg = > > > > > > (struct kwcpu_registers *)KW_CPU_REG_BASE; > > > > > > > > > > > > - /* Linux expects the internal registers to be at 0xf1000000 */ > > > > > > - writel(KW_REGS_PHY_BASE, KW_OFFSET_REG); > > > > > > - > > > > > > /* Enable and invalidate L2 cache in write through mode */ > > > > > > writel(readl(&cpureg->l2_cfg) | 0x18, &cpureg->l2_cfg); > > > > > > invalidate_l2_cache(); > > > > > > diff --git a/arch/arm/mach-kirkwood/lowlevel.S b/arch/arm/mach-kirkwood/lowlevel.S > > > > > > index e69de29bb2d1..3b339f97f056 100644 > > > > > > --- a/arch/arm/mach-kirkwood/lowlevel.S > > > > > > +++ b/arch/arm/mach-kirkwood/lowlevel.S > > > > > > @@ -0,0 +1,12 @@ > > > > > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > > > > > + > > > > > > +#include <config.h> > > > > > > +#include <linux/linkage.h> > > > > > > + > > > > > > +ENTRY(arch_very_early_init) > > > > > > + /* Move internal registers from KW_OFFSET_REG to KW_REGS_PHY_BASE */ > > > > > > + ldr r0, =KW_REGS_PHY_BASE > > > > > > + ldr r1, =KW_OFFSET_REG > > > > > > + str r0, [r1] > > > > > > + bx lr > > > > > > +ENDPROC(arch_very_early_init) > > > > > > > > > > Thanks! I'll try this eventually. But please see my response to Stefan > > > > > below. Would the forced setting CONFIG_DEBUG_UART_BASE=0xd0012000 give > > > > > us some output from uart0 before arch_early_init ? > > > > > > > > I do not know if it gives us any output. It depends on when u-boot start > > > > printing something on UART. Beware that initialization of UART can be > > > > more earlier than printing something. Note that after arch_cpu_init() is > > > > 0xd0012000 invalid. So if initialization happens before arch_cpu_init() > > > > but printing starts after arch_cpu_init() then nothing would be visible > > > > and it will always fail. > > > > > > > > > > > For now I will fix this Pogo V4 with the -u-boot.dtsi, so as > > > > > > > not to mess up anybody who might try UART booting with kwboot. > > > > > > > > > > > > > > Thanks, > > > > > > > Tony > > > > > > > > > > > > > > > > > > So this was another factor why it took me > > > > > > > > > > > so long to figure this out :) I've just restored everything and > > > > > > > > > > > removed the uart0 node from the Pogo V4 DTS like above and it is > > > > > > > > > > > working. > > > > > > > > > > > > > > > > > > > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > > > > > > > > > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > > > > > > > > > > box to enable the dm-pre-reloc tag for uart0. > > > > > > > > > > > > > > > > > > > > Understood. > > > > > > > > > > Regarding Stefan's suggestion about trying using > > > > > CONFIG_DEBUG_UART_BASE=0xd0012000. Yes, I also tried that address (I'm > > > > > aware of this address while building kernels for some old Armada 370 > > > > > boards such as the Mirabox and Netgear RN102). I suspect for some > > > > > reason, i.e. bug, at the pre-relocation phase we don't even have the > > > > > uart0 device so DEBUG UART printch() just hangs. > > > > > > > > > > Thanks, > > > > > Tony > > > > > > > > DEBUG UART does not use DM / DT devices like uart0. DEBUG UART does not > > > > use DTS file. So even with broken DTS file DEBUG UART should work fine. > > > > > > Sorry, I meant the serial device that DEBUG UART uses, not the > > > specific uart0! I think that device does not exist at that point. > > > > > > Anyway, I tried your patch for ARCH_VERY_EARLY_INIT, and the behavior > > > is the same. Subsequently, with this patch I also tried taking out all > > > printch() calls (to make sure nothing is output). The board is just > > > frozen right when u-boot starts. > > > > > > I think I'll let this problem stew for a while, and come back later. I > > > will turn off DM_SERIAL and run some tests then. > > > > > > In the meantime, if anybody has any Marvell SoC defconfig in which > > > DEBUG_UART was working with DM_SERIAL, I'd appreciate it if you can > > > send that defconfig. > > > > OK so finally Debug UART is working on this board. Thanks to Pali's > > "[PATCH RFC u-boot-mvebu] arm: kirkwood: Move internal registers in > > arch_very_early_init() function" here: > > https://lists.denx.de/pipermail/u-boot/2023-March/511973.html > > > > The reason that among the Kirkwood boards, only this board seems to be > > frozen upon starting was this sequence: > > > > 1. The stdout-path = "uart0:115200n8" was not recognized as a valid > > path by serial_check_stdout() (in drivers/serial/serial-uclass.c). So > > it failed to initialize the serial uclass, and invoke panic_str(). We > > knew that was what happened, but it should have reset the board when > > panic was called. > > > > 2. The panic_finish() and do_reset() functions did not work correctly > > in this scenario, because it is too early to have a timer running. So > > u-boot went into a seemingly infinite loop, because the timer getcount > > failed at each increment. > > > > https://github.com/u-boot/u-boot/blob/master/lib/panic.c#L27 > > https://github.com/u-boot/u-boot/blob/master/arch/arm/lib/reset.c#L37 > > > > IMO, it is unnecessary to sleep to flush the text outputs "No serial > > driver found" and "resetting ...". When Debug UART is enabled, the > > text always comes out OK. It is just a precaution, which we might want > > to do when there is a lot going on after relocation. But it seems a > > bit overkill and not working in the early phase. > > > > I'd suggest that we either remove these sleep periods, or find some > > way to enable it only after relocation. > > > > Thanks, > > Tony > > Decision is not "after relocation" but rather "full-feature UART driver > is in use". Moreover there is already new function named flush() which > does "wait until stdout message was sent" and can be used instead of > those sleeps. That's great! > I have already did it on some places (see git history for > flush function) but seems that you find some more. And flush() should be > compatible also with early UART (and if not then it can be fixed). flush() is a much better implementation, even if the timer is working. I'll try that. Thanks, Tony
Hi Pali, On Tue, Mar 14, 2023 at 2:30 PM Tony Dinh <mibodhi@gmail.com> wrote: > > Hi Pali, > > On Tue, Mar 14, 2023 at 2:09 PM Pali Rohár <pali@kernel.org> wrote: > > > > On Tuesday 14 March 2023 13:59:21 Tony Dinh wrote: > > > Hi all, > > > > > > I'm closing the loop on this thread. Please see below. > > > > > > On Fri, Feb 10, 2023 at 6:29 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > > > > Hi Pali, > > > > > > > > On Fri, Feb 10, 2023 at 1:44 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > On Friday 10 February 2023 13:38:44 Tony Dinh wrote: > > > > > > Hi Stefan, > > > > > > Hi Pali, > > > > > > > > > > > > On Fri, Feb 10, 2023 at 9:29 AM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > > > > > On Thursday 09 February 2023 17:37:54 Tony Dinh wrote: > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > > > > > > > > > On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > > > > > > > > > > Hi Stefan, > > > > > > > > > > > > > > > > > > > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese <sr@denx.de> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Tony, > > > > > > > > > > > > > > > > > > > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > > > > > > > > > > Hi Stefan, > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh <mibodhi@gmail.com> wrote: > > > > > > > > > > > >> > > > > > > > > > > > >> Hi Pali, > > > > > > > > > > > >> > > > > > > > > > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali@kernel.org> wrote: > > > > > > > > > > > >>> > > > > > > > > > > > >>> On Thursday 02 February 2023 19:04:45 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 <pali@kernel.org> 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. > > > > > > > > > > > >>> > > > > > > > > > > > >>> BootROM is mapped to 0xF8000000 address and is 64 kB long. So via U-Boot > > > > > > > > > > > >>> md command it is possible to dump it over console. Or via ext4write > > > > > > > > > > > >>> command store it so ext4 fs on sd card / sata disk. > > > > > > > > > > > >> > > > > > > > > > > > >> Thanks for the info. It will be a while before I can get back to this > > > > > > > > > > > >> BootROM 1.1 vs 1.2 topic. > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > > > > > > > > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > > > > > > > > > > consistent with the serial documentation in > > > > > > > > > > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > > > > > > > > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > > > > > > > > > > must also be used. > > > > > > > > > > > > > > > > > > > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > > > > > > > > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > > > > > > > > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > > > > > > > > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > > > > > > > > > > dm-pre-reloc tag is needed. > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > > > index 5aa4669ae2..227d5ff802 100644 > > > > > > > > > > > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > > > > > > > > > > @@ -24,7 +24,8 @@ > > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > > > chosen { > > > > > > > > > > > > - stdout-path = "uart0:115200n8"; > > > > > > > > > > > > + bootargs = "console=ttyS0,115200"; > > > > > > > > > > > > + stdout-path = &uart0; > > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > > > gpio_keys { > > > > > > > > > > > > @@ -97,10 +98,6 @@ > > > > > > > > > > > > }; > > > > > > > > > > > > }; > > > > > > > > > > > > > > > > > > > > > > > > -&uart0 { > > > > > > > > > > > > - status = "okay"; > > > > > > > > > > > > -}; > > > > > > > > > > > > - > > > > > > > > > > > > /* > > > > > > > > > > > > * This PCIE controller has a USB 3.0 XHCI controller at 1,0 > > > > > > > > > > > > */ > > > > > > > > > > > > > > > > > > > > > > FWIU, you are hitting a bug in the early serial console code, perhaps > > > > > > > > > > > in serial_check_stdout()? > > > > > > > > > > > > > > > > > > > > Quite possible. But I recall trying the same stdout path as the > > > > > > > > > > NSA310S, i.e. stdout-path = &uart0. So the stdout-path itself is not > > > > > > > > > > the reason. Perhaps the bug is in another part of the function. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could you please check if Pogo V4 boots with > > > > > > > > > > > CONFIG_REQUIRE_SERIAL_CONSOLE unset? > > > > > > > > > > > > > > > > > > > > > Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the > > > > > > > > > > Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted > > > > > > > > > > normally with kwboot, all serial input/outputs are OK. > > > > > > > > > > > > > > > > > > > > > > Also, note that just enabling DEBUG_UART would always make the board > > > > > > > > > > > > frozen when u-boot starts. > > > > > > > > > > > > > > > > > > > > > > This should not be the case of course. Are you sure you've correctly > > > > > > > > > > > configured the DEBUG UART? > > > > > > > > > > > > > > > > > > > > I think I did that correctly (we've used that to debug the orion_timer > > > > > > > > > > issue previously). Here is how I've configured it: > > > > > > > > > > > > > > > > > > > > +CONFIG_DEBUG_UART_BASE=0xf1012000 > > > > > > > > > > +CONFIG_DEBUG_UART_CLOCK=250000000 > > > > > > > > > > +CONFIG_DEBUG_UART=y > > > > > > > > > > > > > > > > > > Maybe you hit same issue in mach-kirkwood as me in the past for > > > > > > > > > mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base > > > > > > > > > register address (0xf1012000) when U-Boot was still using the _old_ base > > > > > > > > > register address (0xd0012000). > > > > > > > > > > > > > > > > > > I fixed it by moving code which changes base register address from > > > > > > > > > arch_cpu_init() function to arch_very_early_init() function in commit: > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 > > > > > > > > > > > > > > > > Thanks for the info! Looking at that patch, I think I'm out of my > > > > > > > > depth :) > > > > > > > > > > > > > > That is pretty simple. It is something like this: > > > > > > > > > > > > > > diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig > > > > > > > index c8a193dd4cdf..ba39e9ae416e 100644 > > > > > > > --- a/arch/arm/mach-kirkwood/Kconfig > > > > > > > +++ b/arch/arm/mach-kirkwood/Kconfig > > > > > > > @@ -5,9 +5,11 @@ config FEROCEON_88FR131 > > > > > > > > > > > > > > config KW88F6192 > > > > > > > bool > > > > > > > + select ARCH_VERY_EARLY_INIT > > > > > > > > > > > > > > config KW88F6281 > > > > > > > bool > > > > > > > + select ARCH_VERY_EARLY_INIT > > > > > > > > > > > > > > config SHEEVA_88SV131 > > > > > > > bool > > > > > > > diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile > > > > > > > index 3b2eef8d5419..0fb5a2326f5f 100644 > > > > > > > --- a/arch/arm/mach-kirkwood/Makefile > > > > > > > +++ b/arch/arm/mach-kirkwood/Makefile > > > > > > > @@ -6,6 +6,7 @@ > > > > > > > > > > > > > > obj-y = cpu.o > > > > > > > obj-y += cache.o > > > > > > > +obj-y += lowlevel.o > > > > > > > obj-y += mpp.o > > > > > > > > > > > > > > # cpu.o and cache.o contain CP15 instructions which cannot be run in > > > > > > > diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c > > > > > > > index df3e8f11782a..2b493b36c20d 100644 > > > > > > > --- a/arch/arm/mach-kirkwood/cpu.c > > > > > > > +++ b/arch/arm/mach-kirkwood/cpu.c > > > > > > > @@ -189,9 +189,6 @@ int arch_cpu_init(void) > > > > > > > struct kwcpu_registers *cpureg = > > > > > > > (struct kwcpu_registers *)KW_CPU_REG_BASE; > > > > > > > > > > > > > > - /* Linux expects the internal registers to be at 0xf1000000 */ > > > > > > > - writel(KW_REGS_PHY_BASE, KW_OFFSET_REG); > > > > > > > - > > > > > > > /* Enable and invalidate L2 cache in write through mode */ > > > > > > > writel(readl(&cpureg->l2_cfg) | 0x18, &cpureg->l2_cfg); > > > > > > > invalidate_l2_cache(); > > > > > > > diff --git a/arch/arm/mach-kirkwood/lowlevel.S b/arch/arm/mach-kirkwood/lowlevel.S > > > > > > > index e69de29bb2d1..3b339f97f056 100644 > > > > > > > --- a/arch/arm/mach-kirkwood/lowlevel.S > > > > > > > +++ b/arch/arm/mach-kirkwood/lowlevel.S > > > > > > > @@ -0,0 +1,12 @@ > > > > > > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > > > > > > + > > > > > > > +#include <config.h> > > > > > > > +#include <linux/linkage.h> > > > > > > > + > > > > > > > +ENTRY(arch_very_early_init) > > > > > > > + /* Move internal registers from KW_OFFSET_REG to KW_REGS_PHY_BASE */ > > > > > > > + ldr r0, =KW_REGS_PHY_BASE > > > > > > > + ldr r1, =KW_OFFSET_REG > > > > > > > + str r0, [r1] > > > > > > > + bx lr > > > > > > > +ENDPROC(arch_very_early_init) > > > > > > > > > > > > Thanks! I'll try this eventually. But please see my response to Stefan > > > > > > below. Would the forced setting CONFIG_DEBUG_UART_BASE=0xd0012000 give > > > > > > us some output from uart0 before arch_early_init ? > > > > > > > > > > I do not know if it gives us any output. It depends on when u-boot start > > > > > printing something on UART. Beware that initialization of UART can be > > > > > more earlier than printing something. Note that after arch_cpu_init() is > > > > > 0xd0012000 invalid. So if initialization happens before arch_cpu_init() > > > > > but printing starts after arch_cpu_init() then nothing would be visible > > > > > and it will always fail. > > > > > > > > > > > > > For now I will fix this Pogo V4 with the -u-boot.dtsi, so as > > > > > > > > not to mess up anybody who might try UART booting with kwboot. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Tony > > > > > > > > > > > > > > > > > > > > So this was another factor why it took me > > > > > > > > > > > > so long to figure this out :) I've just restored everything and > > > > > > > > > > > > removed the uart0 node from the Pogo V4 DTS like above and it is > > > > > > > > > > > > working. > > > > > > > > > > > > > > > > > > > > > > > > But of course, we don't want to change the Pogo V4 DTS, so I will > > > > > > > > > > > > submit another patch just for the Pogo V4 to add -u-boot.dtsi for this > > > > > > > > > > > > box to enable the dm-pre-reloc tag for uart0. > > > > > > > > > > > > > > > > > > > > > > Understood. > > > > > > > > > > > > Regarding Stefan's suggestion about trying using > > > > > > CONFIG_DEBUG_UART_BASE=0xd0012000. Yes, I also tried that address (I'm > > > > > > aware of this address while building kernels for some old Armada 370 > > > > > > boards such as the Mirabox and Netgear RN102). I suspect for some > > > > > > reason, i.e. bug, at the pre-relocation phase we don't even have the > > > > > > uart0 device so DEBUG UART printch() just hangs. > > > > > > > > > > > > Thanks, > > > > > > Tony > > > > > > > > > > DEBUG UART does not use DM / DT devices like uart0. DEBUG UART does not > > > > > use DTS file. So even with broken DTS file DEBUG UART should work fine. > > > > > > > > Sorry, I meant the serial device that DEBUG UART uses, not the > > > > specific uart0! I think that device does not exist at that point. > > > > > > > > Anyway, I tried your patch for ARCH_VERY_EARLY_INIT, and the behavior > > > > is the same. Subsequently, with this patch I also tried taking out all > > > > printch() calls (to make sure nothing is output). The board is just > > > > frozen right when u-boot starts. > > > > > > > > I think I'll let this problem stew for a while, and come back later. I > > > > will turn off DM_SERIAL and run some tests then. > > > > > > > > In the meantime, if anybody has any Marvell SoC defconfig in which > > > > DEBUG_UART was working with DM_SERIAL, I'd appreciate it if you can > > > > send that defconfig. > > > > > > OK so finally Debug UART is working on this board. Thanks to Pali's > > > "[PATCH RFC u-boot-mvebu] arm: kirkwood: Move internal registers in > > > arch_very_early_init() function" here: > > > https://lists.denx.de/pipermail/u-boot/2023-March/511973.html > > > > > > The reason that among the Kirkwood boards, only this board seems to be > > > frozen upon starting was this sequence: > > > > > > 1. The stdout-path = "uart0:115200n8" was not recognized as a valid > > > path by serial_check_stdout() (in drivers/serial/serial-uclass.c). So > > > it failed to initialize the serial uclass, and invoke panic_str(). We > > > knew that was what happened, but it should have reset the board when > > > panic was called. > > > > > > 2. The panic_finish() and do_reset() functions did not work correctly > > > in this scenario, because it is too early to have a timer running. So > > > u-boot went into a seemingly infinite loop, because the timer getcount > > > failed at each increment. > > > > > > https://github.com/u-boot/u-boot/blob/master/lib/panic.c#L27 > > > https://github.com/u-boot/u-boot/blob/master/arch/arm/lib/reset.c#L37 > > > > > > IMO, it is unnecessary to sleep to flush the text outputs "No serial > > > driver found" and "resetting ...". When Debug UART is enabled, the > > > text always comes out OK. It is just a precaution, which we might want > > > to do when there is a lot going on after relocation. But it seems a > > > bit overkill and not working in the early phase. > > > > > > I'd suggest that we either remove these sleep periods, or find some > > > way to enable it only after relocation. > > > > > > Thanks, > > > Tony > > > > Decision is not "after relocation" but rather "full-feature UART driver > > is in use". Moreover there is already new function named flush() which > > does "wait until stdout message was sent" and can be used instead of > > those sleeps. > > That's great! > > > I have already did it on some places (see git history for > > flush function) but seems that you find some more. And flush() should be > > compatible also with early UART (and if not then it can be fixed). flush() works fine with early UART! I will send in a patch for panic and reset function. Thanks, Tony > > flush() is a much better implementation, even if the timer is working. > I'll try that. > > Thanks, > Tony
diff --git a/arch/arm/dts/kirkwood-u-boot.dtsi b/arch/arm/dts/kirkwood-u-boot.dtsi new file mode 100644 index 0000000000..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 <mibodhi@gmail.com> + */ +&uart0 { + u-boot,dm-pre-reloc; +};
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 <mibodhi@gmail.com> --- arch/arm/dts/kirkwood-u-boot.dtsi | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 arch/arm/dts/kirkwood-u-boot.dtsi