From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikolay Dimitrov Date: Mon, 01 Jun 2015 19:08:43 +0300 Subject: [U-Boot] Booting Wandboard through USB In-Reply-To: <556C1370.7080503@denx.de> 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: <556C838B.1070305@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 Stefano, On 06/01/2015 11:10 AM, Stefano Babic wrote: > Hi Nikolay, > > (jumping a little later in the discussion but trying to sumarize all > topics..) Np, you're welcome. > 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. Well, there's no need to work differently. There are already config options that select which interface should be used to load the next boot stage or OS image: void board_init_r(gd_t *dummy1, ulong dummy2) { ... #ifdef CONFIG_SPL_NOR_SUPPORT case BOOT_DEVICE_NOR: spl_nor_load_image(); break; #endif ... #ifdef CONFIG_SPL_USB_SUPPORT case BOOT_DEVICE_USB: spl_usb_load_image(); break; #endif ... } Also, current SPL loads not only from storage, but also from some interfaces like serial port, ethernet, usb-eth. We can just add one more here. To me it looks like a natural extension, thanks to the hard work done so far on the current code. > 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. If you're commenting how the FSL boot ROM works, I doubt that there's a 2nd attempt to load via USB-OTG once the SPL is downloaded, and regardless of the plugin flag. If you're commenting about a possible future imx6 SPL implementation in U-Boot - that would be entirely possible, as long as we fit in OCRAM. >> - 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? Regards, Nikolay