Hi
On 21 January 2018 13:39:15 CET, "Andreas Färber" afaerber@suse.de wrote:
Hi,
Am 20.01.2018 um 15:32 schrieb Sean Nyekjær:
On 20 January 2018 10:07:57 CET, Stefan Roese sr@denx.de wrote:
On 20.01.2018 03:30, Andreas Färber wrote:
Am 20.01.2018 um 02:40 schrieb Andreas Färber:
Am 18.01.2018 um 18:20 schrieb Stefan Roese:
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
[...]
> ./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.
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?
I've so far found that v2017.11 had UART boot working okay.
git-bisect pointed to this commit:
e83e2b390038c9075642cb243a6292241beb8d73 is the first bad commit commit e83e2b390038c9075642cb243a6292241beb8d73 Author: Sean Nyekjaer sean.nyekjaer@prevas.dk Date: Fri Nov 24 14:01:28 2017 +0100
arm: mvebu: fix boot from UART when in fallback mode It's the first 8 bits of the bootrom error register that contain the boot error/fallback error code. Let's check that and continue to boot from UART. Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Signed-off-by: Stefan Roese <sr@denx.de>:040000 040000 c4c5cb4287ae8c3ced749a9734213a5844ddf1d9 772ec1e6401cbb2616b1337ff8757b72240458b3 M arch
Many thanks for digging into this. I'll try to check UART booting with a A38x board sometime next week. Perhaps Sean already has some ideas in the meantime...
What device are the Omnia booting from?
This is about UART boot not working. The regular boot device is SPI.
I was fixing when booting from uart when the romloader does fallback
from other devices.
I am testing UART boot forced by user via sendbeacon and kwboot tools, as well as regular SPI based boot.
https://gitlab.labs.nic.cz/turris/misc/tree/master/sendbeacon
What value does boot_device contain?
Since it's not taking the right return path for A38x, it must be zero.
If you force SoC to boot from uart then the error register should be zero. I guess we need some more handling here...
I have tested this on a custom armada 388 board as well as Marvell development board.
/Sean
Regards, Andreas