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

Tue Aug 8 17:35:48 UTC 2017

On 2017-08-08 02:15, Stefano Babic wrote:
> 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.
> 

Yeah, I really wish NXP would add some functionality and document the
boot ROM clearly.

One issue I have currently is when the SPL gets downloaded via USB
serial download when the SoC entered serial download due to unbootable
device, spl_boot_mode cannot detect that.

Downstream uses "circumstantial evidence" to get this info:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/arch/arm/include/asm/arch-mx7/imx-regs.h?h=imx_v2016.03_4.1.15_2.0.0_ga#n1204

And I just learned that i.MX 7 Boot ROM actually provides a structure
with boot info now, see get_boot_device in arch/arm/mach-imx/mx7/soc.c.

If anybody has a reliable/nicer mechanism than the is_boot_from_usb from
downstream for i.MX 6 that I am all ears.

>>
>> 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 ?
> 

FWIW, many preparation patches actually already made it upstream:
https://github.com/boundarydevices/imx_usb_loader/pull/48

The pending patches are the changes which only make sense in case
upstream U-Boot gains support for this (e.g. U-Boot header support for
imx_usb).

It probably makes sense for reviewers/testers to look at those patches
too.

Especially the batch mode:
https://github.com/toradex/imx_loader/commit/5434415d921f1cc4d22332d9558bed6d42db9f60

I was going to create the pull request after the U-Boot part gets
merged, but if preferred, I can create a pull request immediately so
people can review it over at Github?

>>
>>>> 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..)

As Marcel mentioned, we successfully run it on Solo/DualLite too.

Boot ROM stack? Since it is not running as plugin, can we not just trash
that?

--
Stefan