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 <[email protected]> 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
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
