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

[Andreas Färber]

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.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)