On Mon, Jun 1, 2015 at 9:28 AM, Nikolay Dimitrov <[email protected]> wrote: > 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
I wouldn't be so concerned.... just give them a linux box or VM with a shellscript wrapped with zenity to provide a big 'FLASH' button ;) Honestly I've never used fsl's mfgtool and never want to. I think its way more complicated than a scrip-table linux solution with very few dependencies (imx_usb_loader) and IMHO I think we should not be encumbered with fitting that complicated mould but instead work on breaking it by providing better options. Tim _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
