[U-Boot] Booting Wandboard through USB

[Nikolay Dimitrov <picmaster@mail.bg>]

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