Michael, On Wed, Oct 30, 2013 at 11:52 AM, Michael Trimarchi <[email protected]> wrote: > On Wed, Oct 30, 2013 at 2:44 PM, Tom Rini <[email protected]> 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 <[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? > > 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 mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
