Hi, Am 20.01.2018 um 15:32 schrieb Sean Nyekjær: > On 20 January 2018 10:07:57 CET, Stefan Roese <s...@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.nyekj...@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.nyekj...@prevas.dk> >>> Signed-off-by: Stefan Roese <s...@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. 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
