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?