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.ag...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot