[U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support

[Stefano Babic]

Hi Stefan,

On 07/08/2017 20:06, Stefan Agner wrote:
> Hi Eric,
> 
> On 2017-08-06 08:19, Eric Nelson wrote:
>> Hi Stefan,
>>
>> On 08/04/2017 04:38 PM, Stefan Agner wrote:
>>> From: Stefan Agner <stefan.agner at toradex.com>
>>>
>>> This series adds NXP's Serial Download Protocol (SDP) support via
>>> USB for SPL/U-Boot. It allows to download U-Boot via USB from a
>>> (recovered) SPL using the same tools used to download SPL itself
>>> (specifically imx_usb, but also sb_loader seems to work).
>>>
>>
>> Nice!
>>
>>> The idea has been brought up when the first targets started to make
>>> use of SPL for DDR initialization, see:
>>> https://lists.denx.de/pipermail/u-boot/2015-July/220330.html
>>>
>>
>> There have been lots of discussions surrounding the use of SDP,
>> and this seems to be a nice alternative to using the i.MX "plugin"
>> mode that I explored a while back:
>>
>> https://lists.denx.de/pipermail/u-boot/2017-July/thread.html#298266
>>
> 
> Hm, wasn't aware of that particular effort, thanks for pointing to it.
> From a quick glance, it did not work out so far, is this correct?
> 
> I looked into plugin mode also a little bit, but I did not continue to
> look into it after reading this sentence in the i.MX 6 RM:
> 
> 8.7 Plugin Image
> The boot ROM detects the image type using the plugin flag of the boot
> data structure (see
> Boot Data Structure). If the plugin flag is 1, then the ROM uses the
> image as a plugin
> function. The function must initialize the boot device and copy the
> program image to the
> final location. At the end the plugin function must return with the
> program image
> parameters. (See High level boot sequence for details about boot flow).
> 
> 
> So if SPL should work as a plugin as NXP defines it, SPL is supposed to
> load the image from somewhere. The boot ROM then only takes care about
> image verification and further boot steps, but it's the plugins job to
> get the image from somewhere and store it in RAM.
> 

Right, and this is also the weak point. There are also some cases (at
least, in some projects of mine) where this conflicts with the setup of
the RAM controller. We need to set the RAM controller to load the code
or to fight with the limitation of the IRAM.

> Afact this is not really helpful in our case. We would want the boot ROM
> to go through the boot sequence (again).

Agree. This makes the whole boot process easier to understand - and not
to mention the fact that code of BootROM is not officially published,
and we cannot know what it exactly does.

> 
> Unless returning an error/invalid image causes the boot ROM to go
> through boot sequence again?
> 
> 
> The nice thing with our own SDP implementation is we can reuse it even
> from within U-Boot again, e.g. to download a kernel/initramfs....

Right - I think SDP is a nice solution, and thanks for your effort !

> 
>>> The initial SDP implementation (patch 2) requires the payload to
>>> have the imx specific headers (hence the move of the imx header
>>> file in patch 1).
>>>
>>> Patch 3 extends image header support beyond the SDP specification,
>>> specifically implements also support for U-Boot headers. This
>>> allows to use the same SPL/U-Boot binaries for recovery as used on
>>> the regular boot device (SD/eMMC). For that to work also the host
>>> side imx_usb tools needed an extension, currently available here:
>>>
>>> https://github.com/toradex/imx_loader/tree/imx_usb_batch_mode_refactored
>>>
>>> The full patchset allows to download SPL and U-Boot over USB to a
>>> target in recovery mode using the same usb_imx utility:
>>
>> imx_usb?
>>
> 
> Yeah right, sorry.

But what about to merge into the official imx_usb repo ?

> 
>>> The usb_imx utility also has a batch mode which allows to download
>>> multiple artifacts with a single invocation. The details are
>>> outlined in the imx_usb commit message:
>>> https://github.com/toradex/imx_loader/commit/5434415d921f1cc4d22332d9558bed6d42db9f60
>>>
>>> In case this patchset gets accepted in U-Boot, I plan to push the
>>> imx_usb changes upstream as well.
>>>
>>
>> Do you have numbers for how much code/data size this adds to SPL?
>>
> 
> Besides the protocol implementation also general USB (gadget) support is
> required, hence it adds quite a bit.
> 
> 
> Without USB Gadget/SDP support (Apalis iMX6 SPL):
> 
> $ arm-linux-gnueabihf-size spl/u-boot-spl
>    text    data     bss     dec     hex filename
>   24552    3808      92   28452    6f24 spl/u-boot-spl
> 
> 
> With USB Gadget/SDP support:
> 
> $ arm-linux-gnueabihf-size spl/u-boot-spl
>    text    data     bss     dec     hex filename
>   42549    4679    1984   49212    c03c spl/u-boot-spl


mmmhhh...ok, I see.

> 
> 
>> I believe some i.MX users have struggled to stay within the
>> size of internal RAM.
> 
> Hm, I think the limit is somewhere around 64kiB? In our case we are
> still well below...

I will try to build. The issue is with MX6 Solo (and some lower level
MX6) because it has 64KB IRAM and due to BootROM Stack the maximum size
for SPL is lower (maybe 48K ?). As far as I see, apalis is MX6Q or MX6D,
in both cases no problem. If the size is too big for Solo, we will have
to limit SDP's usage to the SOCs with more IRAM (Dual / Quad/ QP..)

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================