Am 20.01.2018 um 02:40 schrieb Andreas Färber: > Hi, > > 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 >> >> I have to admit, that don't know anything about this "sendbeacon" >> tool. >> >>> ./tools/kwboot -t -B 115200 /dev/ttyUSBx -b u-boot-spl.kwb -p >> >> This is what I have used, when I tested / debugged images for >> Armada XP / 38x. Please note that the init sequence is somewhat >> "fragile" - so I added the -q and -s parameters, to optionally >> finetune the startup timings: >> >> # kwboot >> ... >> -q <req-delay>: use specific request-delay >> -s <resp-timeo>: use specific response-timeout >> >> You might what to play a bit with these parameters as well. > > I saw them but had no idea what to pass as values. ;) > I did try -a, but it worked with and without. > >> BTW: I don't have access to the Omnia router, so I can't >> test anything on this specific platform. >> >> BTW2: Kosta from Marvell just recently added a new tool / script, >> to help debug / boot Marvell MVEBU boards: >> >> tools/mrvl_uart.sh >> >> He told me that its better to use than the "old" kwboot tool. >> I never found the time to use it up until now, so I have no >> personal experience. But I'm pretty sure that Kosta did a >> great job here. So please give it a try. > > I did not get it to work ... or was not patient enough. > >>> # 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 Regards, Andreas >>> 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. >> >> Hmmm. I can only > > I have reconfirmed (with our GCC 7.2.1) that no version works for me: > > v2017.07 did not have turris_omnia defconfig yet > b6ee860b87d8accedfb7a1fd5414f7c483603234 bad (adds turris_omnia) > v2017.09 bad > v2017.11 bad > v2018.01 bad > master bad (c4cb6e64bf068eaa1f7c96cb37da7ae6d40bbbff / arc merge) > > So I have nothing to bisect and wonder how Marek tested this... > >>> I also ran into a couple DDR3 training failures when booting via UART. >>> No such training problems observed booting from SPI. >> >> Using the same U-Boot version, meaning same DDR init code? > > Yes. Only difference being BOOT_FROM and the spl.c modification. > >> Thats >> strange. I have not really worked with Armada 38x for quite some >> time, but I don't remember any such problems that you describe >> here. I might need to dig up an Armada 38x board and give it a >> try myself... > > 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 [email protected] https://lists.denx.de/listinfo/u-boot
