Hi On 21 January 2018 13:39:15 CET, "Andreas Färber" <[email protected]> wrote: >Hi, > >Am 20.01.2018 um 15:32 schrieb Sean Nyekjær: >> On 20 January 2018 10:07:57 CET, Stefan Roese <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>> Signed-off-by: Stefan Roese <[email protected]> >>>> >>>> :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 -- Sent from my mobile device. Please excuse my brevity. _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
