[U-Boot] Booting Wandboard through USB

[Nikolay Dimitrov <picmaster@mail.bg>]

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