[U-Boot] SPL Dfu update

[Tom Rini <trini@ti.com>]

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>