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