kwboot: Testing latest kwboot with Kirkwood SoC boards

[Pali Rohár]

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.

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'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.

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.

> > > 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.