From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Rae Date: Thu, 26 Jun 2014 10:18:56 -0700 Subject: [U-Boot] [RFC PATCH 0/3] Implement "fastboot flash" for eMMC In-Reply-To: References: <1403211128-19631-1-git-send-email-srae@broadcom.com> <20140620081842.50471ae4@amdc2363> <201406200832.19841.marex@denx.de> <53A4ADE7.2080306@broadcom.com> <20140623145858.5bef59fe@amdc2363> <53A873E4.7040008@broadcom.com> <53AB666B.3020903@broadcom.com> Message-ID: <53AC5600.7040900@broadcom.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 14-06-26 06:20 AM, Rob Herring wrote: > On Wed, Jun 25, 2014 at 7:16 PM, Steve Rae wrote: >> Rob, >> >> >> On 14-06-25 06:59 AM, Rob Herring wrote: >>> >>> On Mon, Jun 23, 2014 at 1:37 PM, Steve Rae 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".