Hi Pali, On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár <p...@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 <s...@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 <mibo...@gmail.com> wrote: > > > >> > > > >> Hi Pali, > > > >> > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár <p...@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 <p...@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