Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support
Hi Stefan, On 08/07/2017 11:06 AM, 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 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? That's right. I believe that the trouble is in the return-to-ROM process. I hacked together a form of "setjmp/longjmp" to try and get it to work, but wasn't successful and the documentation for the entry points had me confused. 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). Hmm. That doesn't seem to match the existing code in the NXP U-Boot. 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. I think the documentation is just misleading, as NXP is using SPL to load the payload in stages. The ROM is loading the portion that goes into RAM after executing the plugin to initialize the DDR controller (and PMIC if needed). Afact this is not really helpful in our case. We would want the boot ROM to go through the boot sequence (again). Not the full boot sequence. We'd just want it to load the rest of the image into external RAM. Unless returning an error/invalid image causes the boot ROM to go through boot sequence again? I'm not clear on how errors are handled. 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 There are lots of nice things about having SDP implemented in open-source "C" code and I'm inclined to give up on worrying about "plugin" mode, at least for now. My primary rationale for trying to get plugins to work was to prevent the need to have a "full" U-Boot for initial programming of eMMC. There is one other use case for plugins though, and that's the "resume from LPSR" on i.MX7. In this case, RAM already has a running kernel loaded, but the LPDDR is in self-refresh and something needs to detect that during boot and return after restoring the DDR registers. 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. 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 textdata bss dec hex filename 245523808 92 284526f24 spl/u-boot-spl With USB Gadget/SDP support: $ arm-linux-gnueabihf-size spl/u-boot-spl textdata bss dec he
Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support
Hi Stefan, From: Stefan Agner 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). If I might ask - could you prepare some ./doc/README.sdp entry for v2? I mean some kind of howto for using this feature? Nothing long - just the most important commands (imx_usb?) including the list of supported (and not) features. 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 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: 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. Thanks for the patch set. It would definitely facilitate work with IMX SoCs. Stefan Agner (7): imx: move imximage header to common location usb: gadget: add SDP driver usb: gadget: sdp: extend images compatible for jumps cmd: add sdp command spl: add serial download protocol (SDP) support apalis/colibri_imx6: use independent USB PID for SPL apalis/colibri_imx6: enable SDP by default board/toradex/apalis_imx6/apalis_imx6.c | 13 + board/toradex/colibri_imx6/colibri_imx6.c | 13 + cmd/Kconfig | 7 + cmd/Makefile | 1 + cmd/usb_gadget_sdp.c | 53 +++ common/spl/Kconfig| 6 + common/spl/Makefile | 1 + common/spl/spl_sdp.c | 38 ++ configs/apalis_imx6_defconfig | 4 + configs/colibri_imx6_defconfig| 4 + drivers/usb/gadget/Kconfig| 7 + drivers/usb/gadget/Makefile | 2 + drivers/usb/gadget/f_sdp.c| 739 ++ {tools => include}/imximage.h | 0 include/sdp.h | 16 + 15 files changed, 904 insertions(+) create mode 100644 cmd/usb_gadget_sdp.c create mode 100644 common/spl/spl_sdp.c create mode 100644 drivers/usb/gadget/f_sdp.c rename {tools => include}/imximage.h (100%) create mode 100644 include/sdp.h -- Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support
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 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/5434415d921f1cc4d22332d9558bed6d
Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support
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 > > > > > > > > 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
Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support
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 >>> >>> 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 >textdata bss dec hex filename > 245523808 92 284526f24 spl/u-boot-spl > > > With USB Gadget/SDP support: > > $ arm-linux-gnueabihf-size spl/u-boot-spl >textdata bss dec hex filename > 4254946791984 49212c03c 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
Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support
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 >> >> 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. Afact this is not really helpful in our case. We would want the boot ROM to go through the boot sequence (again). 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 >> 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. >> 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 textdata bss dec hex filename 245523808 92 284526f24 spl/u-boot-spl With USB Gadget/SDP support: $ arm-linux-gnueabihf-size spl/u-boot-spl textdata bss dec hex filename 4254946791984 49212c03c spl/u-boot-spl > 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... -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/7] imx: add USB Serial Download Protocol (SDP) support
Hi Stefan, On 08/04/2017 04:38 PM, Stefan Agner wrote: From: Stefan Agner 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 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? 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? I believe some i.MX users have struggled to stay within the size of internal RAM. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot