Hi On 20 January 2018 10:07:57 CET, Stefan Roese <s...@denx.de> wrote: >Hi Andreas, > >On 20.01.2018 03:30, Andreas Färber wrote: >> 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 <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? I was fixing when booting from uart when the romloader does fallback from other devices. What value does boot_device contain? BR Sean > >Thanks, >Stefan > >> 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 >>> >> >> > >Viele Grüße, >Stefan -- Sent from my mobile device. Please excuse my brevity. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot