Search by Tags

Flash Layout (Linux)


Article updated at 09 Apr 2021
Compare with Revision


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.

Toradex Easy Installer

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.

Linux Command-line

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).

Legacy BSP 2.x - NVIDIA Tegra based Hardware

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).

Apalis/Colibri T30 eMMC resp. optional SD Card Boot (Colibri T20 only)

The partitioning is done during recovery mode flashing by Fastboot/NvFlash based on the following configuration files contained in our BSP image packages:


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/ is run which increases the partition size to its full extend.

Adding Partition

Edit the configuration file and add your custom UDA partition between the APP and GPT one as follows:

#previously 0x808


# Extensible Firmware Interface (EFI) Secondary GUID Partition Table (GPT)

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 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