Hi Steve,
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.)
http://lists.denx.de/pipermail/u-boot/2014-May/180468.htmlwhich I already attempted to implement (and abandoned):
As fair as I remember there are available methods to switch HW partitions (like mmc_access_part()).
- handling of partition names
http://lists.denx.de/pipermail/u-boot/2014-May/180292.htmlfor EFI Partitions, this did get accepted:So now I would propose two phases: (1) short term - get "fastboot flash" working (and "erase", and "oem format", etc.)
Would the short term solution allow writing fastboot only to eMMC or other media are going to be supported?
>> 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".
I will do my best to review your patches.