On Wednesday 30 March 2011, Andrei Warkentin wrote: > On Wed, Mar 30, 2011 at 7:03 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > Since eMMC 4.41, you can create "general purpose" partitions (up to > 4), which will be carved out of the user partition, and can be used in > any way possible, thus potentially holding file system partitions. My feeling is that these should be separate from the boot partition. It could probably be done using a new fs/partitions/mmc.c file that directly interacts with the mmc layer instead of looking at the MS-DOS master boot record. That way, you could define the same partitions (mmcblk0p1, ...) using a different method. It also requires a user interface that a new mmc-fdisk tool can talk to, in order to modify the partition table, not sure if it's possible to use the BLKPG ioctl for this. > There is also the "Replay Protected Memory Block" device partition, > which is not able to host a file system in the normal sense (because > layer over the MMC block transfer protocol is a "replay protected > transaction" protocol, which could be used by a user-mode application > directly reading/writing from /dev/block/mmcblkXXX). Ok. That sounds like a use case for an ioctl interface then, if we even want to expose it. > > * What devices specifically have these new partitions? Only eMMC 4.4 > > or also other versions? > > > > Boot partitions are available in 4.3. The other ones (4 general > purpose ones, rpmb since 4.41). ok. > Unfortunately, since the SD spec is proprietary, I have no way of > confirming whether the SD device partitioning (AFAIK there is a > concept of boot partitions for eSD) works the same way or not, so I > was maximally safe in supporting MMC device partitioning. The public parts of the SD standard specifically require MS-DOS partitioning to be used, so I assume that there is no internal method in addition. They also describe the presence of a "secure area" that can only be accessed after authentication. This could use a similar method as the boot partition, but it's unclear to me whether that is something that anyone is interested in. > > * How does a user identify which hardware partition corresponds to > > a given block device and vice versa? > > Right now, you would just need to know. With postfixes like > mmcblk0b0/mmcblk0g0 you would be able to tell the device partitions > apart from the main mmcblk0. Regarding the naming, I would not use a trailing zero, but it's probably a subjective thing. The other names I could imagine for the boot partition of mmc 0 are mmcboot0, mmcblk0b or mmcblk0boot. I also mentioned the character device option. Yet another way would be to add a sysfs_bin_attribute that corresponds to the boot partition and can be accessed using read/write, like we do for PCI resources. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
