[U-Boot] Booting Wandboard through USB
Hi,
Is it still possible to boot u-boot on Wandboard through USB, please?
U-boot has switched to SPL for Wandboard recently[1] and I wonder if it did not lose the possibility to boot the Wandboard through USB in the mean time.
Granted, I can generate an u-boot-with-spl.imx suitable for boot through USB, with tools such as imx_usb_loader[2], but I am not able to compile SPL with usb or ethernet support. Is loading the second stage image from SD card the only way now?
Thanks for any advice.
Best regards,
V.
[1] Commit 0d1ea05210f3 ("wandboard: Switch to SPL support") http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/220799
On Fri, May 29, 2015 at 11:46:40AM +0200, Vincent Stehlé wrote:
Hi,
Is it still possible to boot u-boot on Wandboard through USB, please?
Not directly. I've been toying with a few ideas but not put any into practice yet. The first and possibly simplist would be to mimic the USB RNDIS in SPL support am335x uses (see am335x_evm_usbspl_defconfig) but I don't know if we have space for that. 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.
Proof of concepts, patches or just plain old feedback greatly appreciated!
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.
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).
Regards,
Eric
On Sat, May 30, 2015 at 01:09:48PM -0700, 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).
Well there is precendce these days for doing special things to cooperate with ROM, we do something not totally dissimilar for sunxi I believe, in some cases.
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
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 - 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.
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
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
On Mon, Jun 1, 2015 at 1:10 AM, Stefano Babic sbabic@denx.de 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:
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.
Tim
Hi Tim,
On 06/01/2015 07:03 PM, Tim Harvey wrote:
On Mon, Jun 1, 2015 at 1:10 AM, Stefano Babic sbabic@denx.de 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
On Mon, Jun 1, 2015 at 9:28 AM, Nikolay Dimitrov picmaster@mail.bg wrote:
Hi Tim,
On 06/01/2015 07:03 PM, Tim Harvey wrote:
On Mon, Jun 1, 2015 at 1:10 AM, Stefano Babic sbabic@denx.de 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
On Mon, Jun 01, 2015 at 09:38:18AM -0700, Tim Harvey wrote: [snip]
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.
The counter-point that we can't just dismiss is that we want companies on mainline. Today many use the Freescale mfgtool (which is a big wrapper around shoving u-boot.imx over and booting a kernel + ramdisk into Linux and then flashing the board. A solution that continues to work within this framework removes a barrier from getting them on mainline (and from Freescale shipping a more recent version of U-Boot with their refernce SW).
Thinking about this a bit, as near as I can tell the way the mfgtool (and for that matter, imx_usb_loader when passing in multiple files) works is to use the header of u-boot.imx (or whatever...) to initialize DDR, then start taking files and putting them in. Could we not add some debug (or opt-in CONFIG statement) that would cause SPL to spit out in essence the values to plug into a template for header-based DDR init? That way the mfgtool itself will continue working and instead of being told to use u-boot.imx it's given a script (which iirc it supports) and u-boot.img to run and it's normal loads of everything to flash. Roughly speaking :)
On Tue, Jun 2, 2015 at 7:25 AM, Tom Rini trini@konsulko.com wrote:
On Mon, Jun 01, 2015 at 09:38:18AM -0700, Tim Harvey wrote: [snip]
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.
The counter-point that we can't just dismiss is that we want companies on mainline. Today many use the Freescale mfgtool (which is a big wrapper around shoving u-boot.imx over and booting a kernel + ramdisk into Linux and then flashing the board. A solution that continues to work within this framework removes a barrier from getting them on mainline (and from Freescale shipping a more recent version of U-Boot with their refernce SW).
mfgtool is a big 'windows' wrapper around shoving a u-boot.imx over USB OTG and scripting through serial port to do 'whatever else' is needed. While fsl may be getting close to mainline that doesn't mean they are using SPL and thats the difference here.
Thinking about this a bit, as near as I can tell the way the mfgtool (and for that matter, imx_usb_loader when passing in multiple files) works is to use the header of u-boot.imx (or whatever...) to initialize DDR, then start taking files and putting them in. Could we not add some debug (or opt-in CONFIG statement) that would cause SPL to spit out in essence the values to plug into a template for header-based DDR init? That way the mfgtool itself will continue working and instead of being told to use u-boot.imx it's given a script (which iirc it supports) and u-boot.img to run and it's normal loads of everything to flash. Roughly speaking :)
-- Tom
mfgmode uses a windows exe that takes a *.imx which has a DCD table and sets the regs defined in the DCD table - so it relies on the non-SPL way of doing things where the MMDC configuration is hard-coded in the DCD, thus every combination of SoC 'type' (IMX6DQ|IMX6SDL|IMX6SX) and memory configuration (chip+width+calib-for-pcb+size) requires a different DCD thus *.imx.
To my knowledge fsl has not 'embraced the SPL' and is still relying on custom DCD's in the bootloader (someone please correct me if I'm out of date here). That thought works just fine for customers in large vertical markets with one or two configs but is very inflexible for those of us that vary the parameters quite a bit.
The imx_usb_loader works off the assumption that you have a DCD (which is just a table of register addr's and values) and that the DCD configures the MMDC properly for your target, so that it can then load 1 or more blobs into DRAM. In our case what we are wanting to do is let the SPL configure the MMDC then use the SPL to allow a raw DRAM load option over OTG. I don't see any other way to do it other than Nikolay's idea which should not be that difficult to implement. I don't know enough about mfgtool to know how flexible it is. Can you build imx_usb_loader for windows and choose to use an 'enhanced one' vs the closed-source one distributed with mfgtool and thus continue to use the config/scripting portion of the mfgtool package?
It 'could' be possible to make the SPL output all its register writes I suppose through some wrappers around writel (I've actually done this in the past to troubleshoot things) to re-create a DCD but I'm not sure I see the point in where we go from there as you would also need the SPL to not re-configure the MMDC and not clobber memory.... so essentially your no longer using the SPL.
If someone wants to use mfgtool they can go down the path of non-SPL U-Boot's and be fine. If someone wants to use SPL why can't we provide a better/different approach? Perhaps fsl can release the source for mfgtools windows cmdline app so that it can be enahnced to support this as well.
I've run into a similar issue with fsl's 'ddr calibration and stress test tool' because I think it uses the same approach to mfgtool (it may even use the same windows exe). The windows tool loads their stand-alone bare-metal blob (has a DCD so equiv to an *.imx) over OTG then the bare-metal app immediately implements a USB HID-generic gadget over OTG and communicates to the windows app that way (basically serial-console over USB at that point). Now, if you are able to get the source for the ddr calibration and stress test tool from fsl (not too hard) you can build it in a way that it doesn't have the DCD and doesn't use the USB OTG HID-generic gadget as a serial console and then load it via U-Boot or JTAG (of course in that mode U-Boot or JTAG needs to be doing what the DCD did to configure the MMDC so you can run into a catch-22 scenario if your trying to use the tool to obtain those DDC values). When you get the source for this tool, its just the source for the bare-metal app not the Windows exe that is used with it. The only reason you would need the source is if you needed to boot it in the non-OTG mode with your own UART pinmux etc.
Tim
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Tom,
On 05/30/2015 09:49 AM, Tom Rini wrote:
On Fri, May 29, 2015 at 11:46:40AM +0200, Vincent Stehlé wrote:
Hi,
Is it still possible to boot u-boot on Wandboard through USB, please?
Not directly. I've been toying with a few ideas but not put any into practice yet. The first and possibly simplist would be to mimic the USB RNDIS in SPL support am335x uses (see am335x_evm_usbspl_defconfig) but I don't know if we have space for that. 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.
Proof of concepts, patches or just plain old feedback greatly appreciated!
This is an old topic and the threading seems to be messed up in the archive, but I think Michael Trimarchi has a solution based on inclusion of DFU in the SPL image:
http://lists.denx.de/pipermail/u-boot/2013-October/165849.html
I would prefer to see something slimmer if possible, and using imx_usb has the advantage of only needing a single tool on the programming host.
Regards,
Eric
On Sat, May 30, 2015 at 10:41:16AM -0700, Eric Nelson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Tom,
On 05/30/2015 09:49 AM, Tom Rini wrote:
On Fri, May 29, 2015 at 11:46:40AM +0200, Vincent Stehlé wrote:
Hi,
Is it still possible to boot u-boot on Wandboard through USB, please?
Not directly. I've been toying with a few ideas but not put any into practice yet. The first and possibly simplist would be to mimic the USB RNDIS in SPL support am335x uses (see am335x_evm_usbspl_defconfig) but I don't know if we have space for that. 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.
Proof of concepts, patches or just plain old feedback greatly appreciated!
This is an old topic and the threading seems to be messed up in the archive, but I think Michael Trimarchi has a solution based on inclusion of DFU in the SPL image:
http://lists.denx.de/pipermail/u-boot/2013-October/165849.html
I would prefer to see something slimmer if possible, and using imx_usb has the advantage of only needing a single tool on the programming host.
Ah yes, firing up and letting DFU do the rest is another option I had forgotten about. But I too lean towards something imx_usb can do as that will also make integration into the Freescale factory flashing tool easier I suspect.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Tom,
On 05/30/2015 12:25 PM, Tom Rini wrote:
On Sat, May 30, 2015 at 10:41:16AM -0700, Eric Nelson wrote:
On 05/30/2015 09:49 AM, Tom Rini wrote:
On Fri, May 29, 2015 at 11:46:40AM +0200, Vincent Stehlé wrote:
[...]
This is an old topic and the threading seems to be messed up in the archive, but I think Michael Trimarchi has a solution based on inclusion of DFU in the SPL image:
http://lists.denx.de/pipermail/u-boot/2013-October/165849.html
I would prefer to see something slimmer if possible, and using imx_usb has the advantage of only needing a single tool on the programming host.
Ah yes, firing up and letting DFU do the rest is another option I had forgotten about. But I too lean towards something imx_usb can do as that will also make integration into the Freescale factory flashing tool easier I suspect.
I think there's an easy way and a more complicated way to do this.
The easiest is probably to do something custom in SPL and update imx_usb to support the same.
There's a WRITE_FILE command in the serial download protocol which could serve as an example, though 100% compatibility isn't needed, since the internal ROM isn't needed.
Note that this would also require updates to the SB_LOADER tool used in the Freescale Manufacturing tool for use on Windows. I think that's closed source (and C# or somesuch), but perhaps Fabio can provide details.
The harder way (and the Freescale way) is to somehow package the SPL content and full U-Boot image in a way such that the SPL is a "plugin" that can execute and return to the boot loader after setting up DDR and bundle SPL and u-boot.img into a single .imx file.
I think that both imx_usb and sb_loader support plugins.
Regards,
Eric
On Sat, May 30, 2015 at 2:41 PM, Eric Nelson eric.nelson@boundarydevices.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Tom,
On 05/30/2015 09:49 AM, Tom Rini wrote:
On Fri, May 29, 2015 at 11:46:40AM +0200, Vincent Stehlé wrote:
Hi,
Is it still possible to boot u-boot on Wandboard through USB, please?
Not directly. I've been toying with a few ideas but not put any into practice yet. The first and possibly simplist would be to mimic the USB RNDIS in SPL support am335x uses (see am335x_evm_usbspl_defconfig) but I don't know if we have space for that. 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.
Proof of concepts, patches or just plain old feedback greatly appreciated!
This is an old topic and the threading seems to be messed up in the archive, but I think Michael Trimarchi has a solution based on inclusion of DFU in the SPL image:
http://lists.denx.de/pipermail/u-boot/2013-October/165849.htmlI would prefer to see something slimmer if possible, and using imx_usb has the advantage of only needing a single tool on the programming host.
I know this thread is a bit old, but I am also interested in loading SPL + u-boot.img via imx_usb tool.
Has anyone managed to get this working in the mean time?
Thanks,
Fabio Estevam
Hi Vincent,
On Fri, May 29, 2015 at 6:46 AM, Vincent Stehlé vincent.stehle@laposte.net wrote:
Hi,
Is it still possible to boot u-boot on Wandboard through USB, please?
U-boot has switched to SPL for Wandboard recently[1] and I wonder if it did not lose the possibility to boot the Wandboard through USB in the mean time.
I am not sure how to load SPL + img via usb.
Adding Tim and Stefano in case they have any suggestions.
Regards,
Fabio Estevam
participants (7)
-
Eric Nelson -
Fabio Estevam -
Nikolay Dimitrov -
Stefano Babic -
Tim Harvey -
Tom Rini -
Vincent Stehlé