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