On 08/02/2012 02:31 AM, Lukasz Majewski wrote:
On Wed, 01 Aug 2012 11:13:14 -0600 Stephen Warren swarren@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.