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

[Marcel Ziswiler <marcel.ziswiler@toradex.com>]

Hi Stefano

On Tue, 2017-08-08 at 11:15 +0200, 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@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#2982
> > > 66
> > > 
> > 
> > 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_r
> > > > efactored
> > > > 
> > > > 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 ?

Yes, of course as Stefan mentioned before that is planned once this
made it into U-Boot proper.

> > > > 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/5434415d921f1cc4d2
> > > > 2332d9558bed6d42db9f60
> > > > 
> > > > 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,

We of course also have our Colibri iMX6 with both Solo and DualLite
options:

https://www.toradex.com/computer-on-modules/colibri-arm-family/nxp-free
scale-imx6#module_features

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

No, it really works fine for us across all i.MX 6 variants.

> Best regards,
> Stefano

Cheers

Marcel