Hi Steve, > > > On 14-06-26 06:20 AM, Rob Herring wrote: > > On Wed, Jun 25, 2014 at 7:16 PM, Steve Rae <s...@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 <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
