kwboot: Testing latest kwboot with Kirkwood SoC boards

[Tony Dinh]

Hi Pali,

On Fri, Nov 5, 2021 at 5:10 PM Pali Rohár <pali at kernel.org> wrote:
>
> On Friday 05 November 2021 16:36:47 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Fri, Nov 5, 2021 at 3:15 PM Pali Rohár <pali at kernel.org> wrote:
> > >
> > > On Friday 05 November 2021 15:07:17 Tony Dinh wrote:
> > > > > > Also, I have several Kirkwood boards (with various old BootROM
> > > > > > versions) that I can run the kwboot tests on. Will keep you posted.
> > > > >
> > > > > Ok! Do you have some Kirkwood board with PCIe slot? If yes, I would like
> > > > > to see dumps from config space of Kirkwood PCIe Root Port, see:
> > > > > https://lore.kernel.org/u-boot/20211104154921.b6zxjpczj7t6qlct@pali/
> > > >
> > > > I have these Kirwood boards with PCI:
> > > > - No slot (host bus for USB 3.0): Pogoplug V4 (6192), Zyxel NSA325v2
> > > > (6282). These 2 boards can be kwboot.
> > > > - Iomega iConnect (6281), with PCIe slot for Wifi card. This board
> > > > does not have kwboot booting support.
> > >
> > > What do you mean that it 'does not have kwboot booting support'?
> > > 88F6281 is also Kirkwood and UART booting with kwboot should work.
> >
> > Most of the Kirkwood boards do have UART booting support. However, in
> > my past experience, some Kirkwood boxes did not work with kwboot
> > booting. It was observed experimentally that certain BootROM versions
> > (depending on the time of manufacturing) on the 88F6281 SoC have
> > problems with UART booting. But we have not proven this to be the real
> > reason. These boards failed UART booting (the behavior is like the
> > UART magic string handshake never occur):
> >
> > Seagate Dockstar (all), Iomega iConnect (all), Sheevaplug (some models
> > probably do work), Seagate GoFlex Net (most boxes work, but a few
> > models don't, and they have a different BootROM version from ones that
> > do work).
>
> Hmm... ok. Maybe some bootrom versions have broken UART booting.
>
> During experiment with A385 I observed that it is needed to send
> continuous stream of boot pattern without delay, so bootrom can properly
> detect it and enter UART booting. But after bootrom is in UART booting
> mode, it responds only when do not transmitting anything for some few
> milliseconds.
> So it is needed to solve two timing issues. First with upper bound (you
> cannot use large delay as bootrom does not detect boot pattern) and
> second with lower bound (you cannot use small delay as bootrom does not
> answer). Plus another issue that linux kernel does provide asynchronous
> tty API which could tell when output buffer was transmitted via UART.

That's exactly what I've found trying to boot the Thecus N2350 (Armada
385). I've tried various -q -s parameters but could not find the right
combination! OTOH, the Zyxel NAS326 (Armada 380) is OK with just the
default timing (still more work on my part in the u-boot image, but
kwboot started OK).

>
> If some bootrom versions are too much timing sensitive and you do not
> know exact characteristic of it (and also of UART HW on the host) then
> it could be hard or impossible to enter that UART boot mode.

I've always suspected the box UART HW is the reason for failure to
handshake, not the BootROM. But I'll try testing the old Kirkwood
boxes again with the new kwboot to be sure.

> I'm planning to rewrite kwboot code which is sending boot pattern to be
> more precise on timings... So if you are interested in testing it, I
> could do it in a way with more configurable delays... once I would have
> some time for it.

I'll be glad to test any new kwboot code you will have. My main
interest is the Armada 38x and all Kirkwood boards.

>
> You could try to use tools/mrvl_uart.sh instead of kwboot. It implements
> also code for sending boot pattern. But it requires valid image with
> UART signature, it does not support on-the-fly patching like kwboot.

That's what I did to boot the stock Thecus N2350 u-boot UART version.
An old version of this mrvl_uart.sh script has been on the net for
quite some time. But kwboot is more robust in the timing setup and
allows us to boot the final version that will be flashed.

> > > > I'll take a look at your link above and get back to you about the
> > > > config space dumps.
> > > >
> > > > By the way, I'm starting to look at the driver/pci/pci_mvebu.c to see
> > > > if it can be made to work with Kirkwood SoCs. I think there are many
> > > > differences in the addresses and memory space. I would appreciate it
> > > > if you have a general assessment whether I can use that driver for
> > > > Kirkwood.
> > >
> > > pci_mvebu.c should work with Kirkwood SoCs and also with all these
> > > 32-bit Marvell SoCs: Orion, Discovery, Kirkwood, Dove, A370, AXP, A375,
> > > A38x and A39x. According to Functional Specifications all these SoCs
> > > have common PCIe register set.
> >
> > That's great to hear!
> >
> > >
> > > If there is any issue with it, I could try to look at it.
> >
> > At the moment, pci_mvebu.c is not included in the build for Kirkwood
> > boards because ./drivers/pci/Kconfig excludes it:
> >
> > config PCI_MVEBU
> > bool "Enable Armada XP/38x PCIe driver"
> > depends on ARCH_MVEBU
> >
> > When I removed the above  dependency, the build had errors. Because
> > different soc.h and cpu.h are brought into pci_mvebu.c when
> > ARCH_KIRWOOD is enabled and ARCH_MVEBU is disabled.
> >
> > #include <asm/arch/cpu.h>
> > #include <asm/arch/soc.h>
>
> So, it it needed to do some adjustment of SoC related code and defines.
> I think the relevant parts are mapping of mbus windows.

I did look a bit at the mbus windows. There are some differences from
MVEBU, such as in arch/arm/dts/kirkwood.dtsi

pcie-mem-aperture = <0xe0000000 0x10000000>; /* 256 MiB memory space */
pcie-io-aperture  = <0xf2000000 0x100000>;   /*   1 MiB    I/O space */

But my knowledge in PCI drivers is practically nothing, just hacking
it :) So if you plan to make this driver work for Kirkwood, I'd be
happy to volunteer to be a tester.

Thanks,
Tony