ru: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
Previous revision
ru:doc:techref:flash.layout [2012/11/13 20:55]
ru:doc:techref:flash.layout [2014/12/14 16:19] (current)
Cobolorum [Устройство образа SquashFS]
Line 1: Line 1:
-====== ​The OpenWrt ​Flash Layout ​======+====== ​Разбиение встроенной флэш памяти в OpenWrt ======
  
-Есть жесткие диски, которые ​считаются блочными устройствами, ​ а есть флэш-память. Флэш NOR Flash, SLC NAND flash и MLC NAND flash. +Есть жесткие диски, которые ​являются блочными устройствами,​ а есть флэш-память. Флэш ​память имеет множество типов: ​NOR Flash, SLC NAND flash и MLC NAND flash. 
-Если чип флэш (не важно какого типа) соединен непосредственно с SoC и адресуется непосредственно ​Linux, ​мы называем это ** "​сырой флэш"​ **. +Если чип флэш ​памяти ​(не важно какого типа) соединен непосредственно с процессором ​и процессор может ее использовать обращаясь непосредственно ​к ее адресам то это ​называется  ​** "​сырой флэш"​ ** (raw flash)Для примера ​подобной ​флеш памяти являются микросхемы BIOS в старых PC совместимых компьютерах.  
-Если чип флэш не может быть адресован непосредственно ​операционкой ​(потому что есть ​дополнительный контроллер ​между флэш-чипом и SoC)мы называем это **  FTL (Flash Translation Layer) флэш ​ **. Встроенные системы почти всегда используют "сырые Flash", в то время как USB-карты памяти, ​ используют FTL flash! +Если ли же между микросхемой флэш ​памяти и находится какой либо ​контроллер, через который происходит обращение к памяти, то это ​называется **  FTL (Flash Translation Layer) флэш ​ **.  
- +Встроенные системы почти всегда используют "raw flash", в то время как ​любые ​USB-устройства хранения это FTL flash!  
-===== Partitioning of SquashFS-Images ​=====+Или другими словами при доступе к raw flash процессор оперирует адресами флеш ​памяти, ​а при FTL flash адресами контроллера. Есть небольшое исключение так называемая трансляция/​отображение SPI в память процессора. При которой контроллер SPI отлавливает все обращения к блоку памяти и транслирует их в протокол SPI. Т.е. процессор не замечает подмены,​ но это довольно специфическое и редкое аппаратное решение. 
 +===== Устройство образа ​SquashFS ===== 
 +Микросхема флэш памяти встроенных систем ​
 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**! Anotherslightly 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 devicefor information about its particular layout and simply check it yourself on your device. +:!: Ниже приведен пример разбиение флеш памяти  ​[[toh:​tp-link:​TL-WR1043ND]] ​другой пример разбиения вы можете найти на соответствующих страницах устройств данной wikiдля примера ​ смотри ​[[toh:​d-link:​DIR-300#​flash.layout|DIR-300]]. ​Варианты разбиений могут существенно различаться от устройства к устройствув том числе и для одноименных устройств,​ но с разными версия.
- +
-^   ​TP-Link WR1043ND ​ Flash Layout ​          ​^^^^^^ +
-^ Layer0 ​      ​| ​                      ​m25p80 [[wp>​Serial Peripheral Interface Bus|spi]]0.0:​ m25p64 ​     8192KiB ​                                                                     ||||| +
-^ Layer1 ​      ​| ​ mtd0 **//​u-boot//​** 128KiB ​ |  mtd5 **//​firmware//​** 8000KiB ​                                     |||    mtd4 **//art//** 64KiB  | +
-^ Layer2 ​      ​| ​                             |  mtd1 **//​kernel//​** 1280KiB ​ |  mtd2 **//​rootfs//​** 6720KiB ​                          ​|| ​         | +
-^ <color magenta>​mountpoint</​color> ​  ​| ​                             |                               ​| ​ <color magenta>''/''</​color> ​                         ||          | +
-^ filesystem ​  ​| ​                             |                               ​| ​ [[doc:​techref:​filesystems#​mini_fo|mini_fo]]/​[[doc:​techref:​filesystems#​overlayfs|overlayfs]] ​          ​|| ​         | +
-^ Layer3 ​      ​| ​                             |                               ​| ​                ​| ​ mtd3 **//​rootfs_data//​** 5184KiB ​    ​| ​         | +
-^ Size in KiB  |  128KiB ​                     |  1280KiB ​                     |  1536KiB ​       |  5184KiB ​                             |   ​64KiB ​ | +
-^ 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// ​ |+
  
-==== Partitions ​====+^   ​Разбиение флеш памяти TP-Link WR1043ND ​          ​^^^^^^ 
 +^ Уровень-0 ​      ​| ​                      ​m25p80 [[wp>​Serial Peripheral Interface Bus|spi]]0.0:​ m25p64 ​     8192 КБ                                                                      ||||| 
 +^ Уровень-1 ​      ​| ​ mtd0 **//​u-boot//​** 128 КБ  |  mtd5 **//​firmware//​** 8000 КБ                                      |||    mtd4 **//art//** 64 КБ  | 
 +^ Уровень-2 ​      ​| ​                             |  mtd1 **//​kernel//​** 1280 КБ  |  mtd2 **//​rootfs//​** 6720 КБ                           ​|| ​         | 
 +^ <color magenta>​точка монтирования</​color> ​  ​| ​                             |                               ​| ​ <color magenta>''/''</​color> ​                         ||          | 
 +^ файловая система ​  ​| ​                             |                               ​| ​ [[doc:​techref:​filesystems#​mini_fo|mini_fo]]/​[[doc:​techref:​filesystems#​overlayfs|overlayfs]] ​          ​|| ​         | 
 +^ Уровень-3 ​      ​| ​                             |                               ​| ​                ​| ​ mtd3 **//​rootfs_data//​** 5184 КБ     ​| ​         | 
 +^ Размер в КБайтах ​ |  128 КБ                      |  1280 КБ                    |  1536 КБ        |  5184 КБ                              |   64 КБ  | 
 +^ Наименование ​        ​| ​ **//​u-boot//​** ​             |  **//​kernel//​** ​              ​| ​                ​| ​ **//​rootfs_data//​** ​            ​| ​ **//​art//​** ​ | 
 +^ <color magenta>​точка монтирования</​color> ​  ​| ​ //​none// ​                   |  //​none// ​                    ​| ​ <color magenta>''/​rom''</​color> ​ |  <color magenta>''/​overlay''</​color> ​  ​| ​ //​none// ​ | 
 +^ файловая система ​  ​| ​ //​none// ​                   |  //​none// ​                    ​| ​ [[doc:​techref:​filesystems#​SquashFS]] ​ |  [[doc:​techref:​filesystems#​JFFS2]] ​ |  //​none// ​ | 
 +==== Разбиение ​==== 
 +Разбиение легче всего продемонстрировать на примера уровней(слоев):​
 Since the partitions are nested we look at this whole thing in layers: Since the partitions are nested we look at this whole thing in layers:
-  - Layer0So we have the Flashchip8MiB in sizewhich is soldered to the PCB and connected to the [[doc:​hardware:​SoC]] ​over [[wp>​Serial Peripheral Interface Bus|SPI (Serial Peripheral Interface Bus)]]. +  - Уровень-0Представляет из себя микросхему флэш памяти установленную на платев примере она имеет емкость8192 КБ и аппаратно подключена к [[doc:​hardware:​SoC]] ​через ​[[wp>​Serial Peripheral Interface Bus|SPI (Serial Peripheral Interface Bus)]]. 
-  - Layer1: We "​partition"​ the space into mtd0 for the bootloader, mtd5 for the firmware and, in this case, mtd4 for the ART (Atheros Radio Test) - it contains mac addresses and calibration data for the wifi (EEPROM). If it is missing or corrupt, ''​ath9k''​ (wireless driver) won't come up anymore. +  - Уровень-1: We "​partition"​ the space into mtd0 for the bootloader, mtd5 for the firmware and, in this case, mtd4 for the ART (Atheros Radio Test) - it contains mac addresses and calibration data for the wifi (EEPROM). If it is missing or corrupt, ''​ath9k''​ (wireless driver) won't come up anymore. 
-  - 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! +  - Уровень-2: 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! 
-  - Layer3: we subdivide rootfs even further into mtd3 for rootfs_data and the rest for an unnamed partition which will accommodate the SquashFS-partition.+  - Уровень-3: we subdivide rootfs even further into mtd3 for rootfs_data and the rest for an unnamed partition which will accommodate the SquashFS-partition.
  
 ==== Filesystems ==== ==== Filesystems ====
Line 53: Line 55:
  
 ==== Directories ==== ==== Directories ====
--> [[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 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.\\ **//''​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.\\
ru/doc/techref/flash.layout.1352836529.txt.bz2 · Last modified: 2012/11/13 20:55 (external edit)