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?