[U-Boot] Booting Wandboard through USB

[Tim Harvey]

On Mon, Jun 1, 2015 at 9:28 AM, Nikolay Dimitrov <picmaster at 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 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:
>
>
> 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