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
- 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".
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
