On 14-06-26 06:20 AM, Rob Herring wrote:
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
While I agree in general that to make everything generic is ideal, IMO, I don't think that there is a design or a roadmap to get us there yet I would suggest that any generic interface would also need to support: - handling of multiple HW partitions (0=USER 1-BOOT1 2=BOOT2 etc.) >> which I already attempted to implement (and abandoned): http://lists.denx.de/pipermail/u-boot/2014-May/180468.html - handling of partition names >> for EFI Partitions, this did get accepted: http://lists.denx.de/pipermail/u-boot/2014-May/180292.html So now I would propose two phases: (1) short term - get "fastboot flash" working (and "erase", and "oem format", etc.) >> I have code that works for eMMC device (and potentially for NAMD...) (2) longer term - define the "generic block device" (probably enhance "block_dev_desc_t" ?!?!?) and move the "short term solution" into this new design.
I will submit a "v2" to see if it will get accepted as part of the "short term solution".