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) _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot