From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikolay Dimitrov Date: Mon, 01 Jun 2015 01:54:35 +0300 Subject: [U-Boot] Booting Wandboard through USB In-Reply-To: <556A190C.2010704@boundarydevices.com> References: <55683580.8060803@bergerie> <20150530164921.GB1728@bill-the-cat> <5569F236.4080905@bergerie> <556A190C.2010704@boundarydevices.com> Message-ID: <556B912B.3090409@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 all, On 05/30/2015 11:09 PM, Eric Nelson wrote: > On 05/30/2015 10:24 AM, Vincent Stehl? wrote: >> On 05/30/2015 06:49 PM, Tom Rini wrote: >> .. >>> The second would be trying to "fake" things such that for >>> imx_usb_loader you can pass both SPL and u-boot.img, and SPL is >>> run, inits memory and just exists and then u-boot.img is loaded >>> and run, similar to how with the non-SPL case you can use the >>> loader to pass in u-boot.imx as well as a kernel, ramdisk, etc, >>> into DDR. >> >> I wonder if we could use the i.MX6 ROM "plugin"[1] mechanism with u-boot >> SPL, to download it through USB, have it configure the DDR and return to >> the ROM, in a way that would allow us to resume downloading the second >> stage u-boot through USB... >> >> Best regards, >> >> V. >> >> [1] Chapter "8.8 Plugin Image" of the i.MX6D/Q Reference Manual. > > ;) This is an even older idea: > http://lists.denx.de/pipermail/u-boot/2012-September/thread.html#134444 > > In my earlier e-mail, I said that this was more complicated because > it involves hacking the image creation process (and perhaps some > linker scripts). > > It also requires that SPL images have some form of flag telling them > not to boot, but return to the ROM boot loader after initializing DDR > (i.e. they need to optionally act like a plugin). According to the RM, the plugin image is expected to load the actual boot image in memory and report the start/len/ivt parameters to the boot ROM. Then I see 2 problems: 1. It seems that at this exact point if the plugin returned "success" the boot ROM will start executing the downloaded image and there's no intent to download anything else from USB. 2. Even if there was a way for the boot ROM to download more data, the previous communication sequence ends with "jump header" (in imx-usb- loader jargon) which means we can't differentiate between boot ROM returning for more boot data, and a fresh new boot session. Regards, Nikolay