[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi

On Wed, Oct 30, 2013 at 8:47 PM, Tom Rini <trini at 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 at 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 at 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

Michael


> --
> Tom