[U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command

[Stephen Warren <swarren@wwwdotorg.org>]

On 08/01/2012 01:16 AM, Lukasz Majewski wrote:
> Hi Stephen Warren,
> 
>> On 07/31/2012 12:37 AM, Lukasz Majewski wrote:
>>> Support for u-boot's "dfu <interface> <dev> [list]" command.
>>
>>> +U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
>>> +	"Device Firmware Upgrade",
>>> +	"<interface> <dev> [list]\n"
>>> +	"  - device firmware upgrade on a device <dev>\n"
>>> +	"    attached to interface <interface>\n"
>>> +	"    [list] - list available alt settings"
>>> +);
...
>> Somewhat related to this, it looks like the eMMC support doesn't allow
>> the HW partition to be specified; it would be nice to expose alt
>> settings for all of:
>>
>> a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if
>> present, the user area, maybe the replay block)
> 
> I'm fully aware of this problem.
> In the eMMC case, the access to boot partitions will be served by
> defining special alt settings for DFU.
> 
> Those altsettings will be defined as follows:
> -a[N] boot0
> -a[N+1] boot1
> 
> Prerequisite for this functionality is support of "boot"
> command, which will allow switching of the MMC available address spaces
> (e.g. between boot0/boot1 and user accessible space).

Is this "boot" command a DFU protocol command, or a U-Boot command-line
command? I note that the U-Boot command-line already allows HW partition
selection using an additional parameter to "mmc" - "mmc dev
$mmc_device_id $partition_id".

>> b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1
>> write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs
>> 2*boot_size..end_of_device write to user area for example).
> 
> Access to partitions will be done differently. I assume that each eMMC
> memory (the user accessible part) will be equipped with MBR or GPT
> definition.

That's a different kind of partition though.

In general, there's no need for the eMMC device to contain any kind of
standardized SW-level partition table. On Tegra, the boot ROM can boot
directly from an eMMC device, and that requires raw data in the
partitions, not a standardized SW partition table.

> For this reason I'm now developing the USB Mass Storage (UMS) gadget to
> export eMMC to host PC.
> This solves the problem with accessing separate partitions. 

OK, if the raw eMMC device is exposed using USB storage, we should be
able to dd directly to it and the presence-or-lack-thereof of any
MBR/GPT wouldn't even be relevant.

It'd still be useful to have a linearized view of the flash that
concatenated all the HW partitions into a single raw device, but I guess
an alt setting for that probably could be added later.

> Please also be aware, that DFU shall be used only for relatively small
> files (due to small EP0 bandwidth).
> 
> Large files shall be copied with UMS.

Oh, didn't know that. Just out of curiosity, are you thinking of
implementing that too?