eMMc partitioning question

Hi Jake,

Assuming you have already booted from SD card and have access to the board's console, here are the required steps:

1. The eMMC is /dev/mmcblk1. Format it this way:
1.01. fdisk /dev/mmcblk1
1.02. o - this clears the existing partitions
1.03. p - this lists all partition tables on the card (there should be none)
1.04. n - create a new partition
1.05. p - primary partition
1.06. 1 - partition number
1.07. 2048 - default value for the first sector
1.08. +16M - last sector / partition size
1.09. t - change the partition type (select partition 1)
1.10. e - change tha partition type to "W95 FAT16 (LBA)"
1.11. a - set the bootable flag for the selected partition (1)
1.12. n - create a new partition
1.13. p - primary partition
1.14. 2 - partition number
1.15. hit Enter to choose the default (next available) value for the first sector
1.16. hit Enter to choose the default (last) value for the last sector
1.17. p - this lists all partition tables on the card (there should be two)
1.18. w - write all the above changes to disk
1.19. umount /dev/mmcblk1p1; mkfs.vfat -F 16 /dev/mmcblk1p1 - format the first partition
1.20. umount /dev/mmcblk1p2; mkfs.ext4 /dev/mmcblk1p2 - format the second partition

2. Copy the {MLO,u-boot.img,uEnv.txt} files to the first partition:
# mkdir boot
# mount /dev/mmcblk1p1 boot
# cp {MLO,u-boot.img,uEnv.txt} boot
# umount boot

3. Copy the root file system to the second partition:
# mkdir root
# mount /dev/mmcblk1p2 root
# tar -xf tisdk-rootfs-image-am335x-evm.tar.gz -C root
# umount root

4. Shutdown the BBB, remove the SD card and start it from the eMMC.

Best regards,
Miroslav

Excellent - but - my code does not include fdisk, how would I build fdisk for the am335x target?

Thanks,

Jake

Thank you Miroslav - this basically solves our problem.

-Jake

fdisk is not capable of performing eMMC native partitioning, it just creates a "HD-like" partition table on the eMMC user partition.  For most purposes this is fine.  Note in particular that the ROM bootloader will only boot from the eMMC user partition, it does not use eMMC boot mode.

You can still access the (fixed-size) eMMC-native boot0 and boot1 partitions in linux, which may be useful to retain some data even if the "whole device" (in practice: the whole user partition) is reflashed. They may also have enhanced reliability compared to the user partition. They appear as separate block devices, /dev/mmcblk0boot{0,1}.  Presumably if the eMMC has GP partitions, those will also show up, though I haven't checked whether linux supports these yet (it would be easy to support them though since accessing them is similar to the boot partitions).

Note however that eMMC native partitioning (splitting off parts of the user partition as gp0-gp3) is one time programmable only, there's no way to change or undo it afterwards. This is probably part of why it's not very popular to use that functionality. I have no idea what tool can be used to perform it.

I'm not sure whether you can (currently) access the RPMB on linux. Access to it follows a very specific protocol that is unlike accessing a normal partition.

Thanks for the care to reply, using mmcutils to partition the GP[0-3], even RPMB,not quite screwed them yet,for the lifetime though :-) .

I agree over the part that linux recognizes the boot1 and boot2 partitions of the emmc, shame to say that such an important module left in the darkness.

I place the blame mostly with JEDEC: making settings one-time-programmable, especially in a soldered-on chip, is very developer-hostile. And I sincerely doubt it would be technically difficult for an eMMC to allow repartitioning (especially since partitioning is allowed to cause total loss of existing data).

Another thing sorely missing is a global "disallow any OTP until next power on" bit. They do encourage disabling any OTP protection features you don't need, to avoid them from being set accidently or maliciously, but such disabling is in all cases also OTP. This means that if you want to keep the option of using such a feature some time in the future, you have no safeguard to avoid it from being set accidently or maliciously until you make this final decision.

To be honest, the eMMC standard just sucks. It seems to lack any kind of careful design process or overall vision.

For reference, a list of OTP settings in eMMC v4.41 and v4.51 (which seem to be the most common versions currently), and whether there's any way to prevent them from being programmed. Note that in nearly all cases, if there is any way to prevent programming the setting, it is by perm-disabling, which is itself an OTP setting which cannot be prevented (with exception of the boot partition write-protect in v4.51).

(Disclaimer: I make no guarantee that this list is correct of course. The relevant standards can be downloaded on the JEDEC website after free registration.)

• Permanent write-protect of all partitions
  • Can be perm-disabled
• Other OTP fields of csd (file_format_grp, file_format, copy).  I'm not sure anything cares about these.
• Permanent write-protect of a WP-group (a chunk of user partition, size depends on the eMMC part used, but is for example 4 MB for the ones used in the beaglebone black rev C).
  • Can be perm-disabled (does not affect existing WP-groups)
• [v4.51] Release of a WP-group (becomes permanently unusable)
• Partitioning, which includes (programmed together, all at once): sizes and attributes (enhanced or [v4.51] extended) of GP partitions, offset and size of enhanced area of user partition, reliability settings of user and GP partitions.
• Perm-disabling password-based locking of the user partition
  • Can only be prevented by using the feature (i.e. setting a password)
• Setting the RPMB authentication key
• Perm-enabling secure bad block retirement
• Perm-disabling ability to perform firmware updates
• Perm-enabling or perm-disabling hardware reset pin. (Pin is disabled until final decision is made.)
• Permanent write-protect of boot mode configuration
• Permanent write-protect of both boot partitions (or [v4.51] one of the boot partitions)
  • Can be perm-disabled
  • [v4.51] Both permanent write-protect and perm-disable thereof can be prevented until next power-on since the BOOT_WP register "can only be written once per power cycle".
• Perm-enabling the "background operations handshake" (?!? An OS would probably want this enabled, but a bootloader would probably want this disabled...)
• [v4.51] Disabling sector size emulation; only applies to devices with 4 KB native sector size.

Other notes:

Password-based user partition lock is normally merely non-volatile and can be force-unlocked by erasing the whole user partition.  But, it is not clear what happens if you attempt force-unlock when any WP-group is permanently locked (i.e. whether they are simply skipped during erasure, or whether the erase fails and you permanently lose access to the user partition).

The total number of successful writes to RPMB is limited to 2^32-1 (due to the write counter), but writes need to be authenticated.

[v4.51] Periodic wakeup interval is non-volatile and may only be decreased, although it's not clear whether this is enforced.