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

[Sean Nyekjær]

Hi

On 2018-01-21 13:39, Andreas Färber 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.
Can you try to enable debug here [1].
I would like to see what device it will boot from.

/Sean

[1]: http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-mvebu/spl.c#l46