Hi Tim,
On 06/01/2015 07:03 PM, Tim Harvey wrote:
On Mon, Jun 1, 2015 at 1:10 AM, Stefano Babic <[email protected]> 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
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
