[U-Boot] Booting Wandboard through USB

[U-Boot] Booting Wandboard through USB

[Vincent Stehlé]

Hi,

Is it still possible to boot u-boot on Wandboard through USB, please?

U-boot has switched to SPL for Wandboard recently[1] and I wonder if it
did not lose the possibility to boot the Wandboard through USB in the
mean time.

Granted, I can generate an u-boot-with-spl.imx suitable for boot through
USB, with tools such as imx_usb_loader[2], but I am not able to compile
SPL with usb or ethernet support. Is loading the second stage image from
SD card the only way now?

Thanks for any advice.

Best regards,

V.

[1] Commit 0d1ea05210f3 ("wandboard: Switch to SPL support")
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/220799

[2] https://github.com/boundarydevices/imx_usb_loader

[U-Boot] Booting Wandboard through USB

[Tom Rini]

On Fri, May 29, 2015 at 11:46:40AM +0200, Vincent Stehl? wrote:

> Hi,
> 
> Is it still possible to boot u-boot on Wandboard through USB, please?

Not directly.  I've been toying with a few ideas but not put any into
practice yet.  The first and possibly simplist would be to mimic the USB
RNDIS in SPL support am335x uses (see am335x_evm_usbspl_defconfig) but I
don't know if we have space for that.  The second would be trying to
"fake" things such that for imx_usb_loader you can pass both SPL and
u-boot.img, and SPL is run, inits memory and just exists and then
u-boot.img is loaded and run, similar to how with the non-SPL case you
can use the loader to pass in u-boot.imx as well as a kernel, ramdisk,
etc, into DDR.

Proof of concepts, patches or just plain old feedback greatly
appreciated!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150530/49ed93ad/attachment.sig>

[U-Boot] Booting Wandboard through USB

[Vincent Stehlé]

On 05/30/2015 06:49 PM, Tom Rini wrote:
..
> The second would be trying to "fake" things such that for 
> imx_usb_loader you can pass both SPL and u-boot.img, and SPL is 
> run, inits memory and just exists and then u-boot.img is loaded
> and run, similar to how with the non-SPL case you can use the
> loader to pass in u-boot.imx as well as a kernel, ramdisk, etc,
> into DDR.

I wonder if we could use the i.MX6 ROM "plugin"[1] mechanism with u-boot
SPL, to download it through USB, have it configure the DDR and return to
the ROM, in a way that would allow us to resume downloading the second
stage u-boot through USB...

Best regards,

V.

[1] Chapter "8.8 Plugin Image" of the i.MX6D/Q Reference Manual.

[U-Boot] Booting Wandboard through USB

[Eric Nelson]

On 05/30/2015 10:24 AM, Vincent Stehl? wrote:
> On 05/30/2015 06:49 PM, Tom Rini wrote:
> ..
>> The second would be trying to "fake" things such that for 
>> imx_usb_loader you can pass both SPL and u-boot.img, and SPL is 
>> run, inits memory and just exists and then u-boot.img is loaded
>> and run, similar to how with the non-SPL case you can use the
>> loader to pass in u-boot.imx as well as a kernel, ramdisk, etc,
>> into DDR.
> 
> I wonder if we could use the i.MX6 ROM "plugin"[1] mechanism with u-boot
> SPL, to download it through USB, have it configure the DDR and return to
> the ROM, in a way that would allow us to resume downloading the second
> stage u-boot through USB...
> 
> Best regards,
> 
> V.
> 
> [1] Chapter "8.8 Plugin Image" of the i.MX6D/Q Reference Manual.

;) This is an even older idea:
	http://lists.denx.de/pipermail/u-boot/2012-September/thread.html#134444

In my earlier e-mail, I said that this was more complicated because
it involves hacking the image creation process (and perhaps some
linker scripts).

It also requires that SPL images have some form of flag telling them
not to boot, but return to the ROM boot loader after initializing DDR
(i.e. they need to optionally act like a plugin).

Regards,


Eric

[U-Boot] Booting Wandboard through USB

[Tom Rini]

On Sat, May 30, 2015 at 01:09:48PM -0700, Eric Nelson wrote:
> On 05/30/2015 10:24 AM, Vincent Stehl? wrote:
> > On 05/30/2015 06:49 PM, Tom Rini wrote:
> > ..
> >> The second would be trying to "fake" things such that for 
> >> imx_usb_loader you can pass both SPL and u-boot.img, and SPL is 
> >> run, inits memory and just exists and then u-boot.img is loaded
> >> and run, similar to how with the non-SPL case you can use the
> >> loader to pass in u-boot.imx as well as a kernel, ramdisk, etc,
> >> into DDR.
> > 
> > I wonder if we could use the i.MX6 ROM "plugin"[1] mechanism with u-boot
> > SPL, to download it through USB, have it configure the DDR and return to
> > the ROM, in a way that would allow us to resume downloading the second
> > stage u-boot through USB...
> > 
> > Best regards,
> > 
> > V.
> > 
> > [1] Chapter "8.8 Plugin Image" of the i.MX6D/Q Reference Manual.
> 
> ;) This is an even older idea:
> 	http://lists.denx.de/pipermail/u-boot/2012-September/thread.html#134444
> 
> In my earlier e-mail, I said that this was more complicated because
> it involves hacking the image creation process (and perhaps some
> linker scripts).
> 
> It also requires that SPL images have some form of flag telling them
> not to boot, but return to the ROM boot loader after initializing DDR
> (i.e. they need to optionally act like a plugin).

Well there is precendce these days for doing special things to cooperate
with ROM, we do something not totally dissimilar for sunxi I believe, in
some cases.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150530/18350402/attachment.sig>

[U-Boot] Booting Wandboard through USB

[Nikolay Dimitrov]

Hi all,

On 05/30/2015 11:09 PM, Eric Nelson wrote:
> On 05/30/2015 10:24 AM, Vincent Stehl? wrote:
>> On 05/30/2015 06:49 PM, Tom Rini wrote:
>> ..
>>> The second would be trying to "fake" things such that for
>>> imx_usb_loader you can pass both SPL and u-boot.img, and SPL is
>>> run, inits memory and just exists and then u-boot.img is loaded
>>> and run, similar to how with the non-SPL case you can use the
>>> loader to pass in u-boot.imx as well as a kernel, ramdisk, etc,
>>> into DDR.
>>
>> I wonder if we could use the i.MX6 ROM "plugin"[1] mechanism with u-boot
>> SPL, to download it through USB, have it configure the DDR and return to
>> the ROM, in a way that would allow us to resume downloading the second
>> stage u-boot through USB...
>>
>> Best regards,
>>
>> V.
>>
>> [1] Chapter "8.8 Plugin Image" of the i.MX6D/Q Reference Manual.
>
> ;) This is an even older idea:
> 	http://lists.denx.de/pipermail/u-boot/2012-September/thread.html#134444
>
> In my earlier e-mail, I said that this was more complicated because
> it involves hacking the image creation process (and perhaps some
> linker scripts).
>
> It also requires that SPL images have some form of flag telling them
> not to boot, but return to the ROM boot loader after initializing DDR
> (i.e. they need to optionally act like a plugin).

According to the RM, the plugin image is expected to load the actual
boot image in memory and report the start/len/ivt parameters to the
boot ROM. Then I see 2 problems:

1. It seems that at this exact point if the plugin returned "success"
the boot ROM will start executing the downloaded image and there's no
intent to download anything else from USB.

2. Even if there was a way for the boot ROM to download more data, the
previous communication sequence ends with "jump header" (in imx-usb-
loader jargon) which means we can't differentiate between boot ROM
returning for more boot data, and a fresh new boot session.

Regards,
Nikolay

[U-Boot] Booting Wandboard through USB

[Nikolay Dimitrov]

Hi guys,

Here's a proposal how to avoid changing the host boot software for the
SPL case:

- Power on
- Boot ROM announces usb device (0x15a2:0x0054 or 0x15a2:0x0054 or
0x15a2:0x0063)
- Host software uploads SPL over OTG
- Board initializes DDR
- Board initializes USB-OTG and announces again as a usb device with
slightly different PID (0x15a2:0x0055 or 0x15a2:0x0056 or
0x15a2:0x0064) or a special PID (0x15a2:0xffff), thus needs to
implement FSL boot protocol
- Both imx-usb-loader and mfgtool already have easy mechanism to detect
boards' by vid-pid and to sequence actions based on it. So basically
we'll just need an additional config for the host boot programs, which
need to feed the 2nd boot stage (one more file for imx-usb-loader, and
one more config section for the mfgtool), but otherwise it will be
quite straight-forward.

Overall, from the PC host this boot sequence will look like 2 boot
sequences for 2 separate usb devices (1 for SPL, 1 for u-boot.img).

Probably the most important question is "how easy is to implement the
FSL boot protocol in the remaining OCRAM free space". What do you think?

Regards,
Nikolay

[U-Boot] Booting Wandboard through USB

[Stefano Babic]

Hi Nikolay,

(jumping a little later in the discussion but trying to sumarize all
topics..)

IMHO we should find a way without constraining SPL to work differently
as thought only to allow loading from USB. For this reason I will tend
to a solution as much as possible "tools" only, that is extending
imx-usb-loader as try to bind together SPL and u-boot.bin and convince
SPL to load from memory. This becomes an artifact, because in the
reality, SPL loads from a storage.

On 01/06/2015 01:15, Nikolay Dimitrov wrote:
> Hi guys,
> 
> Here's a proposal how to avoid changing the host boot software for the
> SPL case:
> 
> - Power on
> - Boot ROM announces usb device (0x15a2:0x0054 or 0x15a2:0x0054 or
> 0x15a2:0x0063)
> - Host software uploads SPL over OTG
> - Board initializes DDR
> - Board initializes USB-OTG and announces again as a usb device with
> slightly different PID (0x15a2:0x0055 or 0x15a2:0x0056 or
> 0x15a2:0x0064) or a special PID (0x15a2:0xffff), thus needs to
> implement FSL boot protocol

It looks like a straightforward solution. I guess that the USB-OTG
initialization is done as fallback when SPL cannot load from storage,
allowing us to have a single binary for "standard" booting and USB
booting. When load fails, USB is initialized.

> - Both imx-usb-loader and mfgtool already have easy mechanism to detect
> boards' by vid-pid and to sequence actions based on it. So basically
> we'll just need an additional config for the host boot programs, which
> need to feed the 2nd boot stage (one more file for imx-usb-loader, and
> one more config section for the mfgtool), but otherwise it will be
> quite straight-forward.

Agree, this looks like a straight-forward solution.

> 
> Overall, from the PC host this boot sequence will look like 2 boot
> sequences for 2 separate usb devices (1 for SPL, 1 for u-boot.img).
> 
> Probably the most important question is "how easy is to implement the
> FSL boot protocol in the remaining OCRAM free space". What do you think?
> 


Best regards,
Stefano Babic


-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] Booting Wandboard through USB

[Tim Harvey]

On Mon, Jun 1, 2015 at 1:10 AM, Stefano Babic <sbabic@denx.de> wrote:
> Hi Nikolay,
>
> (jumping a little later in the discussion but trying to sumarize all
> topics..)
>
> IMHO we should find a way without constraining SPL to work differently
> as thought only to allow loading from USB. For this reason I will tend
> to a solution as much as possible "tools" only, that is extending
> imx-usb-loader as try to bind together SPL and u-boot.bin and convince
> SPL to load from memory. This becomes an artifact, because in the
> reality, SPL loads from a storage.
>
> On 01/06/2015 01:15, Nikolay Dimitrov wrote:
>> Hi guys,
>>
>> Here's a proposal how to avoid changing the host boot software for the
>> SPL case:
>>
>> - Power on
>> - Boot ROM announces usb device (0x15a2:0x0054 or 0x15a2:0x0054 or
>> 0x15a2:0x0063)
>> - Host software uploads SPL over OTG
>> - Board initializes DDR
>> - Board initializes USB-OTG and announces again as a usb device with
>> slightly different PID (0x15a2:0x0055 or 0x15a2:0x0056 or
>> 0x15a2:0x0064) or a special PID (0x15a2:0xffff), thus needs to
>> implement FSL boot protocol
>
> It looks like a straightforward solution. I guess that the USB-OTG
> initialization is done as fallback when SPL cannot load from storage,
> allowing us to have a single binary for "standard" booting and USB
> booting. When load fails, USB is initialized.
>
>> - Both imx-usb-loader and mfgtool already have easy mechanism to detect
>> boards' by vid-pid and to sequence actions based on it. So basically
>> we'll just need an additional config for the host boot programs, which
>> need to feed the 2nd boot stage (one more file for imx-usb-loader, and
>> one more config section for the mfgtool), but otherwise it will be
>> quite straight-forward.
>
> Agree, this looks like a straight-forward solution.
>
>>
>> Overall, from the PC host this boot sequence will look like 2 boot
>> sequences for 2 separate usb devices (1 for SPL, 1 for u-boot.img).
>>
>> Probably the most important question is "how easy is to implement the
>> FSL boot protocol in the remaining OCRAM free space". What do you think?
>>
>
>
> Best regards,
> Stefano Babic
>

Glad to see this thread - I've been wanting to revive a 'boot over
OTG' method ever since I switched Ventana to use SPL. Here are my
thoughts on various comments in this thread:

I like Nikolay's approach as well. As I look into adding more
boot-device support into the SPL (in a single image - I hate having to
support multiple SPL's) I find that I'm out of space and trying to
cram something like DFU support into the SPL just doesn't make sense
to me vs the idea of putting more smarts into the host tools like
imx_usb_loader. I don't agree with the idea of trying to stuff DFU
support into the SPL - I'm already fighting for space in the SPL with
just supporting NAND/MMC/env in a single image for Falcon mode.

I see the benefit of the concept of OTG->(something)->DFU but I think
perhaps that 'something' should be SPL+U-Boot as U-Boot already has a
ton of support and I hate to see us trying to replicate 'everything'
in the SPL.

Tim

[U-Boot] Booting Wandboard through USB

[Nikolay Dimitrov]

Hi Tim,

On 06/01/2015 07:03 PM, Tim Harvey wrote:
> On Mon, Jun 1, 2015 at 1:10 AM, Stefano Babic <sbabic@denx.de> wrote:
>> Hi Nikolay,
>>
>> (jumping a little later in the discussion but trying to sumarize all
>> topics..)
>>
>> IMHO we should find a way without constraining SPL to work differently
>> as thought only to allow loading from USB. For this reason I will tend
>> to a solution as much as possible "tools" only, that is extending
>> imx-usb-loader as try to bind together SPL and u-boot.bin and convince
>> SPL to load from memory. This becomes an artifact, because in the
>> reality, SPL loads from a storage.
>>
>> On 01/06/2015 01:15, Nikolay Dimitrov wrote:
>>> Hi guys,
>>>
>>> Here's a proposal how to avoid changing the host boot software for the
>>> SPL case:
>>>
>>> - Power on
>>> - Boot ROM announces usb device (0x15a2:0x0054 or 0x15a2:0x0054 or
>>> 0x15a2:0x0063)
>>> - Host software uploads SPL over OTG
>>> - Board initializes DDR
>>> - Board initializes USB-OTG and announces again as a usb device with
>>> slightly different PID (0x15a2:0x0055 or 0x15a2:0x0056 or
>>> 0x15a2:0x0064) or a special PID (0x15a2:0xffff), thus needs to
>>> implement FSL boot protocol
>>
>> It looks like a straightforward solution. I guess that the USB-OTG
>> initialization is done as fallback when SPL cannot load from storage,
>> allowing us to have a single binary for "standard" booting and USB
>> booting. When load fails, USB is initialized.
>>
>>> - Both imx-usb-loader and mfgtool already have easy mechanism to detect
>>> boards' by vid-pid and to sequence actions based on it. So basically
>>> we'll just need an additional config for the host boot programs, which
>>> need to feed the 2nd boot stage (one more file for imx-usb-loader, and
>>> one more config section for the mfgtool), but otherwise it will be
>>> quite straight-forward.
>>
>> Agree, this looks like a straight-forward solution.
>>
>>>
>>> Overall, from the PC host this boot sequence will look like 2 boot
>>> sequences for 2 separate usb devices (1 for SPL, 1 for u-boot.img).
>>>
>>> Probably the most important question is "how easy is to implement the
>>> FSL boot protocol in the remaining OCRAM free space". What do you think?
>>>
>>
>>
>> Best regards,
>> Stefano Babic
>>
>
> Glad to see this thread - I've been wanting to revive a 'boot over
> OTG' method ever since I switched Ventana to use SPL. Here are my
> thoughts on various comments in this thread:

My personal expectations are that OTG is needed for 2 typical use cases 
- faster SW development and automated testing. Does your needs fall into 
these 2 or it's something different?

> I like Nikolay's approach as well. As I look into adding more
> boot-device support into the SPL (in a single image - I hate having to
> support multiple SPL's) I find that I'm out of space and trying to
> cram something like DFU support into the SPL just doesn't make sense
> to me vs the idea of putting more smarts into the host tools like
> imx_usb_loader. I don't agree with the idea of trying to stuff DFU
> support into the SPL - I'm already fighting for space in the SPL with
> just supporting NAND/MMC/env in a single image for Falcon mode.
>
> I see the benefit of the concept of OTG->(something)->DFU but I think
> perhaps that 'something' should be SPL+U-Boot as U-Boot already has a
> ton of support and I hate to see us trying to replicate 'everything'
> in the SPL.

My only real concern is divorcing from MFGtool without a real
alternative for Windows hosts. I've been in situations where the
customer's factory/service personnel is just competent enough to work
with the Windows-based MFGtool and anything else (imx-usb-loader) would
be a disaster in terms of support efforts.

So, if there's a possibility to (natively) run imx-usb-loader on
Windows and to have a nice big "FLASH" button there, together with
pass/fail counters, that would allow much more freedom of choosing how
SPL can download the next boot stage :D.

Regards,
Nikolay

[U-Boot] Booting Wandboard through USB

[Tim Harvey]

On Mon, Jun 1, 2015 at 9:28 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Hi Tim,
>
>
> On 06/01/2015 07:03 PM, Tim Harvey wrote:
>>
>> On Mon, Jun 1, 2015 at 1:10 AM, Stefano Babic <sbabic@denx.de> wrote:
>>>
>>> Hi Nikolay,
>>>
>>> (jumping a little later in the discussion but trying to sumarize all
>>> topics..)
>>>
>>> IMHO we should find a way without constraining SPL to work differently
>>> as thought only to allow loading from USB. For this reason I will tend
>>> to a solution as much as possible "tools" only, that is extending
>>> imx-usb-loader as try to bind together SPL and u-boot.bin and convince
>>> SPL to load from memory. This becomes an artifact, because in the
>>> reality, SPL loads from a storage.
>>>
>>> On 01/06/2015 01:15, Nikolay Dimitrov wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> Here's a proposal how to avoid changing the host boot software for the
>>>> SPL case:
>>>>
>>>> - Power on
>>>> - Boot ROM announces usb device (0x15a2:0x0054 or 0x15a2:0x0054 or
>>>> 0x15a2:0x0063)
>>>> - Host software uploads SPL over OTG
>>>> - Board initializes DDR
>>>> - Board initializes USB-OTG and announces again as a usb device with
>>>> slightly different PID (0x15a2:0x0055 or 0x15a2:0x0056 or
>>>> 0x15a2:0x0064) or a special PID (0x15a2:0xffff), thus needs to
>>>> implement FSL boot protocol
>>>
>>>
>>> It looks like a straightforward solution. I guess that the USB-OTG
>>> initialization is done as fallback when SPL cannot load from storage,
>>> allowing us to have a single binary for "standard" booting and USB
>>> booting. When load fails, USB is initialized.
>>>
>>>> - Both imx-usb-loader and mfgtool already have easy mechanism to detect
>>>> boards' by vid-pid and to sequence actions based on it. So basically
>>>> we'll just need an additional config for the host boot programs, which
>>>> need to feed the 2nd boot stage (one more file for imx-usb-loader, and
>>>> one more config section for the mfgtool), but otherwise it will be
>>>> quite straight-forward.
>>>
>>>
>>> Agree, this looks like a straight-forward solution.
>>>
>>>>
>>>> Overall, from the PC host this boot sequence will look like 2 boot
>>>> sequences for 2 separate usb devices (1 for SPL, 1 for u-boot.img).
>>>>
>>>> Probably the most important question is "how easy is to implement the
>>>> FSL boot protocol in the remaining OCRAM free space". What do you think?
>>>>
>>>
>>>
>>> Best regards,
>>> Stefano Babic
>>>
>>
>> Glad to see this thread - I've been wanting to revive a 'boot over
>> OTG' method ever since I switched Ventana to use SPL. Here are my
>> thoughts on various comments in this thread:
>
>
> My personal expectations are that OTG is needed for 2 typical use cases -
> faster SW development and automated testing. Does your needs fall into these
> 2 or it's something different?
>
>> I like Nikolay's approach as well. As I look into adding more
>> boot-device support into the SPL (in a single image - I hate having to
>> support multiple SPL's) I find that I'm out of space and trying to
>> cram something like DFU support into the SPL just doesn't make sense
>> to me vs the idea of putting more smarts into the host tools like
>> imx_usb_loader. I don't agree with the idea of trying to stuff DFU
>> support into the SPL - I'm already fighting for space in the SPL with
>> just supporting NAND/MMC/env in a single image for Falcon mode.
>>
>> I see the benefit of the concept of OTG->(something)->DFU but I think
>> perhaps that 'something' should be SPL+U-Boot as U-Boot already has a
>> ton of support and I hate to see us trying to replicate 'everything'
>> in the SPL.
>
>
> My only real concern is divorcing from MFGtool without a real
> alternative for Windows hosts. I've been in situations where the
> customer's factory/service personnel is just competent enough to work
> with the Windows-based MFGtool and anything else (imx-usb-loader) would
> be a disaster in terms of support efforts.
>
> So, if there's a possibility to (natively) run imx-usb-loader on
> Windows and to have a nice big "FLASH" button there, together with
> pass/fail counters, that would allow much more freedom of choosing how
> SPL can download the next boot stage :D.
>
> Regards,
> Nikolay

I wouldn't be so concerned.... just give them a linux box or VM with a
shellscript wrapped with zenity to provide a big 'FLASH' button ;)

Honestly I've never used fsl's mfgtool and never want to. I think its
way more complicated than a scrip-table linux solution with very few
dependencies (imx_usb_loader) and IMHO I think we should not be
encumbered with fitting that complicated mould but instead work on
breaking it by providing better options.

Tim

[U-Boot] Booting Wandboard through USB

[Tom Rini]

On Mon, Jun 01, 2015 at 09:38:18AM -0700, Tim Harvey wrote:
[snip]
> Honestly I've never used fsl's mfgtool and never want to. I think its
> way more complicated than a scrip-table linux solution with very few
> dependencies (imx_usb_loader) and IMHO I think we should not be
> encumbered with fitting that complicated mould but instead work on
> breaking it by providing better options.

The counter-point that we can't just dismiss is that we want companies
on mainline.  Today many use the Freescale mfgtool (which is a big
wrapper around shoving u-boot.imx over and booting a kernel + ramdisk
into Linux and then flashing the board.  A solution that continues to
work within this framework removes a barrier from getting them on
mainline (and from Freescale shipping a more recent version of U-Boot
with their refernce SW).

Thinking about this a bit, as near as I can tell the way the mfgtool
(and for that matter, imx_usb_loader when passing in multiple files)
works is to use the header of u-boot.imx (or whatever...) to initialize
DDR, then start taking files and putting them in.  Could we not add some
debug (or opt-in CONFIG statement) that would cause SPL to spit out in
essence the values to plug into a template for header-based DDR init?
That way the mfgtool itself will continue working and instead of being
told to use u-boot.imx it's given a script (which iirc it supports) and
u-boot.img to run and it's normal loads of everything to flash.  Roughly
speaking :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150602/efbc01d4/attachment.sig>

[U-Boot] Booting Wandboard through USB

[Tim Harvey]

On Tue, Jun 2, 2015 at 7:25 AM, Tom Rini <trini@konsulko.com> wrote:
> On Mon, Jun 01, 2015 at 09:38:18AM -0700, Tim Harvey wrote:
> [snip]
>> Honestly I've never used fsl's mfgtool and never want to. I think its
>> way more complicated than a scrip-table linux solution with very few
>> dependencies (imx_usb_loader) and IMHO I think we should not be
>> encumbered with fitting that complicated mould but instead work on
>> breaking it by providing better options.
>
> The counter-point that we can't just dismiss is that we want companies
> on mainline.  Today many use the Freescale mfgtool (which is a big
> wrapper around shoving u-boot.imx over and booting a kernel + ramdisk
> into Linux and then flashing the board.  A solution that continues to
> work within this framework removes a barrier from getting them on
> mainline (and from Freescale shipping a more recent version of U-Boot
> with their refernce SW).

mfgtool is a big 'windows' wrapper around shoving a u-boot.imx over
USB OTG and scripting through serial port to do 'whatever else' is
needed. While fsl may be getting close to mainline that doesn't mean
they are using SPL and thats the difference here.

>
> Thinking about this a bit, as near as I can tell the way the mfgtool
> (and for that matter, imx_usb_loader when passing in multiple files)
> works is to use the header of u-boot.imx (or whatever...) to initialize
> DDR, then start taking files and putting them in.  Could we not add some
> debug (or opt-in CONFIG statement) that would cause SPL to spit out in
> essence the values to plug into a template for header-based DDR init?
> That way the mfgtool itself will continue working and instead of being
> told to use u-boot.imx it's given a script (which iirc it supports) and
> u-boot.img to run and it's normal loads of everything to flash.  Roughly
> speaking :)
>
> --
> Tom

mfgmode uses a windows exe that takes a *.imx which has a DCD table
and sets the regs defined in the DCD table - so it relies on the
non-SPL way of doing things where the MMDC configuration is hard-coded
in the DCD, thus every combination of SoC 'type'
(IMX6DQ|IMX6SDL|IMX6SX) and memory configuration
(chip+width+calib-for-pcb+size) requires a different DCD thus *.imx.

To my knowledge fsl has not 'embraced the SPL' and is still relying on
custom DCD's in the bootloader (someone please correct me if I'm out
of date here). That thought works just fine for customers in large
vertical markets with one or two configs but is very inflexible for
those of us that vary the parameters quite a bit.

The imx_usb_loader works off the assumption that you have a DCD (which
is just a table of register addr's and values) and that the DCD
configures the MMDC properly for your target, so that it can then load
1 or more blobs into DRAM. In our case what we are wanting to do is
let the SPL configure the MMDC then use the SPL to allow a raw DRAM
load option over OTG. I don't see any other way to do it other than
Nikolay's idea which should not be that difficult to implement. I
don't know enough about mfgtool to know how flexible it is. Can you
build imx_usb_loader for windows and choose to use an 'enhanced one'
vs the closed-source one distributed with mfgtool and thus continue to
use the config/scripting portion of the mfgtool package?

It 'could' be possible to make the SPL output all its register writes
I suppose through some wrappers around writel (I've actually done this
in the past to troubleshoot things) to re-create a DCD but I'm not
sure I see the point in where we go from there as you would also need
the SPL to not re-configure the MMDC and not clobber memory.... so
essentially your no longer using the SPL.

If someone wants to use mfgtool they can go down the path of non-SPL
U-Boot's and be fine. If someone wants to use SPL why can't we provide
a better/different approach? Perhaps fsl can release the source for
mfgtools windows cmdline app so that it can be enahnced to support
this as well.

I've run into a similar issue with fsl's 'ddr calibration and stress
test tool' because I think it uses the same approach to mfgtool (it
may even use the same windows exe). The windows tool loads their
stand-alone bare-metal blob (has a DCD so equiv to an *.imx) over OTG
then the bare-metal app immediately implements a USB HID-generic
gadget over OTG and communicates to the windows app that way
(basically serial-console over USB at that point). Now, if you are
able to get the source for the ddr calibration and stress test tool
from fsl (not too hard) you can build it in a way that it doesn't have
the DCD and doesn't use the USB OTG HID-generic gadget as a serial
console and then load it via U-Boot or JTAG (of course in that mode
U-Boot or JTAG needs to be doing what the DCD did to configure the
MMDC so you can run into a catch-22 scenario if your trying to use the
tool to obtain those DDC values). When you get the source for this
tool, its just the source for the bare-metal app not the Windows exe
that is used with it. The only reason you would need the source is if
you needed to boot it in the non-OTG mode with your own UART pinmux
etc.

Tim

[U-Boot] Booting Wandboard through USB

[Nikolay Dimitrov]

Hi Stefano,

On 06/01/2015 11:10 AM, Stefano Babic wrote:
> Hi Nikolay,
>
> (jumping a little later in the discussion but trying to sumarize all
> topics..)

Np, you're welcome.

> IMHO we should find a way without constraining SPL to work differently
> as thought only to allow loading from USB. For this reason I will tend
> to a solution as much as possible "tools" only, that is extending
> imx-usb-loader as try to bind together SPL and u-boot.bin and convince
> SPL to load from memory. This becomes an artifact, because in the
> reality, SPL loads from a storage.

Well, there's no need to work differently. There are already config
options that select which interface should be used to load the next
boot stage or OS image:

void board_init_r(gd_t *dummy1, ulong dummy2)
{
...
#ifdef CONFIG_SPL_NOR_SUPPORT
	case BOOT_DEVICE_NOR:
		spl_nor_load_image();
		break;
#endif
...
#ifdef CONFIG_SPL_USB_SUPPORT
	case BOOT_DEVICE_USB:
		spl_usb_load_image();
		break;
#endif
...
}

Also, current SPL loads not only from storage, but also from some
interfaces like serial port, ethernet, usb-eth. We can just add one
more here. To me it looks like a natural extension, thanks to the hard
work done so far on the current code.

> On 01/06/2015 01:15, Nikolay Dimitrov wrote:
>> Hi guys,
>>
>> Here's a proposal how to avoid changing the host boot software for the
>> SPL case:
>>
>> - Power on
>> - Boot ROM announces usb device (0x15a2:0x0054 or 0x15a2:0x0054 or
>> 0x15a2:0x0063)
>> - Host software uploads SPL over OTG
>> - Board initializes DDR
>> - Board initializes USB-OTG and announces again as a usb device with
>> slightly different PID (0x15a2:0x0055 or 0x15a2:0x0056 or
>> 0x15a2:0x0064) or a special PID (0x15a2:0xffff), thus needs to
>> implement FSL boot protocol
>
> It looks like a straightforward solution. I guess that the USB-OTG
> initialization is done as fallback when SPL cannot load from storage,
> allowing us to have a single binary for "standard" booting and USB
> booting. When load fails, USB is initialized.

If you're commenting how the FSL boot ROM works, I doubt that there's a
2nd attempt to load via USB-OTG once the SPL is downloaded, and
regardless of the plugin flag.

If you're commenting about a possible future imx6 SPL implementation in
U-Boot - that would be entirely possible, as long as we fit in OCRAM.

>> - Both imx-usb-loader and mfgtool already have easy mechanism to detect
>> boards' by vid-pid and to sequence actions based on it. So basically
>> we'll just need an additional config for the host boot programs, which
>> need to feed the 2nd boot stage (one more file for imx-usb-loader, and
>> one more config section for the mfgtool), but otherwise it will be
>> quite straight-forward.
>
> Agree, this looks like a straight-forward solution.
>
>>
>> Overall, from the PC host this boot sequence will look like 2 boot
>> sequences for 2 separate usb devices (1 for SPL, 1 for u-boot.img).
>>
>> Probably the most important question is "how easy is to implement the
>> FSL boot protocol in the remaining OCRAM free space". What do you think?

Regards,
Nikolay

[U-Boot] Booting Wandboard through USB

[Eric Nelson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Tom,

On 05/30/2015 09:49 AM, Tom Rini wrote:
> On Fri, May 29, 2015 at 11:46:40AM +0200, Vincent Stehl? wrote:
> 
>> Hi,
>> 
>> Is it still possible to boot u-boot on Wandboard through USB,
>> please?
> 
> Not directly.  I've been toying with a few ideas but not put any
> into practice yet.  The first and possibly simplist would be to
> mimic the USB RNDIS in SPL support am335x uses (see
> am335x_evm_usbspl_defconfig) but I don't know if we have space for
> that.  The second would be trying to "fake" things such that for
> imx_usb_loader you can pass both SPL and u-boot.img, and SPL is
> run, inits memory and just exists and then u-boot.img is loaded and
> run, similar to how with the non-SPL case you can use the loader to
> pass in u-boot.imx as well as a kernel, ramdisk, etc, into DDR.
> 
> Proof of concepts, patches or just plain old feedback greatly 
> appreciated!
> 

This is an old topic and the threading seems to be messed
up in the archive, but I think Michael Trimarchi has a
solution based on inclusion of DFU in the SPL image:

	http://lists.denx.de/pipermail/u-boot/2013-October/165849.html

I would prefer to see something slimmer if possible, and using
imx_usb has the advantage of only needing a single tool on the
programming host.

Regards,


Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVafY8AAoJEFUqXmm9AiVrQEgIAKU/ipaOKVREJ1mLVBk8bBcb
EKY1Pc9AKC58vblsREIksBPNWC1vGAxPH/8langozXyKrHdjtK/iPVd7zicDIEZ3
51l7U+TNzwRNcqS+oyc8uZZSkUu1OtcsJmO0WehX+X19hgoGnu4Pht17R/m0aKxB
M6NQDckDnRFY8KCw34z11Cfq8dVOa2ifmTVZIZVZh3MoHmLFVcZDlxnNCtANKemn
QyXl8NeXTaENgx4yIfY5aVrxg+RU1ouBgf/leDwqOm2Nh8ILiD9bkyrpJPgGF6NG
nwiJj/DlSwub2190PWv0c/XIS+Q9KsGXkbPRCYcINlaiKuksVCeRr+S0VilVUIY=
=G80J
-----END PGP SIGNATURE-----

[U-Boot] Booting Wandboard through USB

[Tom Rini]

On Sat, May 30, 2015 at 10:41:16AM -0700, Eric Nelson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi Tom,
> 
> On 05/30/2015 09:49 AM, Tom Rini wrote:
> > On Fri, May 29, 2015 at 11:46:40AM +0200, Vincent Stehl? wrote:
> > 
> >> Hi,
> >> 
> >> Is it still possible to boot u-boot on Wandboard through USB,
> >> please?
> > 
> > Not directly.  I've been toying with a few ideas but not put any
> > into practice yet.  The first and possibly simplist would be to
> > mimic the USB RNDIS in SPL support am335x uses (see
> > am335x_evm_usbspl_defconfig) but I don't know if we have space for
> > that.  The second would be trying to "fake" things such that for
> > imx_usb_loader you can pass both SPL and u-boot.img, and SPL is
> > run, inits memory and just exists and then u-boot.img is loaded and
> > run, similar to how with the non-SPL case you can use the loader to
> > pass in u-boot.imx as well as a kernel, ramdisk, etc, into DDR.
> > 
> > Proof of concepts, patches or just plain old feedback greatly 
> > appreciated!
> > 
> 
> This is an old topic and the threading seems to be messed
> up in the archive, but I think Michael Trimarchi has a
> solution based on inclusion of DFU in the SPL image:
> 
> 	http://lists.denx.de/pipermail/u-boot/2013-October/165849.html
> 
> I would prefer to see something slimmer if possible, and using
> imx_usb has the advantage of only needing a single tool on the
> programming host.

Ah yes, firing up and letting DFU do the rest is another option I had
forgotten about.  But I too lean towards something imx_usb can do as
that will also make integration into the Freescale factory flashing tool
easier I suspect.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150530/581965ae/attachment.sig>

[U-Boot] Booting Wandboard through USB

[Eric Nelson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Tom,

On 05/30/2015 12:25 PM, Tom Rini wrote:
> On Sat, May 30, 2015 at 10:41:16AM -0700, Eric Nelson wrote:
>> On 05/30/2015 09:49 AM, Tom Rini wrote:
>>> On Fri, May 29, 2015 at 11:46:40AM +0200, Vincent Stehl?
>>> wrote:
>>> 
[...]
>> 
>> This is an old topic and the threading seems to be messed up in
>> the archive, but I think Michael Trimarchi has a solution based
>> on inclusion of DFU in the SPL image:
>> 
>> http://lists.denx.de/pipermail/u-boot/2013-October/165849.html
>> 
>> I would prefer to see something slimmer if possible, and using 
>> imx_usb has the advantage of only needing a single tool on the 
>> programming host.
> 
> Ah yes, firing up and letting DFU do the rest is another option I
> had forgotten about.  But I too lean towards something imx_usb can
> do as that will also make integration into the Freescale factory
> flashing tool easier I suspect.
> 

I think there's an easy way and a more complicated way to do this.

The easiest is probably to do something custom in SPL and
update imx_usb to support the same.

There's a WRITE_FILE command in the serial download protocol
which could serve as an example, though 100% compatibility isn't
needed, since the internal ROM isn't needed.

Note that this would also require updates to the SB_LOADER tool
used in the Freescale Manufacturing tool for use on Windows.
I think that's closed source (and C# or somesuch), but perhaps
Fabio can provide details.

The harder way (and the Freescale way) is to somehow package
the SPL content and full U-Boot image in a way such that the
SPL is a "plugin" that can execute and return to the boot loader
after setting up DDR and bundle SPL and u-boot.img into a
single .imx file.

I think that both imx_usb and sb_loader support plugins.

Regards,


Eric


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVahUpAAoJEFUqXmm9AiVrTNkH/iexdhpBtiLHGO9IQ1T9ewk+
B+sdeZHj8MLRWRsN7AeWrfXXFqy6+JTkPkKLgiqkfd93JmT82xsp6EOzqO1MPmBK
L+nSl0+ILj/iBVhyew5O56N/EJT/JQG4wHIbuJfEIgkMkWP7BK722sOitnkKLXO5
aNPi5T4z4XZXnw+5JSLQi75c4TUGz5O8tMNxd/8yUBrjeW0t03ZqAWErWvAq29IT
qLWLr1SYTl5Rl25D5dn2p/mwYlbHNq0KsYZTjesQeyGdKglN8QVmvof84doPpL34
cxerzYlKr1VGaMGo2jQ3hOs+eA+JrYG+C3V82hTvl+5XpSLpfQ/BTxiG04n/pmw=
=nBFi
-----END PGP SIGNATURE-----

[U-Boot] Booting Wandboard through USB

[Fabio Estevam]

On Sat, May 30, 2015 at 2:41 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi Tom,
>
> On 05/30/2015 09:49 AM, Tom Rini wrote:
>> On Fri, May 29, 2015 at 11:46:40AM +0200, Vincent Stehl? wrote:
>>
>>> Hi,
>>>
>>> Is it still possible to boot u-boot on Wandboard through USB,
>>> please?
>>
>> Not directly.  I've been toying with a few ideas but not put any
>> into practice yet.  The first and possibly simplist would be to
>> mimic the USB RNDIS in SPL support am335x uses (see
>> am335x_evm_usbspl_defconfig) but I don't know if we have space for
>> that.  The second would be trying to "fake" things such that for
>> imx_usb_loader you can pass both SPL and u-boot.img, and SPL is
>> run, inits memory and just exists and then u-boot.img is loaded and
>> run, similar to how with the non-SPL case you can use the loader to
>> pass in u-boot.imx as well as a kernel, ramdisk, etc, into DDR.
>>
>> Proof of concepts, patches or just plain old feedback greatly
>> appreciated!
>>
>
> This is an old topic and the threading seems to be messed
> up in the archive, but I think Michael Trimarchi has a
> solution based on inclusion of DFU in the SPL image:
>
>         http://lists.denx.de/pipermail/u-boot/2013-October/165849.html
>
> I would prefer to see something slimmer if possible, and using
> imx_usb has the advantage of only needing a single tool on the
> programming host.

I know this thread is a bit old, but I am also interested in loading
SPL + u-boot.img via imx_usb tool.

Has anyone managed to get this working in the mean time?

Thanks,

Fabio Estevam

[U-Boot] Booting Wandboard through USB

[Fabio Estevam]

Hi Vincent,

On Fri, May 29, 2015 at 6:46 AM, Vincent Stehl?
<vincent.stehle@laposte.net> wrote:
> Hi,
>
> Is it still possible to boot u-boot on Wandboard through USB, please?
>
> U-boot has switched to SPL for Wandboard recently[1] and I wonder if it
> did not lose the possibility to boot the Wandboard through USB in the
> mean time.

I am not sure how to load SPL + img via usb.

Adding Tim and Stefano in case they have any suggestions.

Regards,

Fabio Estevam

[U-Boot] Booting Wandboard through USB

[Vincent Prince]

following:
- https://lists.denx.de/pipermail/u-boot/2015-May/215573.html
- https://lists.denx.de/pipermail/u-boot/2015-June/215606.html


Hi everyone,

I'd like to know if something is going on regarding this topic ?

I managed to flash a yocto BSP with SPL with USB+serial with Fabio help,
but I found it a bit painful, and hard to automate.

- Go into serial console to reboot, interrupt uboot, and type bmode usb.
- Quit serial console
- Launch imx_usb_loader,
- Send u-boot.bin with ymodem (teraterm on windows, kermit on linux)
- Go back to serial console, interrupt u-boot
- Mount Usb OTG (ums 1 mmc 0)
- Flash wic.gz image
- Reset u-boot.

What is a bit annoying is the use of ymodem to load u-boot.bin.
Anybody has a cleaner solution ?

Thanks

[U-Boot] Booting Wandboard through USB

[Wolfgang Denk]

Dear Vincent,

In message <CAB2nKc_zcgbCGOVdXgP-Q2hNVAv-PE11pYn43PJ828iFHdPftg@mail.gmail.com> you wrote:
>
> I managed to flash a yocto BSP with SPL with USB+serial with Fabio help,
> but I found it a bit painful, and hard to automate.
> 
> - Go into serial console to reboot, interrupt uboot, and type bmode usb.
> - Quit serial console
> - Launch imx_usb_loader,
> - Send u-boot.bin with ymodem (teraterm on windows, kermit on linux)
> - Go back to serial console, interrupt u-boot
> - Mount Usb OTG (ums 1 mmc 0)
> - Flash wic.gz image
> - Reset u-boot.

A bit easier (though not really much) is it when you use ckermit as
terminal program.  Then you can run both the serial connections and
the download with in the same command environment.  See [1] for a
well tested standard configuration for Kermit; in addition, you may
want to add something like this:

define sx !sx \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)
define rx !rx \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)
define sy !sz --ymodem \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)
define ry !rz --ymodem \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)
define sz !sz \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)
define rz !rz \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)

to add macros for sending and receiving files suing X-, Y- and
Z-modem protocols.

Best regards,

Wolfgang Denk

-- 
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: wd at denx.de
Quote from a recent meeting:   "We are going to continue having these
meetings everyday until I find out why no work is getting done."

[U-Boot] Booting Wandboard through USB

[Fabio Estevam]

Hi Vincent,

On Thu, Jul 27, 2017 at 6:05 AM, Vincent Prince
<vincent.prince.fr@gmail.com> wrote:
> following:
> - https://lists.denx.de/pipermail/u-boot/2015-May/215573.html
> - https://lists.denx.de/pipermail/u-boot/2015-June/215606.html
>
>
> Hi everyone,
>
> I'd like to know if something is going on regarding this topic ?
>
> I managed to flash a yocto BSP with SPL with USB+serial with Fabio help,
> but I found it a bit painful, and hard to automate.
>
> - Go into serial console to reboot, interrupt uboot, and type bmode usb.
> - Quit serial console
> - Launch imx_usb_loader,
> - Send u-boot.bin with ymodem (teraterm on windows, kermit on linux)
> - Go back to serial console, interrupt u-boot
> - Mount Usb OTG (ums 1 mmc 0)
> - Flash wic.gz image
> - Reset u-boot.
>
> What is a bit annoying is the use of ymodem to load u-boot.bin.
> Anybody has a cleaner solution ?

Stefan has sent a patch series that seems to really help on loading
SPL + u-boot.img via USB:

https://www.mail-archive.com/u-boot at lists.denx.de/msg259052.html

I haven't had a chance to test it yet as I am currently out of office
without hardware access.

Please give it a try and provide your feedback.

[U-Boot] Booting Wandboard through USB

[Vincent Prince]

Hi Fabio, Stefan,

Indeed i saw it this morning with great enthusiasm,
I'm currently in vacation, I'll test it in two weeks when I'll back to work.

Thanks,
Vincent

2017-08-05 14:22 GMT+02:00 Fabio Estevam <festevam@gmail.com>:

> Hi Vincent,
>
> On Thu, Jul 27, 2017 at 6:05 AM, Vincent Prince
> <vincent.prince.fr@gmail.com> wrote:
> > following:
> > - https://lists.denx.de/pipermail/u-boot/2015-May/215573.html
> > - https://lists.denx.de/pipermail/u-boot/2015-June/215606.html
> >
> >
> > Hi everyone,
> >
> > I'd like to know if something is going on regarding this topic ?
> >
> > I managed to flash a yocto BSP with SPL with USB+serial with Fabio help,
> > but I found it a bit painful, and hard to automate.
> >
> > - Go into serial console to reboot, interrupt uboot, and type bmode usb.
> > - Quit serial console
> > - Launch imx_usb_loader,
> > - Send u-boot.bin with ymodem (teraterm on windows, kermit on linux)
> > - Go back to serial console, interrupt u-boot
> > - Mount Usb OTG (ums 1 mmc 0)
> > - Flash wic.gz image
> > - Reset u-boot.
> >
> > What is a bit annoying is the use of ymodem to load u-boot.bin.
> > Anybody has a cleaner solution ?
>
> Stefan has sent a patch series that seems to really help on loading
> SPL + u-boot.img via USB:
>
> https://www.mail-archive.com/u-boot at lists.denx.de/msg259052.html
>
> I haven't had a chance to test it yet as I am currently out of office
> without hardware access.
>
> Please give it a try and provide your feedback.
>

[U-Boot] Booting Wandboard through USB

[Tom Rini]

On Sat, Aug 05, 2017 at 03:44:04PM +0200, Vincent Prince wrote:
> Hi Fabio, Stefan,
> 
> Indeed i saw it this morning with great enthusiasm,
> I'm currently in vacation, I'll test it in two weeks when I'll back to work.

Add me to the existed people list as this means I can finally add an
i.MX target to my CI loop :)

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170805/cb1412f3/attachment.sig>