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

[Andreas Färber]

Hi Marek and Stefan,

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
./tools/kwboot -t -B 115200 /dev/ttyUSBx -b u-boot-spl.kwb -p
# 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.

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.

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

Any hints appreciated.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)