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

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>