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

[Stephen Warren]

On 08/02/2012 02:31 AM, Lukasz Majewski wrote:
> On Wed, 01 Aug 2012 11:13:14 -0600
> Stephen Warren <swarren at wwwdotorg.org> wrote:
> 
>> 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".
> 
> I'm rather thinking of a U-boot command (as it is easier to integrate).
> The command would be "mmc boot <dev> <params .. boot partition>"
> 
> Although it is not yet implemented, it is on the top of mine "TO DO"
> list :-).

I guess I'm confused what that "boot" command would actually do then...
The only thing I can think that it might do is already covered by the
"mmc" command's partition parameter.

>>>> 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.
> 
> With the UMS you would see the whole mmc address space as one
> partition. Then you can use dd with several parameters to "dump" data
> to a specific LBA address. 
> 
> When correct MBR or GPT is present, then we can specify partitions to
> be accessed.
> 
>> 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.
> 
> I think that UMS solves this issue. However, correct me if I'm wrong.
> 
> Let's assume, that UMS causes host to see following partitions:
> sde: sde1 sde2 sde3 sde4 < sde5 .. sdeN >
> 
> Is the "mount -t vfat /dev/sde /mnt" not allowing access to the whole
> eMMC device (despite of the partitions)?

Again, this is confusing two different kinds of partitions.

There are HW-level partitions/regions/areas within the eMMC HW itself.
You need to send commands to the eMMC device to select whether
read/write commands act on the boot0/boot1/general*/user HW partition.

There are (or can be) SW-level partitions within any/all of those HW
partitions. This is the level at which an MBR/GPT partition would exist.

With DFU, I'd expect an alt setting for each of the HW partitions at least.

With UMS, I'd expect a device to appear for each of the HW partitions.
(these may show up as say /dev/sdb for boot0, /dev/sdc for boot1,
/dev/sdd for the user area). If an MBR/GPT is present within any of
those, Linux may then create a device for each SW partition, so e.g.
/dev/sdd1, /dev/sdd2, etc.