[U-Boot] mrvl_uart.sh and Turris Omnia (was: [EXT] Re: [PATCH v4 0/6] Support for the Turris Omnia router)

["Andreas Färber" <afaerber@suse.de>]

Hi Kosta,

Am 20.01.2018 um 10:48 schrieb Kostya Porotchkin:
> Which Marvell SoC is used on this platform?

According to Linux DT filename it's an Armada 385.

> The script I added recently covert only the new Armada SoCs like A8K and
> A8K+.
> It will not work with A3K family.

# UART recovery downloader for Armada SoCs

    echo -e "\nMarvell recovery image downloader for Armada SoC family."

    echo -e "- The speed-up option is not awailable in SoC families
prior to A8K+"
    echo -e "- This utility is not compatible with Armada 37xx SoC family\n"

https://patchwork.ozlabs.org/patch/843021/

It doesn't rule out anything other than 37xx, sounding very generic and
making no specific statements about earlier 32-bit models. ;)

If it's known to be 7K/8K only, then you should spell that out please.
Note that I've just sent out some potentially conflicting output
cleanups that I noticed above.

Another comment: The kwboot tool is particularly handy in that -p allows
to send a binary u-boot-spl.kwb (such as from our Open Build Service)
with default of "BOOT_FROM spi" for turris_omnia here, without needing
to rebuild from sources with "BOOT_FROM uart" like I seem to need to for
mrvl_uart.sh. Are you planning to re-implement that for your script?

Regards,
Andreas


> -------- Original message --------
> From: Andreas Färber <afaerber@suse.de>
> Date: 1/20/18 05:34 (GMT+02:00)
> To: Stefan Roese <sr@denx.de>, u-boot at lists.denx.de, Kostya Porotchkin
> <kostap@marvell.com>
> Cc: Marek Behún <marek.behun@nic.cz>, Tomas Hlavacek
> <tomas.hlavacek@nic.cz>
> Subject: [EXT] Re: [U-Boot] [PATCH v4 0/6] Support for the Turris Omnia
> router
> 
> External Email
> 
> ----------------------------------------------------------------------
> 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.
> 
> https://gitlab.labs.nic.cz/turris/misc/tree/master/sendbeacon
> 
>>>> ./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.
> 
> It seems, just as with kwboot, the tool alone is not enough. If I use
> sendbeacon before and in mrvl_uart.sh just press enter without another
> reset, then the transfer does work for me, and if in the script I add -b
> $default_baudrate to the minicom line, then I also see useful output.
> 
> But it does not affect the reported non-SPL boot breakage, i.e. it still
> reboots from SPI immediately after loading from UART.
> 
> Regards,
> Andreas
> 
> -- 
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)


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