[U-Boot] [RFC PATCH 0/3] Implement "fastboot flash" for eMMC

[Steve Rae]

On 14-06-26 06:20 AM, Rob Herring wrote:
> On Wed, Jun 25, 2014 at 7:16 PM, Steve Rae <srae at 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 at 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".