On 08/02/2012 02:31 AM, Lukasz Majewski wrote: > On Wed, 01 Aug 2012 11:13:14 -0600 > Stephen Warren <swar...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot