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

Sun Jan 21 09:02:03 UTC 2018

Hi, Andreas,

> -----Original Message-----
> From: Andreas Färber [mailto:afaerber at suse.de]
> Sent: Saturday, January 20, 2018 14:35
> To: Kostya Porotchkin; u-boot at lists.denx.de
> Cc: Stefan Roese; Marek Behún; Tomas Hlavacek
> Subject: mrvl_uart.sh and Turris Omnia (was: [EXT] Re: [U-Boot] [PATCH
> v4 0/6] Support for the Turris Omnia router)
> 
> 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.
[Konstantin Porotchkin] 
Basically it will work with any Armada device, even with earlier KW SoCs.
The difference is that 32-bit SoCs are mandating different image formats for different boot devices.
We have removed this requirement from 64-bit models, so flash image format is the same for SPI, UART, or eMMC.
For 32-bit devices you need to get UART image in order to use with this script.
Marvell's A38x/A39x SDK build script always produces "uart recovery" image in addition to the requested boot device, so we never needed to convert the image on the fly as it is done by kwboot utility.
> 
> 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?
[Konstantin Porotchkin] 
For supporting legacy devices we probably need to define some environment variable
Something like "ARMADA_LEGACY" and if it set, the source flash image should be copied to a temporary location replacing the boot device and the checksum fields in the main header with "UART" and recalculated checksum value respectfully.
Then such image could be used by the script as usual.
I currently a bit busy with implementing support for the new Marvell SoC families, so cannot promise you to add legacy support shortly.
I even do not have older platform boards on my work table for testing such support.

Regards
Kosta
> 
> Regards,
> Andreas
> 
> 
> > -------- Original message --------
> > From: Andreas Färber <afaerber at suse.de>
> > Date: 1/20/18 05:34 (GMT+02:00)
> > To: Stefan Roese <sr at denx.de>, u-boot at lists.denx.de, Kostya Porotchkin
> > <kostap at marvell.com>
> > Cc: Marek Behún <marek.behun at nic.cz>, Tomas Hlavacek
> > <tomas.hlavacek at 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)