[U-Boot] [PATCH v4 0/6] Support for the Turris Omnia router

[Stefan Roese]

Hi Andreas,

On 17.01.2018 16:52, Andreas Färber wrote:
> Am 09.06.2017 um 19:28 schrieb Marek Behún:
>> This is the fourth version of patches for adding support for the
>> Turris Omnia board, a router developed by the CZ.NIC.
> 
> I'm still facing trouble testing turris_omnia on latest v2018.01.
> 
> First, that made me notice there's no README for how to test and deploy.
> I'm aware of temporary:
> sendbeacon /dev/ttyUSBx

I have to admit, that don't know anything about this "sendbeacon"
tool.

> ./tools/kwboot -t -B 115200 /dev/ttyUSBx -b u-boot-spl.kwb -p

This is what I have used, when I tested / debugged images for
Armada XP / 38x. Please note that the init sequence is somewhat
"fragile" - so I added the -q and -s parameters, to optionally
finetune the startup timings:

# kwboot
...
   -q <req-delay>:  use specific request-delay
   -s <resp-timeo>: use specific response-timeout

You might what to play a bit with these parameters as well.

BTW: I don't have access to the Omnia router, so I can't
test anything on this specific platform.

BTW2: Kosta from Marvell just recently added a new tool / script,
to help debug / boot Marvell MVEBU boards:

tools/mrvl_uart.sh

He told me that its better to use than the "old" kwboot tool.
I never found the time to use it up until now, so I have no
personal experience. But I'm pretty sure that Kosta did a
great job here. So please give it a try.

> # or without -p when s/BOOT_FROM spi/BOOT_FROM uart/
> and permanent:
> tftpboot 0x1000000 u-boot-spl.kwb
> sf probe
> sf update 0x1000000 0 $filesize
> 
> I used to have the original factory CZ.NIC U-Boot in SPI and booted test
> versions only via sendbeacon+kwboot.
> 
> With mainline that appears to be broken - the CONFIG_ARMADA_38X code in
> arch/arm/mach-mvebu/spl.c seems to run into !boot_device and instead of
> UART tries to boot from SPI - nothing happens then and kwboot complains.
> I can force it to continue booting from UART by commenting out the if.
> So Stefan, it looks like your auto-detection is not working here and the
> Kconfig option to force it was dropped prematurely.

Hmmm. Then some patch must have broken this UART boot-ability. Could
you by any chance git-bisect, to check which patch broke this
functionality? Perhaps some of the newer patches from Sean Nyekjaer?

> When forcing UART, as soon as the progress surpasses 99%, it reboots
> into SPI SPL without any error message.
> Using the old U-Boot fork I've tried flashing u-boot-spl.kwb - similarly
> it gets stuck in the SPL trying to boot on from SPI. After a while it
> reboots, and so on in a loop.
> 
> So it seems that non-SPL U-Boot 2018.01 is broken, on my 2 GB model.

Hmmm. I can only

> I also ran into a couple DDR3 training failures when booting via UART.
> No such training problems observed booting from SPI.

Using the same U-Boot version, meaning same DDR init code? Thats
strange. I have not really worked with Armada 38x for quite some
time, but I don't remember any such problems that you describe
here. I might need to dig up an Armada 38x board and give it a
try myself...

Thanks,
Stefan