[U-Boot] SPL Dfu update

[Otavio Salvador]

Michael,

On Wed, Oct 30, 2013 at 11:52 AM, Michael Trimarchi
<michael at amarulasolutions.com> wrote:
> On Wed, Oct 30, 2013 at 2:44 PM, Tom Rini <trini at 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 at 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