Differences

This shows you the differences between two versions of the page.

doc:techref:flash.layout [2012/07/28 11:05]
orca
doc:techref:flash.layout [2013/04/11 12:00] (current)
osiixy
Line 1: Line 1:
====== The OpenWrt Flash Layout ====== ====== The OpenWrt Flash Layout ======
There are hard discs, which are considered block devices, and there is flash memory. There types of flash, like NOR flash, SLC NAND flash and MLC NAND flash.\\ There are hard discs, which are considered block devices, and there is flash memory. There types of flash, like NOR flash, SLC NAND flash and MLC NAND flash.\\
-If the flash chip (no matter what type) is connected directly with the SoC and has to be addressed directly by Linux, we call it **//"raw flash"//**.+If the flash chip (no matter what type) is connected directly with the [[http://en.wikipedia.org/wiki/System-on-a-chip|SoC]] and has to be addressed directly by Linux, we call it **//"raw flash"//**.
If the flash chip cannot be addressed directly by the OS (because there is an additional controller chip between flash chip and the SoC), we call it **//"FTL (Flash Translation Layer) flash"//**. Embedded systems almost exclusively use "raw flash", while USB memory sticks, almost exclusively use FTL flash! If the flash chip cannot be addressed directly by the OS (because there is an additional controller chip between flash chip and the SoC), we call it **//"FTL (Flash Translation Layer) flash"//**. Embedded systems almost exclusively use "raw flash", while USB memory sticks, almost exclusively use FTL flash!
- 
===== Partitioning of SquashFS-Images ===== ===== Partitioning of SquashFS-Images =====
-The flash chip on embedded systems is not accompanied by a controller chip, and thus are not //"FTL"//-devices but //"raw flash"//-devices. Storage space is treated and addressed as an [[doc:techref:MTD| MTD (Memory Technology Device)]] and special [[doc:techref:Filesystems]] are used. The available storage is not partitioned in the traditional way, where you store the data about the partitions in the [[wp>Master boot record|MBR]] and [[wp>Volume boot record|PBR]]s, but it is done in the Linux Kernel (and sometimes independently in the [[doc:techref:bootloader]] as well!). You simply define, that "partition kernel starts at offset x and ends at offset y. The advantage is, that later we can address these partitions by name, rather then specifying the precise start point of the data.+The flash chip on embedded systems is not accompanied by a controller chip, and thus are not //"FTL"//-devices but //"raw flash"//-devices. Storage space is treated and addressed as an [[doc:techref:MTD| MTD (Memory Technology Device)]] and special [[doc:techref:Filesystems]] are used. The available storage is not partitioned in the traditional way, where you store the data about the partitions in the [[wp>Master boot record|MBR]] and [[wp>Volume boot record|PBR]]s, but it is done in the Linux Kernel (and sometimes independently in the [[doc:techref:bootloader]] as well!). You simply define, that "partition **//kernel//** starts at offset x and ends at offset y". The advantage is, that later we can address these partitions by name, rather then specifying the precise start point of the data.
:!: The following table documents the layout of the [[toh:tp-link:TL-WR1043ND]] and is merely one **example**! Another, slightly different, example can be found on the wiki-page for the [[toh:d-link:DIR-300#flash.layout|DIR-300]]. So the layout does differ between the devices! Please see the wiki-page for a device, for information about its particular layout and simply check it yourself on your device. :!: The following table documents the layout of the [[toh:tp-link:TL-WR1043ND]] and is merely one **example**! Another, slightly different, example can be found on the wiki-page for the [[toh:d-link:DIR-300#flash.layout|DIR-300]]. So the layout does differ between the devices! Please see the wiki-page for a device, for information about its particular layout and simply check it yourself on your device.
Line 15: Line 14:
^ Layer2      |                              |  mtd1 **//kernel//** 1280KiB  |  mtd2 **//rootfs//** 6720KiB                          ||          | ^ Layer2      |                              |  mtd1 **//kernel//** 1280KiB  |  mtd2 **//rootfs//** 6720KiB                          ||          |
^ <color magenta>mountpoint</color>  |                              |                              |  <color magenta>''/''</color>                          ||          | ^ <color magenta>mountpoint</color>  |                              |                              |  <color magenta>''/''</color>                          ||          |
-^ filesystem  |                              |                              |  [[doc:techref:filesystems#mini_fo|mini_fo]]          ||          |+^ filesystem  |                              |                              |  [[doc:techref:filesystems#mini_fo|mini_fo]]/[[doc:techref:filesystems#overlayfs|overlayfs]]          ||          |
^ Layer3      |                              |                              |                |  mtd3 **//rootfs_data//** 5184KiB    |          | ^ Layer3      |                              |                              |                |  mtd3 **//rootfs_data//** 5184KiB    |          |
^ Size in KiB  |  128KiB                      |  1280KiB                      |  1536KiB        |  5184KiB                              |  64KiB  | ^ Size in KiB  |  128KiB                      |  1280KiB                      |  1536KiB        |  5184KiB                              |  64KiB  |
Line 21: Line 20:
^ <color magenta>mountpoint</color>  |  //none//                    |  //none//                    |  <color magenta>''/rom''</color>  |  <color magenta>''/overlay''</color>  |  //none//  | ^ <color magenta>mountpoint</color>  |  //none//                    |  //none//                    |  <color magenta>''/rom''</color>  |  <color magenta>''/overlay''</color>  |  //none//  |
^ filesystem  |  //none//                    |  //none//                    |  [[doc:techref:filesystems#SquashFS]]  |  [[doc:techref:filesystems#JFFS2]]  |  //none//  | ^ filesystem  |  //none//                    |  //none//                    |  [[doc:techref:filesystems#SquashFS]]  |  [[doc:techref:filesystems#JFFS2]]  |  //none//  |
 +
 +
 +Here is a LibreOffice Calc ODS for better understanding: [[http://ubuntuone.com/2aPBH9pwkxtYzy93S0cS1z]] .
==== Partitions ==== ==== Partitions ====
Line 55: Line 57:
-> [[doc:howto:user.beginner.fhs]] -> [[doc:howto:user.beginner.fhs]]
-**//''NOTE1''//:** If the Kernel was part of the SquashFS, we could not control where exactly on the flash it is written to (on which blocks it's data is contained). Thus we could not tell the bootloader to simply load and execute certain blocks on the flash storage, but would have to address it with path and filename. Now this would not be bad, but in order to that the bootloader would have to understand the SquashFS filesystem, which it does not. The embedded bootloader we utilize with OpenWrt generally have no concept of filesystems, thus they cannot address files by path and filename. They pretty much assume that the start of the trx data section is executable code.\\ +**//''NOTE1''//:** If the Kernel was part of the SquashFS, we could not control where exactly on the flash it is written to (on which blocks its data is contained). Thus we could not tell the bootloader to simply load and execute certain blocks on the flash storage, but would have to address it with path and filename. Now this would not be bad, but in order to that the bootloader would have to understand the SquashFS filesystem, which it does not. The embedded bootloaders we utilize with OpenWrt generally have no concept of filesystems, thus they cannot address files by path and filename. They pretty much assume that the start of the trx data section is executable code.\\ 
-**//''NOTE2''//:** the denomination ''"firmware"'' usually is used for the entire data on the flash comprising the boot loader and any other data necessary to operate the device, such as ART, NVRAM, FIS, etc, but we also use it to only name the parts that are being rewritten. Don't let this confuse you ;-)\\+**//''NOTE2''//:** The denomination ''"firmware"'' usually is used for the entire data on the flash comprising the boot loader and any other data necessary to operate the device, such as ART, NVRAM, FIS, etc, but we also use it to name only the parts that are being rewritten. Don't let this confuse you ;-)\\
Line 153: Line 155:
  * [[doc/techref/header]]   * [[doc/techref/header]]
  * [[doc/howto/obtain.firmware.generate]] If you want to read about the **Image Generator**, go back to [[doc:howto:obtain.firmware]] and choose the second way.   * [[doc/howto/obtain.firmware.generate]] If you want to read about the **Image Generator**, go back to [[doc:howto:obtain.firmware]] and choose the second way.
 +  * About [[http://skaya.enix.org/wiki/FirmwareFormat|Broadcom Firware Format]]

Back to top

doc/techref/flash.layout.1343466327.txt.bz2 · Last modified: 2012/07/28 11:05 by orca