User Tools

Site Tools


doc:techref:flash.layout

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
doc:techref:flash.layout [2013/02/06 17:20]
buntalo
doc:techref:flash.layout [2017/05/06 14:02] (current)
lololo rm stuff
Line 1: Line 1:
 +====== The OpenWrt Flash Layout ======
 +The embedded devices (routers and such) OpenWrt/​LEDE (Linux Embedded Development Environment) has mainly targeted since its inception, use flash memory as the form of non-volatile memory for the persistent storage of the firmware and its configuration.\\
 +
 +===== Types of flash memory =====
 +
 +==== Non-mechanical wear ====
 +Moving parts are prone to [[wp>​wear]] (german: [[wpde>​Verschleiß]]) and experience all sorts of "​mechanical breakage/​mechanical failure"​. But how can a non-moving part possibly break? Possibly by [[wp>​electromigration]],​ by [[wp>​Whisker (metallurgy)|whisker growth]], etc.
 +
 +Non-mechanical wear does not only occur when flash memory is erased!
 +
 +| {{:​meta:​icons:​tango:​dialog-information.png?​nolink}} | 1. Flash memory is more likely to experience failure then a [[wp>​hard disk drive (HDD)]] (the ones with the platters rotating at 5400–15000 [[wp>​Revolutions per minute|RPM]])\\ 2. Some types of flash memory seem to experience more non-mechanical wear then other types\\ 3. How do we deal with failure? |
 +
 +
 +==== Host-managed vs. self-managed ====
 +Based on how the flash memory chip is connected with the [[doc/​hardware/​soc|SoC]] (i.e. the "​host"​) we at OpenWrt distinguish between **//"​raw flash"//​** or **//"​host-managed"//​** and **//"​FTL (Flash Translation Layer) flash"//​** or **//"​self-managed"//​**:​ in case the flash memory chip is connected directly with the SoC we call it "raw flash" / "​host-managed"​ and in case there is an additional controller chip between the flash memory chip and the SoC, we call it "FTL flash" / "​self-managed"​. Primarily the controller chip does [[wp>​wear-leveling]] and manages known bad blocks, but it may do other stuff as well. The flash memory cannot be accessed directly, but only through this controller. The controller has to be considered a [[wp>​black box]].
 +
 +| {{:​meta:​icons:​tango:​dialog-information.png?​nolink}} | Embedded systems almost exclusively use "raw flash",​ while [[wp>​Solid-state drive|solid-state drives (SSDs)]] and USB memory sticks, almost exclusively use "FTL flash"​!\\ |
 +
 +
 +==== NOR flash vs NAND flash ====
 +Additionally we at OpenWrt distinguish between the two basic types of flash memory: [[wp>​Flash_memory#​NOR_flash|NOR flash]] and [[wp>​Flash_memory#​NAND_flash|NAND flash]].\\
 +
 +"Raw NOR flash" in typical routers is generally small (4 MiB – 16 MiB) and __error-free__,​ i.e. there cannot be bad erase blocks. Because raw NOR flash is error-free, the installed file system(s) do not need to take bad erase blocks into account, and neither SquashFS nor JFFS2 do! The combination of OverlayFS with SquashFS and JFFS2 has been the default OpenWrt setup since the beginning, and it works flawlessly on "raw NOR flash"​.
 +
 +"Raw NAND flash" in typical routers is generally larger (32 MiB – 256 MiB) and __not error-free__,​ i.e. it may contain bad erase blocks. A solution to deal with bad erase blocks comprises three provisions:
 +
 +  - the manufacturer of the "raw NAND flash" has to guarantee that certain erase blocks are error-free:
 +    * namely the one(s) which the bootloader is to be written to
 +    * but also the ones which the Linux kernel and the SquashFS are to be written to, because the firmware image file is generated on some desktop computer, that cannot know which erase blocks of the "raw NAND flash" of the device are bad.
 +  - the [[doc/​howto/​obtain.firmware.generate|OpenWrt Firmware Generator]] has be constrained to build only file sizes that are equal or smaller then the size of the area of the "raw NAND flash",​ that consists of guaranteed error-free erase blocks.
 +  - OpenWrt would replace JFFS2 with [[doc:​techref:​filesystems#​UBIFS|UBIFS]],​ and the entire area of the "raw NAND flash",​ that consists of potentially bad erase blocks, would be written to exclusively from an installed OpenWrt system through UBIFS.
 +
 +| {{:​meta:​icons:​tango:​dialog-information.png?​nolink}} | Older routers generally have "raw NOR flash" but many newer routers have "raw NAND flash"​. |
 +
 +
 +==== MLC vs. SLC flash ====
 +We can further distinguish between [[wp>​Multi-level cell|multi-level cell (MLC)]] and single-level cell (SLC) flash…
 +
 +
 +===== Partitioning of the Flash =====
 +Almost all embedded systems contain //"raw flash"//​-chips. 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!). It's simply defined, that "//​partition **''​kernel''​** starts at offset ''​x''​ and ends at offset ''​y''//"​. Using names allows convenient addressing of partitions by name instead of giving the start offset over and over again.
 +
 +The generic Flash layout is:
 +^ Layer0 |  raw flash  ||||||
 +^ Layer1 |  bootloader \\ partition(s) ​ |  optional \\ SoC \\ specific \\ partition(s) ​ |  OpenWrt firmware partition ​ |||  optional \\ SoC \\ specific \\ partition(s) ​ |
 +^ Layer2 |:::​|:::​| ​ Linux Kernel ​ |  **''​rootfs''​** \\ mounted: "''/''",​ [[doc:​techref:​filesystems#​overlayfs|OverlayFS]] with ''/​overlay'' ​ ||:::|
 +^ Layer3 |:::​|:::​|:::​| ​ **''/​dev/​root''​** \\ mounted: "''/​rom''",​ [[doc:​techref:​filesystems#​SquashFS|SquashFS]] \\ size depends on selected packages ​ |  **''​rootfs_data''​** \\ mounted: "''/​overlay''",​ [[doc:​techref:​filesystems#​SquashFS|JFFS2]] \\ "​free"​ space  |:::|
 +
 +Many newer devices share this scheme, but the flash layout can differ between the devices! Mostly minor details slightly differ concerning U-Boot and SoC specific firmware images. Please see the wiki pages for each SoC and devices for information about a particular layout. In case the flash layout differs for your device please update the wiki pages.\\
 +Here are some examples how it looks on actual devices:
 +
 +=== Example 1: TP-Link TL-WR1043ND ===
 +[[doc:​hardware:​soc:​soc.qualcomm|Qualcomm Atheros]]-based [[toh:​tp-link:​TL-WR1043ND]]. Somebody also provided a [[https://​web.archive.org/​web/​20131021013058/​http://​ubuntuone.com/​2aPBH9pwkxtYzy93S0cS1z|LibreOffice Calc ODS]].
 +
 +SquashFS-Images are suitable for devices with //"raw NOR flash memory"//​-chips and it is not recommended to install them onto devices with //"raw NAND flash memory"//​-chips. SquashFS-Images comprise both, a SquashFS partition and an JFFS2 partition. JFFS2-Images omit the SquashFS partition.
 +
 +^   ​TP-Link WR1043ND ​ Flash Layout ​          ​^^^^^^
 +^ Layer0 ​      ​| ​                      raw NOR flash memory chip (m25p80 [[wp>​Serial Peripheral Interface Bus|spi]]0.0:​ m25p64) 8192 KiB ​                                                                     |||||
 +^ Layer1 ​      ​| ​ mtd0 **//​u-boot//​** 128 KiB ​ |  mtd5 **//​firmware//​** 8000 KiB ​                                     |||    mtd4 **//art//** 64 KiB ​ |
 +^ Layer2 ​      ​| ​                             |  mtd1 **//​kernel//​** 1280 KiB ​ |  mtd2 **//​rootfs//​** 6720 KiB ​                          ​|| ​         |
 +^ <color magenta>​mountpoint</​color> ​  ​| ​                             |                               ​| ​ <color magenta>''/''</​color> ​                         ||          |
 +^ filesystem ​  ​| ​                             |                               ​| ​ [[doc:​techref:​filesystems#​overlayfs|OverlayFS]] ​          ​|| ​         |
 +^ Layer3 ​      ​| ​                             |                               ​| ​                ​| ​ mtd3 **//​rootfs_data//​** 5184 KiB ​    ​| ​         |
 +^ Size in KiB  |  128 KiB ​                     |  1280 KiB ​                     |  1536 KiB ​       |  5184 KiB ​                             |   ​64 KiB ​ |
 +^ Name         ​| ​ **//​u-boot//​** ​             |  **//​kernel//​** ​              ​| ​                ​| ​ **//​rootfs_data//​** ​            ​| ​ **//​art//​** ​ |
 +^ <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// ​ |
 +
 +==== Explanations ====
 +The Linux kernel treats "raw flash memory"​ (no matter whether NOR or NAND) chips as an [[doc:​techref:​MTD|MTD (Memory Technology Device)]] and employs [[doc:​techref:​filesystems]] developed for this purpose on top of the MTD layer.
 +
 +Since the partitions are nested we look at this whole thing in layers:
 +  - Layer0: So we have the Flashchip, 8 MiB in size, which is soldered to the PCB and connected to the [[doc:​hardware:​SoC]] over [[wp>​Serial Peripheral Interface Bus|SPI (Serial Peripheral Interface Bus)]].
 +  - Layer1: We "​partition"​ the space into mtd0 for the bootloader, mtd5 for OpenWrt and, in this case, mtd4 for the ART (Atheros Radio Test) - it contains calibration data for the wifi (EEPROM). If it is missing or corrupt, ''​ath9k''​ (wireless driver) won't come up anymore. The bootloader (128 KiB) contains of the u-boot 64KiB block AND a data section which contains the MAC, WPS-PIN and type description. If no MAC is configured ath9k will not work correctly due to a faulty MAC.
 +  - Layer2: we subdivide mtd5 (firmware) into mtd1 (kernel) and mtd2 (rootfs); In the generation process of the firmware (see [[doc:​howto:​obtain.firmware.generate]]) the Kernel binary file is first packed with [[wp>​Lempel–Ziv–Markov chain algorithm|LZMA]],​ then the obtained file is packed with [[wp>​gzip]] and then this file will be written onto the raw flash (mtd1) without being part of any filesystem! During boot, u-boot copies this entire section into RAM and executes it. From there on, the Linux kernel bootstraps itself…
 +  - Layer3: we subdivide rootfs even further into mtd3 for rootfs_data and the rest for an unnamed partition which will accommodate the SquashFS-partition.
 +
 +=== Mount Points ===
 +  * <color magenta>''/''</​color>​ this is your entire root filesystem, it comprises ''/​rom''​ and ''/​overlay''​. Please ignore ''/​rom''​ and ''/​overlay''​ and use exclusively ''/''​ for your daily routines!
 +  * <color magenta>''/​rom''</​color> ​ contains all the basic files, like ''​busybox'',​ ''​dropbear''​ or ''​iptables''​. It also includes default configuration files used when booting into [[doc:​howto:​generic.failsafe|OpenWrt Failsafe mode]]. It does not contain the Linux kernel. All files in this directory are located on the SqashFS partition, and thus cannot be altered or deleted. But, because we use overlay_fs filesystem, //​overlay-whiteout//​-symlinks can be created on the JFFS2 partition.
 +  * <color magenta>''/​overlay''</​color> ​ is the writable part of the file system that gets merged with ''/​rom''​ to create a uniform ''/''​-tree. It contains anything that was written to the router after [[doc:​howto:​generic.flashing|installation]],​ e.g. changed configuration files, additional packages installed with ''​[[doc:​techref:​opkg]]'',​ etc. It is formated with JFFS2.
 +
 +Whenever the system is asked to look for an existing file in ''/'',​ it first looks in ''/​overlay'',​ and if not there, then in ''/​rom''​. ​ In this way ''/​overlay''​ overrides ''/​rom''​ and creates the effect of a writable ''/''​ while much of the content is safely and efficiently stored in the read-only ''/​rom''​.
 +
 +When the system is asked to delete a file that is in ''/​rom'',​ it instead creates a corresponding entry in ''/​overlay'',​ a whiteout. ​ A whiteout is a symlink to ''​(overlay-whiteout)''​ that mostly behaves like a file that doesn'​t exist.
 +
 +<code bash>
 +#!/bin/sh
 +# shows all overlay-whiteout symlinks
 +
 +find /overlay -type l -exec sh -c \
 +    'for x; do [ "​$(readlink -n -- "​$x"​)"​ = "​(overlay-whiteout)"​ ] && printf %s\\n "​$x";​ done' -- {} +
 +</​code>​
 +
 +=== Example 2: Hoo Too HT-TM02 ===
 +[[doc:​hardware:​soc:​soc.ralink|Ralink RT5350F]]-based [[toh:​hwdata:​hootoo:​hootoo_tripmatenano_v15|Hoo Too HT-TM02]].
 +
 +^ Layer0 |  raw flash, 8192 KiB  ||||||
 +^ Layer1 |  **mtd0** \\ ''​u-boot''​ \\ 192 KiB  |  **mtd1** \\ ''​u-boot-env''​ \\ 64 KiB  |  **mtd2** \\ ''​factory''​ \\ 64 KiB  |  **mtd3** \\ ''​firmware''​ \\ 7872 KiB <​sub><​sup>​(= FlashSize-(192+64+64))</​sup></​sub> ​ |||
 +^ Layer2 |:::​|:::​|:::​| ​ **mtd4** \\ ''​kernel''​ \\ about 1 MiB  |  **mtd5** \\ ''​rootfs'' ​ ||
 +^ Layer3 |:::​|:::​|:::​|::: ​                      ​| ​ **''/​dev/​root''​** \\ around 2 MiB  |  **mtd6** \\ ''​rootfs_data''​ \\ around 4.5 MiB  |
 +
 +=== Example 3: D-Link DIR-300 ===
 +For some devices, the OpenWrt partition ''​firmware''​ may not exist at all. The [[toh:​d-link:​DIR-300#​flash.layout|DIR-300 flash layout]] is such an example.
 +
 +
 +===== Partitioning of UBIFS-Images =====
 +UBIFS-Images are suitable for devices with //"raw NAND flash memory"//​-chips.
 +
 +TODO
 +
 +===== MTD (Memory Technology Device) =====
 +The Linux kernel treats "​raw/​host-managed"​ flash memory (NOR and NAND alike) as an MTD (Memory Technology Device). An MTD is different to a [[wp>​block device]] or a [[wp>​character device]].
 +
 +  * e.g. a [[wp>​hard disk drive]] with platters spinning at 7200rpm is treated as a block device:
 +
 +The storage space of a block device is split up into "​blocks",​ which are also named "​sectors",​ of a size of 512 Bytes or 4096 Bytes. Blocks do not get corrupted during common operation, but only exceptionally. In the very rare case this happens, the LBA hard disk controller takes care, that accesses to such a bad block are redirected to a replacement block. Block devices support 2 main operations - read a whole block and write a whole block. When a block device is partitioned,​ the information is stored in the [[wp>​Master boot record|MBR]] or the [[wp>​GUID Partition Table|GPT]].
 +
 +  * e.g. flash memory is treated as MTD (Memory Technology Device):
 +
 +The storage space of a MTD is split up into "​erase-blocks",​ of a size of 64 KiB or much more, which themselves are split up into "​blocks",​ which are more correctly named "​pages",​ of smaller sizes. A single "​page"​ can be written to, but it cannot be overwritten,​ but instead the entire "erase block" that page is part of, has to be 
 +erased before it becomes possible to re-write its "​pages"​. Erase-blocks do become worn out after some number of erase cycles – typically 100K-1G for SLC NAND and NOR flashes, and 1K-10K for MLC NAND flashes. Erase-blocks may become bad (only NAND). In case of "FTL flash",​ the controller should notice and avoid further access to bad erase-blocks. In case of "raw flash",​ the operating system should deal with such cases.
 +
 +MTD devices support 3 main operations - read from some offset within an erase block, write to some offset within an erase-block,​ and erase a whole erase-block.
 +
 +The partitioning is not stored in the MBR/GPT, but it is done in the Linux Kernel (and sometimes independently in the [[doc:​techref:​bootloader]] as well!).
 +
 +The kernel boot process involves discovering of partitions within the NOR flash and it can be done by various target-dependent means:
 +  * some bootloaders store a partition table at a known location
 +  * some pass the partition layout via kernel command line
 +  * some targets require specifying the kernel command line at the compile time (thus overriding the one provided by the bootloader).
 +
 +Either way, if there is a partition named ''​rootfs''​ and ''​MTD_ROOTFS_ROOT_DEV''​ kernel config option is set to ''​yes'',​ this partition is automatically used for the root filesystem.
 +
 +After that, if ''​MTD_ROOTFS_SPLIT''​ is enabled, the kernel adjusts the ''​rootfs''​ partition size to the minimum required by the particular SquashFS image and automatically adds ''​rootfs_data''​ to the list of the available mtd partitions setting its beginning to the first appropriate address after the SquashFS end and size to the remainder of the original ''​rootfs''​ partition. The resulting list is stored in RAM only, so no partition table of any kind gets actually modified.
 +
 +For more details please refer to the actual patch at:
 +[[https://​dev.openwrt.org/​browser/​trunk/​target/​linux/​generic/​patches-2.6.37/​065-rootfs_split.patch]]
 +
 +For overlaying a special ''​mini_fo''​ filesystem is used, the ''​README''​ is available from the sources at
 +[[https://​dev.openwrt.org/​browser/​trunk/​target/​linux/​generic/​patches-2.6.37/​209-mini_fo.patch]]
 +
 +The utility program [[doc:​techref:​mtd]] can be used.
 +
 +===== UBI (Unsorted Block Images) =====
 +Unsorted Block Images (UBI) is an ''​erase block''​ management layer in the Linux kernel for raw NAND flash memory chips. It is layer on top of the MTD layer. UBI is used by [[doc:​techref:​filesystems#​UBIFS|UBIFS]].
 +
 +UBI serves two purposes, tracking "bad erase blocks"​ of a raw NAND flash memory chip and also providing wear-leveling. To accomplish this, UBI maps //logical erase blocks// to //physical erase blocks// and presents the first ones to higher layers.
 +
 +  * [http://​www.linux-mtd.infradead.org/​doc/​ubi.html UBI Documentation]
 +
 +
 +===== Discovery (How to find out) =====
 +<​code>​
 +cat /proc/mtd
 +dev:    size   ​erasesize ​ name
 +mtd0: 00020000 00010000 "​u-boot"​
 +mtd1: 00140000 00010000 "​kernel"​
 +mtd2: 00690000 00010000 "​rootfs"​
 +mtd3: 00530000 00010000 "​rootfs_data"​
 +mtd4: 00010000 00010000 "​art"​
 +mtd5: 007d0000 00010000 "​firmware"​
 +</​code>​
 +
 +The //​erasesize//​ is the [[wp>​Block (data storage)|block size]] of the flash, in this case 64KiB. The //size// is little or big [[wp>​Endianess|endian]] hex value in Bytes. In case of little endian, you switch to hex-mode and enter 02 0000 into the calculator for example and convert to decimal (by switching back to decimal mode again). Then guess how they are nested into each other. Or execute ''​dmesg''​ after a fresh boot and look for something like:
 +
 +<​code>​
 +Creating 5 MTD partitions on "​spi0.0":​
 +0x000000000000-0x000000020000 : "​u-boot"​
 +0x000000020000-0x000000160000 : "​kernel"​
 +0x000000160000-0x0000007f0000 : "​rootfs"​
 +mtd: partition "​rootfs"​ set to be root filesystem
 +mtd: partition "​rootfs_data"​ created automatically,​ ofs=2C0000, len=530000
 +0x0000002c0000-0x0000007f0000 : "​rootfs_data"​
 +0x0000007f0000-0x000000800000 : "​art"​
 +0x000000020000-0x0000007f0000 : "​firmware"​
 +</​code>​
 +These are the start and end offsets of the partitions as hex values in Bytes. Now you don't have to guess which is nested in which. E.g. 02 0000 = 131.072 Bytes = 128KiB.
 +
 +===== Details =====
 +==== generic ====
 +The flash chip can be represented as a large block of continuous space:
 +
 +| start of flash ................. end of flash  |
 +
 +There is no ROM to boot from; at power up the CPU begins executing the code at the very start of the flash. Luckily this isn't the firmware or we'd be in real danger every time we reflashed. Boot is actually handled by a section of code we tend to refer to as the [[bootloader]] (the BIOS of your PC //is// a bootloader).
 +
 +| ^ Boot Loader Partition ^ Firmware Partition ^ ''​Special Configuration Data''​ ^^^
 +^ Atheros ​ |  [[doc:​techref:​bootloader:​uboot|U-Boot]] ​  ​| ​ firmware ​ |  ''​ART'' ​        |||
 +^ Broadcom |  CFE      |  firmware ​ |  ''​NVRAM'' ​      |||
 +^ Atheros ​ |  RedBoot ​ |  firmware ​ |  ''​FIS recovery'' ​ |  ''​RedBoot config'' ​ |  ''​boardconfig'' ​ |
 +
 +The partition or partitions containing so called //Special Configuration Data// differ very much from each other. Example: The ''​ART''​-partition you will meet in conjunction with Atheros-Wireless and U-Boot, contains only data regarding the wireless driver, while the ''​NVRAM''​-partition of broadcom devices is used for much more than only that. There are special utilities to access and modify special configuration partitions. For Broadcom devices this is the ''​nvram''​ utility. To find out what is written in ''​NVRAM''​ you can run ''​nvram show''​.
 +
 +Note that clearing these special configuration data partitions like ''​ART,​ NVRAM''​ and ''​FIS''​ does not clear much of OpenWrt'​s configuration,​ unlike other router software which keep configuration data solely in e.g. ''​NVRAM''​. Instead, as a consequence of using the overlay_fs filesystem configuration with JFFS2 flash partition, the whole file system is writable and allows the flexibility of extending your OpenWrt installation in any way you want. OpenWrt'​s main configuration is therefore just kept in the root file system, using [[doc/​uci|UCI]] configuration files. For convenience,​ many other packages are made UCI compatible. If you want to reset your complete installation you should use OpenWrt'​s built-in functionality such as [[doc/​howto/​generic.sysupgrade|sysupgrade]] to restore settings, by clearing the JFFS2 partition. Or, if you cannot boot normally, you can wipe or change the JFFS2 partition using OpenWrt'​s [[doc/​howto/​generic.failsafe|failsafe mode]] (look in your device'​s dedicated page for information how to boot into failsafe). ​
 +
 +
 +==== broadcom with CFE ====
 +
 +If you dig into the "​firmware"​ section you'll find a trx. A trx is just an encapsulation,​ which looks something like this:
 +
 +^ trx-header ^^^^^^^
 +| HDR0  |  length ​ |  crc32  |  flags  |  pointers ​ |  data  |
 +
 +"​HDR0"​ is a magic value to indicate a trx header, rest is 4 byte unsigned values followed by the actual contents. In short, it's a block of data with a length and a checksum. So, our flash usage actually looks something like this:
 +
 +|  CFE  |  trx containing firmware ​ |  NVRAM  |
 +
 +Except that the firmware is generally pretty small and doesn'​t use the entire space between CFE and NVRAM:
 +|  CFE  |  trx firmware ​ |  unused ​ |  NVRAM  |
 +
 +(**//''​NOTE''//:​** The <​model>​.bin files are nothing more than the generic *.trx file with an additional header appended to the start to identify the model. The model information gets verified by the vendor'​s upgrade utilities and only the remaining data -- the trx -- gets written to the flash. When upgrading from within OpenWrt remember to use the *.trx file.)
 +
 +
 +So what exactly is the firmware?
 +
 +The boot loader really has no concept of filesystems,​ it pretty much assumes that the start of the trx data section is executable code. So, at the very start of our firmware is the kernel. But just putting a kernel directly onto flash is quite boring and consumes a lot of space, so we compress the kernel with a heavy compression known as [[wp>​Lempel–Ziv–Markov chain algorithm|LZMA]]. Now the start of firmware is code for an LZMA decompress:
 +
 +|  lzma decompress ​ |  lzma compressed kernel ​ |
 +
 +Now, the boot loader boots into an LZMA program which decompresses the kernel into RAM and executes it. It adds one second to the bootup time, but it saves a large chunk of flash space. (And if that wasn't amusing enough, it turns out the boot loader does know gzip compression,​ so we gzip compressed the LZMA decompression program)
 +
 +Immediately following the kernel is the filesystem. We use SquashFS for this because it's a highly compressed readonly filesystem -- remember that altering the contents of the trx in any way would invalidate the crc, so we put our writable data in a JFFS2 partition, which is outside the trx. This means that our firmware looks like this:
 +
 +|  trx  | gzip'd lzma decompress ​ |  lzma'd kernel ​ |  (SquashFS filesystem) ​ |
 +And the entire flash usage looks like this -
 +
 +|  CFE  |  trx  |  gz'd lzma  |  lzma'd kernel ​ |  SquashFS ​ |  JFFS2 filesystem ​ |  NVRAM  |
 +That's about as tight as we can possibly pack things into flash.
 +
 +----
 +
 +===== Explanations =====
 +==== What is an Image File? ====
 +An image file is byte by byte copy of data contained in a file system. If you installed a Debian or a Windows in the usual way onto one or two hard disk partitions and would afterwards copy the whole content byte by byte from the hard disk into one file:
 +
 +<code bash>
 +dd if=/dev/sda of=/​media/​sdb3/​backup.dd
 +</​code>​
 +
 +the obtained backup file ''/​media/​sdb3/​backup.dd'',​ could be used in the exact same manner like an OpenWrt-Image-File.
 +
 +
 +The difference is, that OpenWrt-Image-File are not created that way ;-) They are being generated with the **Image Generator** (former called Image Builder). You can read about the:
 +  * [[doc/​techref/​flash.layout]]
 +  * [[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.
 +  * About [[http://​skaya.enix.org/​wiki/​FirmwareFormat|Broadcom Firmware Format]]