User Tools

Site Tools


fr:doc:techref:flash.layout

Differences

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

Link to this comparison view

fr:doc:techref:flash.layout [2013/02/11 18:30]
fr:doc:techref:flash.layout [2015/02/23 08:31] (current)
Bouv French link
Line 23: Line 23:
 ==== Partitions ==== ==== Partitions ====
 Comme les partitions sont imbriquées,​ cet ensemble peut être vu en couches : Comme les partitions sont imbriquées,​ cet ensemble peut être vu en couches :
-  - Couche0: nous avons le composant flash, d'une taille de 8MiB , qui est soudé au circuit imprimé et connecté au [[doc:​hardware:​SoC]] via le  [[wp>​Serial Peripheral Interface Bus|SPI (Serial Peripheral Interface Bus)(Bus d'​Interface Série)]].+  - Couche0: nous avons le composant flash, d'une taille de 8MiB , qui est soudé au circuit imprimé et connecté au [[fr:doc:​hardware:​SoC]] via le  [[wp>​Serial Peripheral Interface Bus|SPI (Serial Peripheral Interface Bus)(Bus d'​Interface Série)]].
   - Couche1: nous  "​partitionnons"​ l'​espace en mtd0 pour le chargeur d'​amorçage, ​ mtd5 pour le  firmware et, dans ce cas, mtd4 pour l'ART (Atheros Radio Test) - il contient les adresses MAC et les données de calibration pour le sans fil (EEPROM). S'il est manquant ou corrompu, ''​ath9k''​ (pilote du sans fil) ne démarrera pas.   - Couche1: nous  "​partitionnons"​ l'​espace en mtd0 pour le chargeur d'​amorçage, ​ mtd5 pour le  firmware et, dans ce cas, mtd4 pour l'ART (Atheros Radio Test) - il contient les adresses MAC et les données de calibration pour le sans fil (EEPROM). S'il est manquant ou corrompu, ''​ath9k''​ (pilote du sans fil) ne démarrera pas.
   - Couche2: nous subdivisons mtd5 (firmware) en mtd1 (noyau) et mtd2 (rootfs); Dans le processus de génération du firware, (voir [[doc:​howto:​obtain.firmware.generate]]) le fichier binaire du noyau est le premier empaqueté avec  le  [[wp>​Lempel–Ziv–Markov chain algorithm|LZMA]],​ puis, le fichier résultant est empaqueté avec [[wp>​gzip]] et finalement, ce fichier est écrit dans la mémoire raw flash (mtd1) sans faire partie d'​aucun système de fichiers !   - Couche2: nous subdivisons mtd5 (firmware) en mtd1 (noyau) et mtd2 (rootfs); Dans le processus de génération du firware, (voir [[doc:​howto:​obtain.firmware.generate]]) le fichier binaire du noyau est le premier empaqueté avec  le  [[wp>​Lempel–Ziv–Markov chain algorithm|LZMA]],​ puis, le fichier résultant est empaqueté avec [[wp>​gzip]] et finalement, ce fichier est écrit dans la mémoire raw flash (mtd1) sans faire partie d'​aucun système de fichiers !
Line 51: Line 51:
 </​code>​ </​code>​
  
-==== Dossiers ​==== +==== hiérarchie des systèmes de fichiers ​====
--> [[doc:​howto:​user.beginner.fhs]]+
  
 **//''​NOTE1''//:​** si le noyau faisait partie de la partition SquashFS, nous ne pourrions contrôler à quel emplacement exact dans la mémoire flash il serait écrit (dans quels blocs se trouveraient ses données). Par conséquent,​ nous ne pourrions nous contenter de dire au chargeur d'​amorçage de charger et exécuter certains blocs sur la mémoire flash, mais nous devrions l'​adresser avec un chemin et un nom de fichier. Ce ne serait pas mauvais en soi, mais pour le faire, le chargeur d'​amorçage aurait à connaître et comprendre le système de fichier SquashFS, ce qui n'est pas le cas. Les chargeurs d'​amorçage embarqués que nous utilisons avec OpenWrt ne comprennent pas le concept de système de fichiers et, par conséquent,​ sont incapables d'​adresser un fichier par chemin/​nom.Le mieux qu'il fassent, c'est de supposer que le début de la section trx data est du code exécutable.\\ **//''​NOTE1''//:​** si le noyau faisait partie de la partition SquashFS, nous ne pourrions contrôler à quel emplacement exact dans la mémoire flash il serait écrit (dans quels blocs se trouveraient ses données). Par conséquent,​ nous ne pourrions nous contenter de dire au chargeur d'​amorçage de charger et exécuter certains blocs sur la mémoire flash, mais nous devrions l'​adresser avec un chemin et un nom de fichier. Ce ne serait pas mauvais en soi, mais pour le faire, le chargeur d'​amorçage aurait à connaître et comprendre le système de fichier SquashFS, ce qui n'est pas le cas. Les chargeurs d'​amorçage embarqués que nous utilisons avec OpenWrt ne comprennent pas le concept de système de fichiers et, par conséquent,​ sont incapables d'​adresser un fichier par chemin/​nom.Le mieux qu'il fassent, c'est de supposer que le début de la section trx data est du code exécutable.\\
Line 143: Line 142:
  
 ===== Explanations ===== ===== 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 harddisc partitions and would afterwards copy the whole content byte by byte from the hard disc 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 Firware Format]] 
fr/doc/techref/flash.layout.1360603826.txt.bz2 · Last modified: 2013/02/11 18:30 (external edit)