[U-Boot] SPL Dfu update

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi Lukasz

We have discussed during the u-boot mini-summit the possibility to have
the dfu update from SPL. Right now I'm trying to understand what is the best
way to do:


void spl_dfu_load_image()
{
        int rv;

        env_init();
        env_relocate();
        setenv("dfu_alt_info", DFU_BOARD_FLASHINFO);
        board_usb_init();
        g_dnl_register(s);

One option could be do the same of do_dfu command and let upload
all the image that is needed to flash and the issue a usb reset. I don't sure
if the reset can be triggered and then do a cpu board reset and let it boot
from the booting device.

What is for you the best approch?

Michael

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi

On Wed, Oct 30, 2013 at 9:28 AM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
> Hi Lukasz
>
> We have discussed during the u-boot mini-summit the possibility to have
> the dfu update from SPL. Right now I'm trying to understand what is the best
> way to do:
>
>
> void spl_dfu_load_image()
> {
>         int rv;
>
>         env_init();
>         env_relocate();
>         setenv("dfu_alt_info", DFU_BOARD_FLASHINFO);
>         board_usb_init();
>         g_dnl_register(s);
>
> One option could be do the same of do_dfu command and let upload
> all the image that is needed to flash and the issue a usb reset. I don't sure
> if the reset can be triggered and then do a cpu board reset and let it boot
> from the booting device.
>
> What is for you the best approch?
>

better pseudo code

void spl_dfu_load_image()
{
        ret = dfu_config_entities(DFU_BOARD_FLASHINFO, DFU_BOARD_INTERFACE,
                                  DFU_BOARD_NUMBER);
        board_usb_init();
        g_dnl_register(s);
        while(1) {
                if (ctrlc())
                        goto exit;
                ret = usb_gadget_handle_interrupts();
                if (ret)
                        goto exit;
        }

exit:
        g_dnl_unregister();
        dfu_free_entities();
        board_reset();
}

Michael

> Michael

[U-Boot] SPL Dfu update

[Lukasz Majewski]

Hi Michael,

> Hi
> 
> On Wed, Oct 30, 2013 at 9:28 AM, Michael Trimarchi
> <michael@amarulasolutions.com> wrote:
> > Hi Lukasz
> >
> > We have discussed during the u-boot mini-summit the possibility to
> > have the dfu update from SPL. Right now I'm trying to understand
> > what is the best way to do:
> >
> >
> > void spl_dfu_load_image()
> > {
> >         int rv;
> >
> >         env_init();
> >         env_relocate();
> >         setenv("dfu_alt_info", DFU_BOARD_FLASHINFO);
> >         board_usb_init();
> >         g_dnl_register(s);
> >
> > One option could be do the same of do_dfu command and let upload
> > all the image that is needed to flash and the issue a usb reset. I
> > don't sure if the reset can be triggered

With the dfu-util -R you can issue reset on the board. It already works
in mainline (please refer to CMD_DFU).

> and then do a cpu board
> > reset and let it boot from the booting device.
> >
> > What is for you the best approch?
> >
> 
> better pseudo code
> 
> void spl_dfu_load_image()
> {
>         ret = dfu_config_entities(DFU_BOARD_FLASHINFO,
> DFU_BOARD_INTERFACE, DFU_BOARD_NUMBER);
>         board_usb_init();
>         g_dnl_register(s);
>         while(1) {
>                 if (ctrlc())
>                         goto exit;
>                 ret = usb_gadget_handle_interrupts();
>                 if (ret)
>                         goto exit;
>         }
> 
> exit:
>         g_dnl_unregister();
>         dfu_free_entities();
>         board_reset();
> }
> 

In general the presented structure is correct.

However, I've got other concerns:

The DFU + composite + gadget + UDC driver code is large (around 24KiB
in binary size [1] for the TRATS). 

I'm not sure if this size would be acceptable for SPL. Of course there
are some spots for code base size reduction (like optimizing and often
hardcoding code ported from linux kernel).

I _predict_, that with really aggressive approach for optimization the
size [1] can be reduced, maybe up to 30%. 


> Michael
> 
> > Michael



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi Lukasz

On Wed, Oct 30, 2013 at 1:58 PM, Lukasz Majewski <l.majewski@samsung.com> wrote:
> Hi Michael,
>
>> Hi
>>
>> On Wed, Oct 30, 2013 at 9:28 AM, Michael Trimarchi
>> <michael@amarulasolutions.com> wrote:
>> > Hi Lukasz
>> >
>> > We have discussed during the u-boot mini-summit the possibility to
>> > have the dfu update from SPL. Right now I'm trying to understand
>> > what is the best way to do:
>> >
>> >
>> > void spl_dfu_load_image()
>> > {
>> >         int rv;
>> >
>> >         env_init();
>> >         env_relocate();
>> >         setenv("dfu_alt_info", DFU_BOARD_FLASHINFO);
>> >         board_usb_init();
>> >         g_dnl_register(s);
>> >
>> > One option could be do the same of do_dfu command and let upload
>> > all the image that is needed to flash and the issue a usb reset. I
>> > don't sure if the reset can be triggered
>
> With the dfu-util -R you can issue reset on the board. It already works
> in mainline (please refer to CMD_DFU).
>
>> and then do a cpu board
>> > reset and let it boot from the booting device.
>> >
>> > What is for you the best approch?
>> >
>>
>> better pseudo code
>>
>> void spl_dfu_load_image()
>> {
>>         ret = dfu_config_entities(DFU_BOARD_FLASHINFO,
>> DFU_BOARD_INTERFACE, DFU_BOARD_NUMBER);
>>         board_usb_init();
>>         g_dnl_register(s);
>>         while(1) {
>>                 if (ctrlc())
>>                         goto exit;
>>                 ret = usb_gadget_handle_interrupts();
>>                 if (ret)
>>                         goto exit;
>>         }
>>
>> exit:
>>         g_dnl_unregister();
>>         dfu_free_entities();
>>         board_reset();
>> }
>>
>
> In general the presented structure is correct.
>
> However, I've got other concerns:
>
> The DFU + composite + gadget + UDC driver code is large (around 24KiB
> in binary size [1] for the TRATS).
>

This is not a problem because this should not be supported by all the
architecture.
Optimization can come later on

> I'm not sure if this size would be acceptable for SPL. Of course there
> are some spots for code base size reduction (like optimizing and often
> hardcoding code ported from linux kernel).
>
> I _predict_, that with really aggressive approach for optimization the
> size [1] can be reduced, maybe up to 30%.
>
>

Michael

>> Michael
>>
>> > Michael
>
>
>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[U-Boot] SPL Dfu update

[Stefano Babic]

Hi Lukasz, hi Michael,

On 30/10/2013 13:58, Lukasz Majewski wrote:

> In general the presented structure is correct.
> 
> However, I've got other concerns:
> 
> The DFU + composite + gadget + UDC driver code is large (around 24KiB
> in binary size [1] for the TRATS). 
> 
> I'm not sure if this size would be acceptable for SPL. Of course there
> are some spots for code base size reduction (like optimizing and often
> hardcoding code ported from linux kernel).

Apart of the fact that is possible to add DFU to SPL, I am missing which
is the real advantage. One goal of having split U-Boot into two images
(SPL and U-Boot) is also to get a simpler and smaller image, letting the
main U-Boot image doing the rest (hush shell, further drivers, and so
on). We are now trying to push features that we currently have into SPL.
Well, why cannot we simply run U-Boot if we need a DFU update ? Which
are the real advantages for having DFU in SPL ?

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi

On Wed, Oct 30, 2013 at 2:28 PM, Stefano Babic <sbabic@denx.de> wrote:
> Hi Lukasz, hi Michael,
>
> On 30/10/2013 13:58, Lukasz Majewski wrote:
>
>> In general the presented structure is correct.
>>
>> However, I've got other concerns:
>>
>> The DFU + composite + gadget + UDC driver code is large (around 24KiB
>> in binary size [1] for the TRATS).
>>
>> I'm not sure if this size would be acceptable for SPL. Of course there
>> are some spots for code base size reduction (like optimizing and often
>> hardcoding code ported from linux kernel).
>
> Apart of the fact that is possible to add DFU to SPL, I am missing which
> is the real advantage. One goal of having split U-Boot into two images
> (SPL and U-Boot) is also to get a simpler and smaller image, letting the
> main U-Boot image doing the rest (hush shell, further drivers, and so
> on). We are now trying to push features that we currently have into SPL.
> Well, why cannot we simply run U-Boot if we need a DFU update ? Which
> are the real advantages for having DFU in SPL ?
>

USB flashing (no serial, no display) only otg

Michael


> Best regards,
> Stefano Babic
>
> --
> =====================================================================
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> =====================================================================

[U-Boot] SPL Dfu update

[Tom Rini]

On Wed, Oct 30, 2013 at 02:29:32PM +0100, Michael Trimarchi wrote:
> Hi
> 
> On Wed, Oct 30, 2013 at 2:28 PM, Stefano Babic <sbabic@denx.de> wrote:
> > Hi Lukasz, hi Michael,
> >
> > On 30/10/2013 13:58, Lukasz Majewski wrote:
> >
> >> In general the presented structure is correct.
> >>
> >> However, I've got other concerns:
> >>
> >> The DFU + composite + gadget + UDC driver code is large (around 24KiB
> >> in binary size [1] for the TRATS).
> >>
> >> I'm not sure if this size would be acceptable for SPL. Of course there
> >> are some spots for code base size reduction (like optimizing and often
> >> hardcoding code ported from linux kernel).
> >
> > Apart of the fact that is possible to add DFU to SPL, I am missing which
> > is the real advantage. One goal of having split U-Boot into two images
> > (SPL and U-Boot) is also to get a simpler and smaller image, letting the
> > main U-Boot image doing the rest (hush shell, further drivers, and so
> > on). We are now trying to push features that we currently have into SPL.
> > Well, why cannot we simply run U-Boot if we need a DFU update ? Which
> > are the real advantages for having DFU in SPL ?
> >
> 
> USB flashing (no serial, no display) only otg

OK, but how are we getting SPL loaded?  I know of, today, some solutions
using U-Boot + DFU for flashing/restore (and some other non-DFU flashing
solutions) that do SPL+regular U-Boot.  I think this highlights, in
part, once again that Scott is right and we need to think of SPL as a
differently configured U-Boot, because the flip side here is, why should
we load even more data before doing the payload when we know we're a
single purpose run?

-- 
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/39fd8691/attachment.pgp>

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi Tom

On Wed, Oct 30, 2013 at 2:44 PM, Tom Rini <trini@ti.com> wrote:
> On Wed, Oct 30, 2013 at 02:29:32PM +0100, Michael Trimarchi wrote:
>> Hi
>>
>> On Wed, Oct 30, 2013 at 2:28 PM, Stefano Babic <sbabic@denx.de> wrote:
>> > Hi Lukasz, hi Michael,
>> >
>> > On 30/10/2013 13:58, Lukasz Majewski wrote:
>> >
>> >> In general the presented structure is correct.
>> >>
>> >> However, I've got other concerns:
>> >>
>> >> The DFU + composite + gadget + UDC driver code is large (around 24KiB
>> >> in binary size [1] for the TRATS).
>> >>
>> >> I'm not sure if this size would be acceptable for SPL. Of course there
>> >> are some spots for code base size reduction (like optimizing and often
>> >> hardcoding code ported from linux kernel).
>> >
>> > Apart of the fact that is possible to add DFU to SPL, I am missing which
>> > is the real advantage. One goal of having split U-Boot into two images
>> > (SPL and U-Boot) is also to get a simpler and smaller image, letting the
>> > main U-Boot image doing the rest (hush shell, further drivers, and so
>> > on). We are now trying to push features that we currently have into SPL.
>> > Well, why cannot we simply run U-Boot if we need a DFU update ? Which
>> > are the real advantages for having DFU in SPL ?
>> >
>>
>> USB flashing (no serial, no display) only otg
>
> OK, but how are we getting SPL loaded?  I know of, today, some solutions
> using U-Boot + DFU for flashing/restore (and some other non-DFU flashing
> solutions) that do SPL+regular U-Boot.  I think this highlights, in
> part, once again that Scott is right and we need to think of SPL as a
> differently configured U-Boot, because the flip side here is, why should
> we load even more data before doing the payload when we know we're a
> single purpose run?

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.

Michael


>
> --
> Tom

[U-Boot] SPL Dfu update

[Otavio Salvador]

Michael,

On Wed, Oct 30, 2013 at 11:52 AM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
> On Wed, Oct 30, 2013 at 2:44 PM, Tom Rini <trini@ti.com> wrote:
>> On Wed, Oct 30, 2013 at 02:29:32PM +0100, Michael Trimarchi wrote:
>>> Hi
>>>
>>> On Wed, Oct 30, 2013 at 2:28 PM, Stefano Babic <sbabic@denx.de> wrote:
>>> > Hi Lukasz, hi Michael,
>>> >
>>> > On 30/10/2013 13:58, Lukasz Majewski wrote:
>>> >
>>> >> In general the presented structure is correct.
>>> >>
>>> >> However, I've got other concerns:
>>> >>
>>> >> The DFU + composite + gadget + UDC driver code is large (around 24KiB
>>> >> in binary size [1] for the TRATS).
>>> >>
>>> >> I'm not sure if this size would be acceptable for SPL. Of course there
>>> >> are some spots for code base size reduction (like optimizing and often
>>> >> hardcoding code ported from linux kernel).
>>> >
>>> > Apart of the fact that is possible to add DFU to SPL, I am missing which
>>> > is the real advantage. One goal of having split U-Boot into two images
>>> > (SPL and U-Boot) is also to get a simpler and smaller image, letting the
>>> > main U-Boot image doing the rest (hush shell, further drivers, and so
>>> > on). We are now trying to push features that we currently have into SPL.
>>> > Well, why cannot we simply run U-Boot if we need a DFU update ? Which
>>> > are the real advantages for having DFU in SPL ?
>>> >
>>>
>>> USB flashing (no serial, no display) only otg
>>
>> OK, but how are we getting SPL loaded?  I know of, today, some solutions
>> using U-Boot + DFU for flashing/restore (and some other non-DFU flashing
>> solutions) that do SPL+regular U-Boot.  I think this highlights, in
>> part, once again that Scott is right and we need to think of SPL as a
>> differently configured U-Boot, because the flip side here is, why should
>> we load even more data before doing the payload when we know we're a
>> single purpose run?
>
> 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?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[U-Boot] SPL Dfu update

[Stefano Babic]

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.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] SPL Dfu update

[Eric Nelson]

On 10/30/2013 07:24 AM, Stefano Babic 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.
>

If I understand Tom's comment, I think the question surrounds
a "bare metal" use case, when a full U-Boot isn't available in
the normal place.

In the case of our i.MX boards that boot to SPI-NOR, it would be
nice to simply load an SPL image over the i.MX downloader
and have immediate access to DFU so we can use it to
program the SPI-NOR.

Regards,


Eric

[U-Boot] SPL Dfu update

[Michael Trimarchi]

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

Michael


>
> Best regards,
> Stefano
>
> --
> =====================================================================
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> =====================================================================

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi

On Wed, Oct 30, 2013 at 3:32 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> On 10/30/2013 07:24 AM, Stefano Babic 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.
>>
>
> If I understand Tom's comment, I think the question surrounds
> a "bare metal" use case, when a full U-Boot isn't available in
> the normal place.
>
> In the case of our i.MX boards that boot to SPI-NOR, it would be
> nice to simply load an SPL image over the i.MX downloader
> and have immediate access to DFU so we can use it to
> program the SPI-NOR.
>

This should be a more complete example (just compile in my platform)

http://pastebin.ca/2472734

Michael

> Regards,
>
>
> Eric

[U-Boot] SPL Dfu update

[Tom Rini]

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.

-- 
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/9d52c024/attachment.pgp>

[U-Boot] SPL Dfu update

[Tom Rini]

On Wed, Oct 30, 2013 at 02:52:25PM +0100, Michael Trimarchi wrote:
> Hi Tom
> 
> On Wed, Oct 30, 2013 at 2:44 PM, Tom Rini <trini@ti.com> wrote:
> > On Wed, Oct 30, 2013 at 02:29:32PM +0100, Michael Trimarchi wrote:
> >> Hi
> >>
> >> On Wed, Oct 30, 2013 at 2:28 PM, Stefano Babic <sbabic@denx.de> wrote:
> >> > Hi Lukasz, hi Michael,
> >> >
> >> > On 30/10/2013 13:58, Lukasz Majewski wrote:
> >> >
> >> >> In general the presented structure is correct.
> >> >>
> >> >> However, I've got other concerns:
> >> >>
> >> >> The DFU + composite + gadget + UDC driver code is large (around 24KiB
> >> >> in binary size [1] for the TRATS).
> >> >>
> >> >> I'm not sure if this size would be acceptable for SPL. Of course there
> >> >> are some spots for code base size reduction (like optimizing and often
> >> >> hardcoding code ported from linux kernel).
> >> >
> >> > Apart of the fact that is possible to add DFU to SPL, I am missing which
> >> > is the real advantage. One goal of having split U-Boot into two images
> >> > (SPL and U-Boot) is also to get a simpler and smaller image, letting the
> >> > main U-Boot image doing the rest (hush shell, further drivers, and so
> >> > on). We are now trying to push features that we currently have into SPL.
> >> > Well, why cannot we simply run U-Boot if we need a DFU update ? Which
> >> > are the real advantages for having DFU in SPL ?
> >> >
> >>
> >> USB flashing (no serial, no display) only otg
> >
> > OK, but how are we getting SPL loaded?  I know of, today, some solutions
> > using U-Boot + DFU for flashing/restore (and some other non-DFU flashing
> > solutions) that do SPL+regular U-Boot.  I think this highlights, in
> > part, once again that Scott is right and we need to think of SPL as a
> > differently configured U-Boot, because the flip side here is, why should
> > we load even more data before doing the payload when we know we're a
> > single purpose run?
> 
> 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.

The point I'm trying to make with thinking of SPL as a differently
configured U-Boot is that you're saying, in essance "I want a U-Boot
that can init the hardware, start up DFU and wait".  A general problem
has been pointed out a few times now that when we want to make SPL+foo
we're bringing more and more stuff in and adding more and more
CONFIG_SPL_FOO that matches up with CONFIG_FOO.  What we need to, longer
term, move to is CONFIG_SPL + CONFIG_FOO, roughly, and then one build to
make SPL one build to make U-Boot.  Very roughly at least.

-- 
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/4df07942/attachment.pgp>

[U-Boot] SPL Dfu update

[Michael Trimarchi]

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

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?

Michael

>
> --
> Tom

[U-Boot] SPL Dfu update

[Tom Rini]

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).

-- 
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/c4302d47/attachment.pgp>

[U-Boot] SPL Dfu update

[Wolfgang Denk]

Dear Michael Trimarchi,

In message <CAOf5uw=1yvf8xde--7bP2y0joPhj9WcEhE8jS8Y05+WYZ_wGBQ@mail.gmail.com> you wrote:
> 
> > Apart of the fact that is possible to add DFU to SPL, I am missing which
> > is the real advantage. One goal of having split U-Boot into two images
> > (SPL and U-Boot) is also to get a simpler and smaller image, letting the
> > main U-Boot image doing the rest (hush shell, further drivers, and so
> > on). We are now trying to push features that we currently have into SPL.
> > Well, why cannot we simply run U-Boot if we need a DFU update ? Which
> > are the real advantages for having DFU in SPL ?
> 
> USB flashing (no serial, no display) only otg

This does not answer Stefano's question: why do it in SPL, what's
wrong with loading the real U-Boot for this purpose?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
IMPORTANT NOTICE TO PURCHASERS: The Entire Physical Universe,  Inclu-
ding  This Product, May One Day Collapse Back into an Infinitesimally
Small Space. Should  Another  Universe  Subsequently  Re-emerge,  the
Existence of This Product in That Universe Cannot Be Guaranteed.

[U-Boot] SPL Dfu update

[Michael Trimarchi]

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

Michael


> --
> Tom

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi

On Wed, Oct 30, 2013 at 8:58 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Michael Trimarchi,
>
> In message <CAOf5uw=1yvf8xde--7bP2y0joPhj9WcEhE8jS8Y05+WYZ_wGBQ@mail.gmail.com> you wrote:
>>
>> > Apart of the fact that is possible to add DFU to SPL, I am missing which
>> > is the real advantage. One goal of having split U-Boot into two images
>> > (SPL and U-Boot) is also to get a simpler and smaller image, letting the
>> > main U-Boot image doing the rest (hush shell, further drivers, and so
>> > on). We are now trying to push features that we currently have into SPL.
>> > Well, why cannot we simply run U-Boot if we need a DFU update ? Which
>> > are the real advantages for having DFU in SPL ?
>>
>> USB flashing (no serial, no display) only otg
>
> This does not answer Stefano's question: why do it in SPL, what's
> wrong with loading the real U-Boot for this purpose?
>

Because it's not possible, internal memory size of some cpus. You need
to have a way to load the second stage and I'm discussing a general
way to do.

> Best regards,
>
> Wolfgang Denk
>

What is your alternative way?

Michael


> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> IMPORTANT NOTICE TO PURCHASERS: The Entire Physical Universe,  Inclu-
> ding  This Product, May One Day Collapse Back into an Infinitesimally
> Small Space. Should  Another  Universe  Subsequently  Re-emerge,  the
> Existence of This Product in That Universe Cannot Be Guaranteed.

[U-Boot] SPL Dfu update

[Wolfgang Denk]

Dear Eric Nelson,

In message <52711896.6010900@boundarydevices.com> you wrote:
>
> In the case of our i.MX boards that boot to SPI-NOR, it would be
> nice to simply load an SPL image over the i.MX downloader
> and have immediate access to DFU so we can use it to
> program the SPI-NOR.

Rewrite this as "...simply load an image over the i.MX downloader" and
then explain again, why the DFU support needs to be in the SPL instead
of the "real" U-Boot?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Horses just naturally have mohawk haircuts.

[U-Boot] SPL Dfu update

[Wolfgang Denk]

Dear Michael Trimarchi,

In message <CAOf5uw=gn4=k9K2pjUA6nxocKWStJ4-GP+sb6_+HGiyW1Nv23Q@mail.gmail.com> you wrote:
> 
> > 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

Why should the image "sent over the otg" be just the SPL, and not
include the real U-Boot?

> dfu is another way to upload and write second stage or what you want. I don't

Why make it so complicated and write a second part at all?  Why not
write it in a single go?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Premature optimization is the root of all evil.         -- D.E. Knuth

[U-Boot] SPL Dfu update

[Tom Rini]

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>

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi Wolfgang

On Wed, Oct 30, 2013 at 9:03 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Michael Trimarchi,
>
> In message <CAOf5uw=gn4=k9K2pjUA6nxocKWStJ4-GP+sb6_+HGiyW1Nv23Q@mail.gmail.com> you wrote:
>>
>> > 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
>
> Why should the image "sent over the otg" be just the SPL, and not
> include the real U-Boot?
>
>> dfu is another way to upload and write second stage or what you want. I don't
>
> Why make it so complicated and write a second part at all?  Why not
> write it in a single go?
>

The discussion seems already closed, I will use it internally

Michael


>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Premature optimization is the root of all evil.         -- D.E. Knuth

[U-Boot] SPL Dfu update

[Tom Rini]

On Wed, Oct 30, 2013 at 08:58:14PM +0100, Wolfgang Denk wrote:
> Dear Michael Trimarchi,
> 
> In message <CAOf5uw=1yvf8xde--7bP2y0joPhj9WcEhE8jS8Y05+WYZ_wGBQ@mail.gmail.com> you wrote:
> > 
> > > Apart of the fact that is possible to add DFU to SPL, I am missing which
> > > is the real advantage. One goal of having split U-Boot into two images
> > > (SPL and U-Boot) is also to get a simpler and smaller image, letting the
> > > main U-Boot image doing the rest (hush shell, further drivers, and so
> > > on). We are now trying to push features that we currently have into SPL.
> > > Well, why cannot we simply run U-Boot if we need a DFU update ? Which
> > > are the real advantages for having DFU in SPL ?
> > 
> > USB flashing (no serial, no display) only otg
> 
> This does not answer Stefano's question: why do it in SPL, what's
> wrong with loading the real U-Boot for this purpose?

The answer, of debatable value, is that we can't download the whole
thing at once to the target device.  One could wrap the logic and load
SPL, then load special task U-Boot, at least in the examples I know well
enough to talk about them (the TI parts).

-- 
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/4225a0cd/attachment.pgp>

[U-Boot] SPL Dfu update

[Eric Nelson]

Hi Wolfgang,

On 10/30/2013 01:01 PM, Wolfgang Denk wrote:
> Dear Eric Nelson,
>
> In message <52711896.6010900@boundarydevices.com> you wrote:
>>
>> In the case of our i.MX boards that boot to SPI-NOR, it would be
>> nice to simply load an SPL image over the i.MX downloader
>> and have immediate access to DFU so we can use it to
>> program the SPI-NOR.
>
> Rewrite this as "...simply load an image over the i.MX downloader" and
> then explain again, why the DFU support needs to be in the SPL instead
> of the "real" U-Boot?
>

I can't because it doesn't (of course), and this is what we're doing
right now, since we only have "real" U-Boot...

And we don't yet have DFU support until the next release.

I should get back to work and send some patches...

Cheers,


Eric

[U-Boot] SPL Dfu update

[Wolfgang Denk]

Dear Michael Trimarchi,

In message <CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com> you wrote:
> 
> > This does not answer Stefano's question: why do it in SPL, what's
> > wrong with loading the real U-Boot for this purpose?
> 
> Because it's not possible, internal memory size of some cpus. You need
> to have a way to load the second stage and I'm discussing a general
> way to do.

I'm not sure that there are many use cases where you have sufficient
room for all that is needed for DFU (including I/O buffers); and if
you move to RAM early, you have other options as well.

> What is your alternative way?

Depending on your hardware there is a zillion ways to do this.  For
low to medium volumes good old JTAG is still a very powerful tool; for
high volumes you will probably just fit pre-programmed NAND on your
board.  And of course there is the growing number of systems that can
just boot and install from a SDCard or USB MSD.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
But the only way of discovering the limits  of  the  possible  is  to
venture a little way past them into the impossible.
                         - _Profiles of the Future_ (1962; rev. 1973)
                  ``Hazards of Prophecy: The Failure of Imagination''

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi

On Wed, Oct 30, 2013 at 9:11 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Michael Trimarchi,
>
> In message <CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com> you wrote:
>>
>> > This does not answer Stefano's question: why do it in SPL, what's
>> > wrong with loading the real U-Boot for this purpose?
>>
>> Because it's not possible, internal memory size of some cpus. You need
>> to have a way to load the second stage and I'm discussing a general
>> way to do.
>
> I'm not sure that there are many use cases where you have sufficient
> room for all that is needed for DFU (including I/O buffers); and if
> you move to RAM early, you have other options as well.
>

No because you need anyway to have a way to load it and dfu is a way.

>> What is your alternative way?
>
> Depending on your hardware there is a zillion ways to do this.  For
> low to medium volumes good old JTAG is still a very powerful tool; for
> high volumes you will probably just fit pre-programmed NAND on your
> board.  And of course there is the growing number of systems that can
> just boot and install from a SDCard or USB MSD.
>

I accept the lesson even I don't thing that I need a lesson on it. We
are talking that we have only otg.
BTW Forget about it.

> Best regards,
>
> Wolfgang Denk

Michael

>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> But the only way of discovering the limits  of  the  possible  is  to
> venture a little way past them into the impossible.
>                          - _Profiles of the Future_ (1962; rev. 1973)
>                   ``Hazards of Prophecy: The Failure of Imagination''

[U-Boot] SPL Dfu update

[Otavio Salvador]

Hello Michael,

On Wed, Oct 30, 2013 at 6:35 PM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
> On Wed, Oct 30, 2013 at 9:11 PM, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Michael Trimarchi,
>>
>> In message <CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com> you wrote:
>>>
>>> > This does not answer Stefano's question: why do it in SPL, what's
>>> > wrong with loading the real U-Boot for this purpose?
>>>
>>> Because it's not possible, internal memory size of some cpus. You need
>>> to have a way to load the second stage and I'm discussing a general
>>> way to do.
>>
>> I'm not sure that there are many use cases where you have sufficient
>> room for all that is needed for DFU (including I/O buffers); and if
>> you move to RAM early, you have other options as well.
>>
>
> No because you need anyway to have a way to load it and dfu is a way.
>
>>> What is your alternative way?
>>
>> Depending on your hardware there is a zillion ways to do this.  For
>> low to medium volumes good old JTAG is still a very powerful tool; for
>> high volumes you will probably just fit pre-programmed NAND on your
>> board.  And of course there is the growing number of systems that can
>> just boot and install from a SDCard or USB MSD.
>>
>
> I accept the lesson even I don't thing that I need a lesson on it. We
> are talking that we have only otg.

I see your user-case and I think I agree with you.

> BTW Forget about it.

Please don't. I think it is a valuable contribution and I think it is
good to have a mechanism which work for your user-case in U-Boot; it
is easy to maintain long term and avoid duplication of work in case
users has some problem.

I got a little bit lost when Tom gave an example where he 'loads' MLO
and U-Boot image from OTG; just clarify it for me as it is not clear
if it works for you or does not.

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi

On Wed, Oct 30, 2013 at 9:53 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> Hello Michael,
>
> On Wed, Oct 30, 2013 at 6:35 PM, Michael Trimarchi
> <michael@amarulasolutions.com> wrote:
>> On Wed, Oct 30, 2013 at 9:11 PM, Wolfgang Denk <wd@denx.de> wrote:
>>> Dear Michael Trimarchi,
>>>
>>> In message <CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com> you wrote:
>>>>
>>>> > This does not answer Stefano's question: why do it in SPL, what's
>>>> > wrong with loading the real U-Boot for this purpose?
>>>>
>>>> Because it's not possible, internal memory size of some cpus. You need
>>>> to have a way to load the second stage and I'm discussing a general
>>>> way to do.
>>>
>>> I'm not sure that there are many use cases where you have sufficient
>>> room for all that is needed for DFU (including I/O buffers); and if
>>> you move to RAM early, you have other options as well.
>>>
>>
>> No because you need anyway to have a way to load it and dfu is a way.
>>
>>>> What is your alternative way?
>>>
>>> Depending on your hardware there is a zillion ways to do this.  For
>>> low to medium volumes good old JTAG is still a very powerful tool; for
>>> high volumes you will probably just fit pre-programmed NAND on your
>>> board.  And of course there is the growing number of systems that can
>>> just boot and install from a SDCard or USB MSD.
>>>
>>
>> I accept the lesson even I don't thing that I need a lesson on it. We
>> are talking that we have only otg.
>
> I see your user-case and I think I agree with you.
>
>> BTW Forget about it.
>
> Please don't. I think it is a valuable contribution and I think it is
> good to have a mechanism which work for your user-case in U-Boot; it
> is easy to maintain long term and avoid duplication of work in case
> users has some problem.
>
> I got a little bit lost when Tom gave an example where he 'loads' MLO
> and U-Boot image from OTG; just clarify it for me as it is not clear
> if it works for you or does not.
>
> From what I understand, your use-case would be:
>
> OTG -> SPL -> DFU -> U-Boot Image -> Jump to U-Boot ?
>

My use case is:

OTG->SPL->DFU ----> flash MLO on flash/NAND/eMMC
                            \-----> flash u-boot.img on NAND/flash/eMMC
                            \-----> .....

done? OK so
dfu-util -R

Board should reset and boot from flashed image. One big thing
that I missed (and thanks to Tom Rini) is stack relocation on DDR

Michael






>
> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

[U-Boot] SPL Dfu update

[Tom Rini]

On Wed, Oct 30, 2013 at 09:11:43PM +0100, Wolfgang Denk wrote:
> Dear Michael Trimarchi,
> 
> In message <CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com> you wrote:
> > 
> > > This does not answer Stefano's question: why do it in SPL, what's
> > > wrong with loading the real U-Boot for this purpose?
> > 
> > Because it's not possible, internal memory size of some cpus. You need
> > to have a way to load the second stage and I'm discussing a general
> > way to do.
> 
> I'm not sure that there are many use cases where you have sufficient
> room for all that is needed for DFU (including I/O buffers); and if
> you move to RAM early, you have other options as well.

No, it's true.  We have some "small" amount of image download area in
some sort of on-chip RAM (OMAP3 is between 54 and 62KiB, depending on
how we think about stack, AM335x is ~110KiB) which is where our first
stage _has_to_ fit.  We can still do a two-step process here of loading
a regular SPL and then a full U-Boot, but this requires more complicated
host side tooling.

But this is what I was trying to highlight, about how Scott's comment is
right.  What's desired here, rightly is a U-Boot build with limited IO
and a main loop that drops right into DFU.  You can do this today with
SPL+U-Boot and a CONFIG_BOOTCOMMAND that just kicks off DFU.  But that
means transferring more data, which is taking more time and yes,
programming time is a concern.

> > What is your alternative way?
> 
> Depending on your hardware there is a zillion ways to do this.  For
> low to medium volumes good old JTAG is still a very powerful tool; for
> high volumes you will probably just fit pre-programmed NAND on your
> board.  And of course there is the growing number of systems that can
> just boot and install from a SDCard or USB MSD.

Exactly.  But you're leaving out "system boots via USB gadget", which is
what Michael is trying to solve.

-- 
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/20131031/e63ccf24/attachment.pgp>

[U-Boot] SPL Dfu update

[Michael Trimarchi]

Hi Tom

On Thu, Oct 31, 2013 at 2:20 PM, Tom Rini <trini@ti.com> wrote:
> On Wed, Oct 30, 2013 at 09:11:43PM +0100, Wolfgang Denk wrote:
>> Dear Michael Trimarchi,
>>
>> In message <CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com> you wrote:
>> >
>> > > This does not answer Stefano's question: why do it in SPL, what's
>> > > wrong with loading the real U-Boot for this purpose?
>> >
>> > Because it's not possible, internal memory size of some cpus. You need
>> > to have a way to load the second stage and I'm discussing a general
>> > way to do.
>>
>> I'm not sure that there are many use cases where you have sufficient
>> room for all that is needed for DFU (including I/O buffers); and if
>> you move to RAM early, you have other options as well.
>
> No, it's true.  We have some "small" amount of image download area in
> some sort of on-chip RAM (OMAP3 is between 54 and 62KiB, depending on
> how we think about stack, AM335x is ~110KiB) which is where our first
> stage _has_to_ fit.  We can still do a two-step process here of loading
> a regular SPL and then a full U-Boot, but this requires more complicated
> host side tooling.
>
> But this is what I was trying to highlight, about how Scott's comment is
> right.  What's desired here, rightly is a U-Boot build with limited IO
> and a main loop that drops right into DFU.  You can do this today with
> SPL+U-Boot and a CONFIG_BOOTCOMMAND that just kicks off DFU.  But that
> means transferring more data, which is taking more time and yes,
> programming time is a concern.
>
>> > What is your alternative way?
>>
>> Depending on your hardware there is a zillion ways to do this.  For
>> low to medium volumes good old JTAG is still a very powerful tool; for
>> high volumes you will probably just fit pre-programmed NAND on your
>> board.  And of course there is the growing number of systems that can
>> just boot and install from a SDCard or USB MSD.
>
> Exactly.  But you're leaving out "system boots via USB gadget", which is
> what Michael is trying to solve.
>

This should make more sense. Try to have all the dfu support
in the first stage is complicated for the writing routine but having
just ram loading can be more simple considering the image size

#define STR_HELPER(x) #x
#define STR(x) STR_HELPER(x)
#define DFU_BOARD_FLASHINFO "RAM" STR(DFU_RAM_DEVICE_ADDRESS) ";"

void spl_dfu_load_image()
{
        int ret;
        struct image_header *header;

        printf("SPL load image\n");

        ret = dfu_config_entities(DFU_BOARD_FLASHINFO, "ram", 0);
        g_dnl_register("dfu");
        while(1) {
                if (ctrlc())
                        goto exit;
                ret = usb_gadget_handle_interrupts();
                if (ret)
                        goto exit;
        }

        g_dnl_unregister();
        dfu_free_entities();

        header = (struct image_header *)DFU_RAM_DEVICE_ADDRESS;
        spl_parse_image_header(header);
        memcpy((void *)DFU_RAM_DEVICE_ADDRESS, (void *)spl_image.load_addr,
                spl_image.size);
        return;
exit:
        g_dnl_unregister();
        dfu_free_entities();
}
> --
> Tom


Michael