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

[Lukasz Majewski]

Hi Steve,

> 
> 
> 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

As fair as I remember there are available methods to switch HW
partitions (like mmc_access_part()).

> - 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.)

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.

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group