[U-Boot] [PATCH v4 0/6] Support for the Turris Omnia router

[Sean Nyekjær]

Hi

On 20 January 2018 10:07:57 CET, Stefan Roese <sr at 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.nyekjaer at 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 at prevas.dk>
>>      Signed-off-by: Stefan Roese <sr at 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.