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

[Sean Nyekjær]

Hi

On 21 January 2018 13:39:15 CET, "Andreas Färber" <afaerber at suse.de> wrote:
>Hi,
>
>Am 20.01.2018 um 15:32 schrieb Sean Nyekjær:
>> On 20 January 2018 10:07:57 CET, Stefan Roese <sr at 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.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?
>
>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.