Hi Rob, > On Wed, Jun 25, 2014 at 7:16 PM, Steve Rae <s...@broadcom.com> wrote: > > Rob, > > > > > > On 14-06-25 06:59 AM, Rob Herring wrote: > >> > >> On Mon, Jun 23, 2014 at 1:37 PM, Steve Rae <s...@broadcom.com> > >> wrote: > >>> > >>> Rob & Sebastian > >>> > >>> I would appreciate your comments on this issue; I suspect that > >>> you had some > >>> ideas regarding the implementation of the fastboot "flash" and > >>> "erase" commands.... > >> > >> > >> I agree with Lukasz's and Marek's comments unless there are good > >> reasons not to use it which can't be fixed. Curiously, USB mass > >> storage does not use the DFU backend, but I don't know why. Perhaps > >> there are incompatibilities or converting it is on the todo list. > >> Are your performance concerns measurable or it's just the fact you > >> are adding another layer? > > > > > > The concern is not performance related -- just the amount of > > (overhead) code required to implement the "DFU backend" versus > > calling mmc_dev->block_write() > > (maybe someone can tell me where to interface into DFU: is it at > > "dfu_write() or ????) > > Yes, I believe it is dfu_write.
dfu_write should be used. > > >> I'd really like to see the eMMC backend be a generic block device > >> backend. There's no good reason for it to be eMMC/SD specific. > > > > > > As I understand it, the "block_write" callback function is in the > > "block_dev_desc_t". Isn't this the part of the "generic block > > device" interface? Please explain... > > There are commands for SATA, SCSI (also SATA), eMMC, IDE, etc. They > are all pretty much the same set of sub-commands and duplicate the > same functionality. Those could all be combined to a single > implementation and/or command for block devices. That part is not DFU > related, but this problem then proliferates to other areas as it has > for DFU. The file drivers/dfu/dfu_mmc.c is mostly generic, but has > some eMMC dependencies with find_mmc_device and mmc_switch_part. dfu_mmc.c is intended to handle eMMC/SD card writing. Please note that there are other files - dfu_nand.c and dfu_raw.c, which are responsible for accessing and storing data to other medium. The "generic" file here is the dfu.c which tries to combine all available media. > So > read and write are already pretty much generic, but there's still some > work to do around device addressing/selection. > > Rob -- 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
