From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikolay Dimitrov Date: Mon, 01 Jun 2015 19:28:38 +0300 Subject: [U-Boot] Booting Wandboard through USB In-Reply-To: References: <55683580.8060803@bergerie> <20150530164921.GB1728@bill-the-cat> <5569F236.4080905@bergerie> <556A190C.2010704@boundarydevices.com> <556B912B.3090409@mail.bg> <556B9603.3080507@mail.bg> <556C1370.7080503@denx.de> Message-ID: <556C8836.9000200@mail.bg> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Tim, On 06/01/2015 07:03 PM, Tim Harvey wrote: > On Mon, Jun 1, 2015 at 1:10 AM, Stefano Babic 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