[PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards

Thu Feb 9 22:45:41 CET 2023

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 at 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 at gmail.com> wrote:
> > >>
> > >> Hi Pali,
> > >>
> > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <pali at 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 at 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