[U-Boot] SPL Dfu update

[Tom Rini <trini@ti.com>]

On Wed, Oct 30, 2013 at 08:58:23PM +0100, Michael Trimarchi wrote:
> Hi
> 
> On Wed, Oct 30, 2013 at 8:47 PM, Tom Rini <trini@ti.com> wrote:
> > 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).
> 
> /*
>  * In the context of SPL, board_init_f must ensure that any clocks/etc for
>  * DDR are enabled, ensure that the stack pointer is valid, clear the BSS
>  * and call board_init_f.  We provide this version by default but mark it
>  * as __weak to allow for platforms to do this in their own way if needed.
>  */
> void __weak board_init_f(ulong dummy)
> {
>         /* Set the stack pointer. */
>         asm volatile("mov sp, %0\n" : : "r"(CONFIG_SPL_STACK));
> 
>         /* Clear the BSS. */
>         memset(__bss_start, 0, __bss_end - __bss_start);
> 
>         /* Set global data pointer. */
>         gd = &gdata;
> 
>         board_init_r(NULL, 0);
> }
> 
> You mean this code here.
> 
> and do somenthing like the code here
> 
> board/freescale/p1022ds/spl_minimal.c
> 
> Ok, this is a problem but we are discussing if in your opinion is something
> useful for several manufactured. If not I can just implement and use
> internally

Yes, something along those lines looks correct.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20131030/4678af9c/attachment.pgp>