The flash layout defines the partitioning in which components of an Embedded Linux image are stored, as well as how much space there is for user application. This article provides instructions on how you can get this information.
All our new Computer on Modules, including all of our i.MX-based SoMs, are supported by the Toradex Easy Installer. This software has a configuration file named image.json which contains information about the image partitioning scheme.
To find the flash layout for specific hardware and software, read the corresponding image.json. Consult the Configuration Files reference for details.
On the command-line, you can find some extra information with regular Linux commands as fdisk and df. The results may vary from raw NAND- and eMMC-based SoMs, since they use different software stacks for the management of the flash.
Raw NAND uses the Unsorted Block Images (UBI) and UBIFS. There is plenty of documentation about both, and you must read it:
The command-line tools for those are the mtd-utils. Check the links above for more information about it.
eMMC uses the block device stack (the same one used for HDD and SSD) and our BSP uses the EXT-4 filesystem. There is plenty of documentation about it on the internet, being a good starting point in our article eMMC (Linux).
Note: The information in this article pre-dates our move to cbootimage/tegrarcm and is no longer applicable for BSPs after V2.3 Beta 2 (T30) resp. V2.3 (T20).
The partitioning is done during recovery mode flashing by Fastboot/NvFlash based on the following configuration files contained in our BSP image packages:
apalis-t30_bin/emmc-flash.cfg
colibri-t20_bin/lnx_hsmmc.cfg
colibri-t30_bin/emmc-flash.cfg
NVIDIA uses a custom partitioning layout that only packs the root file system into a regular GPT (GUID Partition Table). The primary GPT is usually at a offset of 512 KBytes, but this area is used by the boot ROM for the BCT (Boot Configuration Table), PT (Partition Table) resp. boot loader, hence a custom offset is used (see gpt gpt_sector=<offset> kernel boot argument). The secondary GPT is at the end of the block device.
To avoid having to download lots of empty space during flashing our update script calculates a minimal size and generates an ext3 partition accordingly. During the first boot, a custom resizing script (/usr/sbin/resizefs.sh) is run which increases the partition size to its full extend.
Edit the configuration file and add your custom UDA partition between the APP and GPT one as follows:
...
[partition]
name=APP
id=9
type=data
allocation_policy=sequential
filesystem_type=basic
size=2048000000
#previously 0xFFFFFFFFFFFFFFFF
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
#previously 0x808
percent_reserved=0
filename=APP.ext3
[partition]
name=UDA
id=10
type=data
allocation_policy=sequential
filesystem_type=basic
size=0xFFFFFFFFFFFFFFFF
file_system_attribute=0
partition_attribute=0
allocation_attribute=0x808
percent_reserved=0
# Extensible Firmware Interface (EFI) Secondary GUID Partition Table (GPT)
[partition]
name=GPT
id=11
type=GPT
allocation_policy=sequential
filesystem_type=basic
file_system_attribute=0
partition_attribute=0
allocation_attribute=8
percent_reserved=0
Please note one NvFlash bug setting that last user partitions last sector equal to the secondary GPT equivalent at the very end which will cause the secondary GPT to be overwritten if not paying careful attention to this. Our resize script usually runs during the first boot and takes care of this but adding your own partition you probably want to adjust that behavior.
Output from Fastboot/NvFlash during flashing:
...
SD Alloc Partid=9, start sector=7296,num=1000000
SD Alloc Partid=10, start sector=1007296,num=982592
SD Alloc Partid=11, start sector=1989888,num=0
...
Format partition APP
Region=4 SD Erase start 512B-sector=29232,512B-sector-num=3999912
Format partition UDA
Region=4 SD Erase start 512B-sector=4029200,512B-sector-num=3930304
Format partition GPT
...
The first partition can now be resized without any danger:
root@colibri-t20:~# resize2fs /dev/mmcblk0p1 3999912s
resize2fs 1.42.7 (21-Jan-2013)
Filesystem at /dev/mmcblk0p1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/mmcblk0p1 to 499989 (4k) blocks.
The filesystem on /dev/mmcblk0p1 is now 499989 blocks long.
According to http://en.wikipedia.org/wiki/GUID_Partition_Table the primary and secondary GPT are 32 (512 byte) blocks each. During the creation of the last file system one has to subtract those (divide by 8 due to 512 byte eMMC/SD vs. 4096 byte ext3 block size):
(3930304-32)/8 = 491284
Creating the custom ext3 file system without overwriting the secondary GPT. The block size of 4096 is the default for partitions bigger than 512MB, but set it explicitly to avoid any issues. (careful with ext4 due to a bug in NVIDIA's Linux kernel):
root@colibri-t20:~# mkfs.ext3 -b 4096 /dev/mmcblk0p2 491284
...
After a reboot that partition even automatically gets mounted to /media/mmcblk0p2 thanks to udev:
root@colibri-t20:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 1967652 291408 1576932 16% /
devtmpfs 176420 4 176416 0% /dev
tmpfs 176420 0 176420 0% /dev/shm
tmpfs 176420 272 176148 0% /run
tmpfs 176420 0 176420 0% /sys/fs/cgroup
tmpfs 176420 4 176416 0% /tmp
tmpfs 176420 0 176420 0% /media/ram
tmpfs 176420 0 176420 0% /var/volatile
/dev/mmcblk0p2 1934248 37284 1798708 2% /media/mmcblk0p2
