[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[Lukasz Majewski]

Hi Ravi,

> Hi Lukasz
> 
> >> >> Since DFU is tighly coupled to u-boot infrastructure , the size 
> >> >> will increase due to multiple dependencies to compile u-boot
> >> >> DFU source in SPL. Let me re-think on possibility and come back.
> >> 
> >> >If you would need any assistance, please let me know (I don't
> >> >have dra7x, but I do have Beagle Bone Black).
> >> 
> >> The current implementation of dfu (drivers/dfu/dfu.c) relies on 
> >> environment modules (getenv,setenv), and hash algo methods. The 
> >> mandatory modules for DFU includes USB(dwc3/musb), gadget, 
> >> drivers/dfu, hash, environ modules. Added to this mmc/sf support,
> >> with filesystem fat/ext4 would definitely increase the size.
> >> 
> 
> >I've double checked BBB SPL setup:
> 
> >- SPL is the MLO (./common/spl/)
> >- Its size shall be less than 128 KiB
> >- It can reside on eMMC (fat partition, raw LBA offset), NAND or be
> >sent
>  > via serial port.
> 
> >I've build the am335x_boneblack_defconfig and MLO size is 75 KiB.
> 
> >Please correct me, but it seems that the SPL-DFU support adds around
> >30 KiB to SPL binary size.
> 
> 30KB+ is just approx size optimitzed for DFU-SF (qspi) support only,

So the 30KiB+ is for the DFU-SF support only.

> without fat/ext4, mmc support. But all device support may increase
> size.

Ok.

However, adding fat/ext4/mmc (and other) support should be on demand
(and enabled by proper Kconfig options).

This would allow others to add only what is really needed.

> 
> >If yes, then even BBB's SPL can support DFU without any problems
> >(105KiB < 128 KiB).
> 
> You mean BBB must have 128KB ? Can you confirm.

I didn't find any _hard_ rule about the size.

In the am335x_evm.h file the spice reserved for SPL (on raw eMMC) is 128
KiB.

> If BBB is support SPI boot, flashing MLO/U-boot to SPI-flash through
> SPL-DFU/SF would be sufficient right ?

I don't know the exact use cases, but yes, BBB can boot from SPI flash.


I'm just wondering - the use case for your board is to use USB to flash
your device in u-boot SPL. 
If I might ask, why cannot you wait for the U-Boot to use fully-fledged
DFU for flashing?


> Further dfu support for
> mmc/sd, ram available from u-boot.
> 
> >>I'm also wondering if we could even shrink the code more with
> >>reusing or extending the code at ./common/spl/spl_{ext|fat|mmc|sf,
> >>etc}.c (in this way we avoid adding the whole fat, ext, sf
> >>"commands").
> 
> Yes we must see this option. I will check on this.
> 
> >>For more aggressive size reduction we could for example disable
> >>hash algo checking and add ./common/spl/spl_dfu.c file with
> >>ordinary functions and rid of the need to add the whole dfu command.
> 
> >> I have tried minimal subset adding DFU-SF serial flash support
> >> alone in SPL, this itself increases SPL size to 30K+ (SPL size
> >> approx. 107KB for dra7x). 
> >> 
> >> But beagle bone IRAM would be around 64KB right? Definetly this
> >> will not fit.
> >> 
> >> Can we enable this feature for platform with minimum SRAM size of 
> >> 160KB. So SPL-DFU cannot be supported for platform less than 160KB 
> >> (like am335x).
> 
> >I will ask on ML if there is any other interested party in SPL-DFU
> >support (and what are their limitations of SPL code size).
> 
> OK.
> 
> Regards
> Ravi 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group