Dear Afzal Mohammed,
Hi,
DFU spec mentions it as a method to upgrade firmware (software stored in writable non-volatile memory). It also says other potential uses of DFU is beyond scope of the spec.
Here such a beyond the scope use is being attempted - directly pumping binary images from host via USB to RAM. This facility is a developer centric one in that it gives advantage over upgrading non-volatile memory for testing new images every time during development and/or testing.
Directly putting image onto RAM would speed up upgrade process. This and convenience was the initial thoughts that led to doing this, speed improvement over MMC was only 1 second though - 6 sec on RAM as opposed to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing DFU framework to avoid multiple copy for ram (if worth) may help, and on other platforms and other boot media like NAND maybe improvement would be higher.
And for a platform that doesn't yet have proper DFU suppport for non-volatile media's, DFU to RAM can be used.
Another minor advantage would be to increase life of mmc/nand as it would be less used during development/testing.
usage: <image name> ram <start address> <size> eg. kernel ram 0x81000000 0x1000000
Downloading images to RAM using DFU is not something new, this is acheived in openmoko also.
DFU on RAM can be used for extracting RAM contents to host using dfu upload. Perhaps this can be extended to io for squeezing out register dump through usb, if it is worth.
In addition to ram support, a minor unification of dfu read/write enum's currently duplicated in mmc/nand is done, helping ram support too.
Also dfu ram support is added for am335x SoC based boards.
Based on: usb master branch
Regards Afzal
Will wait for Heiko's ACK and then apply for -next.
Best regards, Marek Vasut