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