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 <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?
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
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
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 think these numbers will be a problem for some use cases.
Someone on the list (Tim Harvey perhaps?) has been struggling to keep a
unified U-Boot under the IRAM limit and would need to choose between
supporting lots of different hardware and boot options and using SPL
with SDP.
Regards,
Eric
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
