On Wed, Oct 30, 2013 at 08:43:09PM +0100, Michael Trimarchi wrote:
Hi Tom
On Wed, Oct 30, 2013 at 8:33 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 03:34:45PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 3:24 PM, Stefano Babic sbabic@denx.de wrote:
Hi Otavio,
On 30/10/2013 15:19, Otavio Salvador wrote:
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
But you'd usually want to have an 'upgrade mode' which allows DFU to run. In this case, this could be done using complete U-Boot instead of SPL, no? In case customer needs a slim version of it, it could be accomplished using a specific config and having:
SPL Update mode U-Boot (normal U-Boot with less features) Complete U-Boot (interactive and like)
or am I missing something?
Right, I agree completely with you.
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
It's simple:
- first stage boot can be sent over the otg
- using dfu to flash the u-boot.img, kernel .. etc
dfu is another way to upload and write second stage or what you want. I don't see the point to don't have this option. We have merged USBETH spl support and dfu is more useful.
./usb_load MLO.flash ./dfu-util ... MLO ./dfu-util ... u.boot.img .. ./dfu-util -R
Right. The point of USBETH is to continue the flow from ROM in cases where we're already sending the initial payload this way. It would be analogous to adding support for the USB mode omap3+ support to SPL so that you do: ./usb_load MLO.flash u-boot-flash.img ./dfu-util ... MLO .. ./dfu-util -R
All of that said, I wouldn't mind seeing how the code to make a DFU loop looks, but you're likely to run into the problem of (per Wolfgang) SPL needing to move stack pointerinto DDR once DDR is up so that you have environment, and all of the other big stack users functional.
The stack pointer can be moved using the CONFIG_SPL_RELOC_STACK
Note that this isn't supported under CONFIG_SPL_FRAMEWORK (..yet).
I need to give a try but dfu is more standard then send MLO and then move to a different protocol. What tool are you using to send MLO + u-boot.img in SPLETH way now?
In the SPL_ETH case we do dhcp + tftp requests, which is what the ROM also does to load MLO over (and the ROM supports doing this over the physical ethernet port, or USB as an RNDIS gadget, SPL_USBETH does RNDIS gadget).