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