[U-Boot] Booting Wandboard through USB

[Tim Harvey]

On Mon, Jun 1, 2015 at 1:10 AM, Stefano Babic <sbabic at 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