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