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
Applied, thanks. Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
