Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| docs:techref:flash.layout [2023/10/18 00:37] – [Partitioning of NAND flash-based devices] add kernel volume name lanchon | docs:techref:flash.layout [2023/10/18 09:06] (current) – [NOR flash vs NAND flash] lanchon | ||
|---|---|---|---|
| Line 30: | Line 30: | ||
| * Some partitions are used as large files that can only be read or written completely and in one go. This is the case of raw bootloaders and kernels in MTD partitions. For these partitions, bad blocks are simply skipped during both reads and writes. Because new defects almost exclusively develop during erase and writes, once written these partitions are mostly trusted to be readable forever. (But newer devices tend to duplicate these partitions to minimize failures.) | * Some partitions are used as large files that can only be read or written completely and in one go. This is the case of raw bootloaders and kernels in MTD partitions. For these partitions, bad blocks are simply skipped during both reads and writes. Because new defects almost exclusively develop during erase and writes, once written these partitions are mostly trusted to be readable forever. (But newer devices tend to duplicate these partitions to minimize failures.) | ||
| * Some partitions are used as large files that can only be written completely and in one go, but can be read in a random access fashion. This is the case of raw read-only file systems (such as squashfs) in MTD partitions. For these partitions, bad blocks are simply skipped during writes, and a kernel driver is used to read them. The driver reads the complete partition during setup skipping bad blocks, and builds a logical-block-to-flash-block table in RAM to be able to later access the partition random-access. | * Some partitions are used as large files that can only be written completely and in one go, but can be read in a random access fashion. This is the case of raw read-only file systems (such as squashfs) in MTD partitions. For these partitions, bad blocks are simply skipped during writes, and a kernel driver is used to read them. The driver reads the complete partition during setup skipping bad blocks, and builds a logical-block-to-flash-block table in RAM to be able to later access the partition random-access. | ||
| - | * Some large partitions are used as containers for other compartmentalized data. Note that the amount of bad blocks in a certain partition is a-priory unknown, and thus a raw partition size cannot be taken as the its usable size. For smaller partitions this effect is amplified: although there is a manufacturer-defined limit on the number of bad blocks in a flash, nothing precludes all bad blocks from residing in the same partition. Thus, for guaranteed operation, a system designer should allow _in each and every partition_ | + | * Some large partitions are used as containers for other compartmentalized data. Note that the amount of bad blocks in a certain partition is a-priory unknown, and thus a raw partition size cannot be taken as the its usable size. For smaller partitions this effect is amplified: although there is a manufacturer-defined limit on the number of bad blocks in a flash, nothing precludes all bad blocks from residing in the same partition. Thus, for guaranteed operation, a system designer should allow //in each and every partition// |
| * Some UBI volumes are used as large files that can only be read or written completely and in one go. This is the case of kernels in UBI partitions. | * Some UBI volumes are used as large files that can only be read or written completely and in one go. This is the case of kernels in UBI partitions. | ||
| * Some UBI volumes are used as large files that can only be written completely and in one go, but can be read in a random access fashion. This is the case of read-only file systems (such as squashfs) in UBI partitions. For these volumes, an ubiblock kernel device is used to read them: the device emulates a read-only block device and maintains a logical-block-to-flash-block table in RAM to be able to access the volume random-access. | * Some UBI volumes are used as large files that can only be written completely and in one go, but can be read in a random access fashion. This is the case of read-only file systems (such as squashfs) in UBI partitions. For these volumes, an ubiblock kernel device is used to read them: the device emulates a read-only block device and maintains a logical-block-to-flash-block table in RAM to be able to access the volume random-access. | ||
| Line 52: | Line 52: | ||
| ^ Layer1 | bootloader \\ partition(s) | ^ Layer1 | bootloader \\ partition(s) | ||
| ^ Layer2 |::: | ^ Layer2 |::: | ||
| - | ^ Layer3 |::: | + | ^ Layer3 |::: |
| ^ Layer4 |::: | ^ Layer4 |::: | ||
| Line 134: | Line 134: | ||
| Some NAND devices contain bootloaders that do not understand UBI partitions and thus cannot boot kernels contained in UBI volumes. The generic flash layout for these devices is: | Some NAND devices contain bootloaders that do not understand UBI partitions and thus cannot boot kernels contained in UBI volumes. The generic flash layout for these devices is: | ||
| ^ Layer0 | raw flash ||||||| | ^ Layer0 | raw flash ||||||| | ||
| - | ^ Layer1 | bootloader \\ partition(s) | + | ^ Layer1 | bootloader \\ partition(s) |
| ^ Layer2 |::: | ^ Layer2 |::: | ||
| ^ Layer3 |::: | ^ Layer3 |::: | ||
| Line 141: | Line 141: | ||
| ^ Layer0 | raw flash |||||| | ^ Layer0 | raw flash |||||| | ||
| ^ Layer1 | bootloader \\ partition(s) | ^ Layer1 | bootloader \\ partition(s) | ||
| - | ^ Layer2 |::: | + | ^ Layer2 |::: |
| ^ Layer3 |::: | ^ Layer3 |::: | ||
| Line 147: | Line 147: | ||
| - | ==== Reserving UBI space of user-defined UBI volumes ==== | + | ==== Reserving UBI partition |
| For [[: | For [[: | ||
| Line 159: | Line 159: | ||
| The relevant bootloader variable can be read with this command: | The relevant bootloader variable can be read with this command: | ||
| - | **'' | + | < |
| + | fw_printenv -n rootfs_data_max | ||
| + | </ | ||
| Set with: | Set with: | ||
| - | **'' | + | < |
| + | fw_setenv rootfs_data_max < | ||
| + | </ | ||
| And cleared with: | And cleared with: | ||
| - | **'' | + | < |
| + | fw_setenv rootfs_data_max | ||
| + | </ | ||
| Note that sysupgrade will fail if there is not enough space in the UBI partition to create **'' | Note that sysupgrade will fail if there is not enough space in the UBI partition to create **'' | ||
| - | For example, on an Askey RT4230W REV6 router with 512 MiB flash, the **'' | + | ==== Example: Creating |
| + | In an Askey RT4230W REV6 router with 512 MiB flash, the **'' | ||
| + | |||
| + | < | ||
| + | root@router: | ||
| + | Volume ID: 2 (on ubi0) | ||
| + | Type: dynamic | ||
| + | Alignment: | ||
| + | Size: 3086 LEBs (391847936 bytes, 373.6 MiB) | ||
| + | State: | ||
| + | Name: rootfs_data | ||
| + | Character device major/ | ||
| + | </ | ||
| + | |||
| + | Given that this volume is routinely wiped by sysupgrade, storing any remotely valuable files here would be ill-advised. For this router you might choose to limit **'' | ||
| + | |||
| + | First you need to limit **'' | ||
| + | |||
| + | < | ||
| + | root@router: | ||
| + | </ | ||
| + | |||
| + | Next do a sysupgarde (even if no upgrade is needed) to resize **'' | ||
| + | |||
| + | < | ||
| + | root@router: | ||
| + | Volume ID: 2 (on ubi0) | ||
| + | Type: dynamic | ||
| + | Alignment: | ||
| + | Size: 1058 LEBs (134340608 bytes, 128.1 MiB) | ||
| + | State: | ||
| + | Name: rootfs_data | ||
| + | Character device major/ | ||
| + | </ | ||
| + | |||
| + | You just freed 240+ MiB in the UBI partition. Next, you could manually create, format, and mount a new UBIFS volume. But OpenWrt has a tool to automate this, so let's use it. | ||
| + | |||
| + | Connect the router to the internet if necessary, and use Luci to install package '' | ||
| + | |||
| + | Now check the installation (sizes are in bytes): | ||
| + | |||
| + | < | ||
| + | root@router: | ||
| + | root@router: | ||
| + | 422576128 | ||
| + | root@router: | ||
| + | 253317120 | ||
| + | </ | ||
| + | |||
| + | Create and enable the '' | ||
| + | |||
| + | < | ||
| + | root@router: | ||
| + | Volume ID 4, size 1586 LEBs (201383936 bytes, 192.0 MiB), LEB size 126976 bytes (124.0 KiB), dynamic, name " | ||
| + | root@router: | ||
| + | root@router: | ||
| + | extra rw 201383936 | ||
| + | root@router: | ||
| + | /dev/ubi0_4 on / | ||
| + | </ | ||
| + | |||
| + | You do not like the default mount path ('' | ||
| + | |||
| + | < | ||
| + | root@router: | ||
| + | </ | ||
| + | |||
| + | Finally reboot and check that your new volume is mounted where you want it: | ||
| + | |||
| + | < | ||
| + | root@router: | ||
| + | /dev/ubi0_4 on /extra type ubifs (rw, | ||
| + | </ | ||
| ===== MTD (Memory Technology Device) and MTDSPLIT ===== | ===== MTD (Memory Technology Device) and MTDSPLIT ===== | ||