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

[Lukasz Majewski]

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 :-).

> 
> >> 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)?

> 
> > 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?

The USB Mass Storage gadget is now working with the g_dnl composite
gadget as a f_ums function.

Unfortunately it is not polished enough to be posted to ML.

I'd prefer that DFU related patches would be pulled to ML first.
Afterwards I would post the UMS function.

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group