On Wed, Jun 25, 2014 at 7:16 PM, Steve Rae srae@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 srae@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.
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. So read and write are already pretty much generic, but there's still some work to do around device addressing/selection.
Rob