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