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