Forums d'entraide informatique - Astuces - Conseils

46 lib_generic :contient les fonctions génériques à toutes les architectures (bz 1 ib, zl ib,crc32,printf...)
èé net :contient les fonctions réseau disponibles dans u-boot : bootp, fonctions Ethernet génériques, NFS, RARP,TFTP.
éé tools :contient divers outils (création de logos,génération d'adresse MAC, génération d'images binaires au format uimage, support gdb)
té arch_config.mk : un fichier de configuration par architecture, contenant les flags propres à l'architecture.
5.3 PERSONNALISATION DU BOOTLOADER
La personnalisation du bootloader est relativement simple lorsque l'architecture sur laquelle on souhaite l'utiliser est déjà supportée. Il suffit de copier le répertoire correspondant à la carte existante dans le répertoire boa rd, de modifier les fichiers qu'il contient et de créer le fichier de configuration adapté à notre architecture.
Par exemple, pour la carte CPUPXA255, nous avons un répertoire board/cpupxa 2 5 5 qui contient
•    conf i g .mk : dans lequel nous avons adapté l'adresse de
base à laquelle sera linké le bootloader (qui correspond à une adresse en SDRAM vers laquelle le bootloader sera recopié au boot)
•    cpupxa 2 5 5.c : dans lequel nous précisons le numéro de
notre architecture (numéro devant concorder avec le numéro de l'architecture pour laquelle sera compilé notre noyau :cfhttp://www.arm.linux.org.uledeveloper/machines/ pour la liste des architectures ARM existantes.
•    1 owl evel_i ni t.S :qui contient des routines bas niveau d'initialisation de notre architecture, comme par exemple l'initialisation de la SDRAM, des PLL et des GPIO, ces fonctions étant appelées dès la mise sous tension. Ce fichier et le fichier start .S contenu dans le répertoire cpu/pxa/ sont les deux fichiers qui justifient de comprendre un minimum l'assembleur du processeur afin de pouvoir les modifier.
Ensuite, nous avons créé un fichier i ncl ude/conf igs/ c pup x a 255.  h qui contient un certain nombre de paramètres définissant notre architecture et les fonctions que nous souhaitons embarquer dans le bootloader :ce fichier contient un grand nombre de :,fdef i ne.Voici par exemple la configuration du contrôleur réseau
#define CONFIG_DRIVER_DM9000    1
#define CONFIG_8M9000_BASE    Ox00000000
#define DM9000_I0    CONFIG_1M9000_BASE
#define DM9000_DATA    (CONFIG_1M9000_BASE+4)
#define CONFIG_0M9000_USE_328IT
Nous utilisons un DM9000 (u-boot intégrera donc son driver). Son adresse de base est Ox0C0 00000,1e registre de commande est à l'adresse de base, le registre de données est 4 octets plus loin et le composant est interface sur 32 bits.
Nous définissons aussi dans ce fichier les commandes que u-boot va embarquer
#define CONFIG_COMMANDS    (CONFIG_CMD_DFL I CFG_CMD_PING I
CFG_CMD_MMC I CFG_CMD_JFFS2    I CFG_CMD_FAT)
En plus de toutes les commandes par défaut, nous souhaitons intégrer la commande ci nc, les commandes de gestion des cartes MMC et les commandes d'accès aux systèmes de fichiers JFFS2 et FAT.
Il est très important de prendre le temps de lire les documentations disponibles dans le dossier doc de u-boot, de lire les fichiers de configuration d'autres architectures et enfin de lire le code des drivers (dossier d ri vers) et fonctiOns (dossier commo n) que l'on souhaite utiliser afin debien saisir la portée des définitions du fichier de configuration.
Une fois l'architecture intégrée à u-boot, il est nécessaire de modifier le fichier Ma kef 1 1 e situé à la base de l'arborescence d'u-boot afin d'y intégrer notre architecture.
5.4 COMPILATION
Les commandes de construction d'u-bpot sont assez simples
$ make clobber
$ make cpupxa255_config $ make
On obtient un fichier u- boot .bin qui peut être programmé sur la carte.
5.5 INSTALLATION
Dans le cas où le processeur dispose d'une bootrom interne, il est nécessaire de suivre les instructions du fondeur pour communiquer avec cette bootrom, ce qui passe en général par l'installation en RAM d'un petit bout de code qui va initialiser la SDRAM et le bus et permettre un dialogue au travers du port série afin de recevoir des données et de les programmer en flash. Le passage en mode bootrom se fait en général au moyen d'un jumper qui vient positionner une GPIO dans un état qui fait démarrer le processeur sur sa ROM interne.
Dans le cas où il est nécessaire d'utiliser un adaptateur JTAG, il convient de s'assurer de la compatibilité des niveaux de tension de l'adaptateur avec ceux du processeur et que les logiciels que l'on souhaite utiliser sont bien compatibles avec l'architecture matérielle de la carte.
La session suivante est un exemple de programmation du module CPUPXA255 avec un adaptateur JTAG sur le port parallèle issu du schéma du Byteblaster d'Altera
$ jtag
JTAG Tools 0.6
Copyright (C) 2002, 2003 ETC S.r.O.
JTAG Tools in free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for JTAG Tools.
Warning: JTAG Tools may damage your hardware! Type "duit" to exit!
Type "help" for help.
jtag> cable parallel 0x378 ByteBlaster
Initial i zi ng Altera ByteB1 aster/ByteB1 aster I I /ByteB1 asterMV
Parallel Port Download Cable on parallel port at 0x378
jtag> detect IR length: 5

Chain length: 1
Device Id: 01101001001001100100000000010011 Manufacturer: Intel
Part:    PXA250
Stepping:    PXA255A0
Filename:    /usr/local/share/jtag/intel/pxa250/pxa250c0
jtag> initbus pxa2x0
jtag> detectflash 0
Query identification string:
Primary Algorithm Command Set and Control
Interface ID Code: 000001 (Intel/Sharp Extended
Command Set)
Alternate Algorithm Command Set and Control
Interface ID Code: 0x0000 (null)
Query system interface information:
Vcc Logic Supply Minimum Write/Erase or Write voltage: 2700
mV
Vcc Logic Supply Maximum Write/Erase or Write voltage: 3600
mV
Vpp [Programming] Supply Minimum Write/Erase voltage: 0 mV Vpp [Programming] Supply Maximum Write/Erase voltage: 0 mV Typical timeout per single byte/word program: 64 us
Typical timeout for maximum-size multi-byte program: 128 us Typical timeout per individual block erase: 1024 ms
Typical timeout for full chip erase: 0 ms
Maximum timeout for byte/word program: 256 us
Maximum timeout for multi-byte program: 1024 us
Maximum timeout per individual block erase: 4096 ms Maximum timeout for chip erase: 0 ms
Device geometry definition:
Device Size: 16771216 B (16384 KiB, 16 MiB)
Flash Device Interface Code description: 0x0002 (x8/x16) Maximum number of bytes in multi-byte program: 32
Number of Erase Block Regions within device: 1
Erase Block Region Information:
Region 0:
Erase Block Size: 131072 B (128 KiB)
Number of Erase Blocks: 128
jtag> flashmem 0 images/u-boot.bin
Manufacturer: Intel
Chip: 28F128J3A
program:
block 0 unlocked erasing block 0: 0 addr: Ox0001F7AC (done)
verify:
addr: 0x0001F7A8 Done.
jtag>
5.6 UTILISATION
u-boot a été conçu dans l'objectif d'apporter un maximum de souplesse dans la phase de démarrage d'une carte : il offre donc toutes les fonctions permettant de tester le bas niveau de la carte, en plus des fonctions plus classiques de chargement de programmes par le port série ou le réseau et de gestion de périphériques de stockage.
Voici par exemple le résultat de la commande help sur une architecture ARM920t :
- alias for 'help'
base    - print or set address offset
boot    - boot default, i.e., run 'bootcmd'
bootd    - boot default, i.e., run 'bootcmd'
bootm    - boot application image from memory
bootp    - boot image via network using BootP/TFTP protocol
cmp    - memory compare
coninfo - print console devices and information
cp    - memory copy
crc32    - checksum calculation
date    - get/set/reset date & time
dcache - enable or disable data cache echo    - echo args to console
eeprom • EEPROM sub-system
erase    - erase FLASH memory
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls    - list files in a directory (default /1
flinfo - print FLASH memory information
fsinfo - print information about filesystems fsload - load binary file from a filesystem Image go    - start application at address 'addr'
help    - print online help
icache - enable or disable instruction cache icrc32 - checksum calculation
iloop    - infinite loop on address range
imd    - i2c memory display
imls    - list all images found in flash
imm    - i2c memory modify (auto-incrementing)
imw    - memory write (fill)
inm    - memory modify (constant address)
iprobe - probe to discover valid I2C chip addresses
itest    - return true/false on integer compare
loadb    - load binary file over serial line (kermit mode)
loop    - infinite loop on address range
ls    - list files in a directory (default /)
md    - memory display
mm    - memory modify (auto-incrementing)
mtest    - simple RAM test
mw    - memory write (fill)
nfs    - boot image via network using NFS protocol
nm    - memory modify (constant address)
printenv- print environnent variables
protect - enable or disable FLASH write protection rarpboot• boot image via network using RARP/TFTP protocol
reset    - Perform RESET of the CPU
run    - run commands in an environment variable
saveenv - save environnent variables to persistent storage setenv - set environnent variables
sntp    - synchronize RTC via network
tftpboot- boot image via network using TFTP protocol usb    - USB sub-system
usbboot - boot from USB device
version - print monitor version
Nous avons donc à notre disposition :
♦    Des commandes de gestion mémoire : cp, cmp, c r c 32, MG,
MM, mt e st, mw, nm ;
♦    Des commandes de gestion d'une eeprom externe :eeprom
wri te, read ;
♦    Des commandes de gestion de date : sntp, date ;
♦    Des commandes de gestion du bus i2c : i probe, i md, imm,
imw, i nm ;
♦    Des commandes de gestion de mémoire flash : fl info,
i ml s, e ra se, protect ;
♦    Des commandes d'accès au système de fichiers JFFS2 :
fsl oad, fsinfo,1 s ;
♦    Des commandes de gestion de l'USB : usb reset,  stop,
tree, i nfo, scan, part, read ;
♦    Des commandes d'accès au système de fichiers FAT :
fati nfo, fatl oad, fatl s ;

•    D'une commande de chargement par le port série loadb
•    D'une commande d'exécution d'une application : go
•    De commandes de gestion de l'environnement : setenv, printenv, saveenv
•    De commandes réseau : t f tpboot, t f tp.
Pour en savoir plus sur une commande, et si CFG_LONGHE LP est défini dans le fichier de configuration, il est nécessaire de taper hel p commande.
Par exemple pour l'USB
usb reset - reset (rescan) USB controller
usb stop [f] - stop USB [f]=force stop
usb tree - show USB device tree
usb info [dey] - show available USB devices
usb scan - (re-)scan USB bus for storage devices
usb device [dey] - show or set current USB storage device
usb part [dev] - print partition table of one or all USB storage devices usb read addr blk# cnt - read 'cnt blocks starting ut block 'blk#'
to memory address 'addr'
usbboot loadAddr dev:part
Les paramètres d'environnement importants à connaître sont :
•    setenv ethaddr aa:bb:cc:dd:ee:ff
•    setenv serveri p i pduserveurtftp
•    setenv ipaddr ipdelacarte
5.7 U-BOOT : ENVIRONNEMENT DE TEST
u-boot permet d'exécuter des applications ce qui est très pratique pour tester des fonctionnalités avant d'avoir monté le système d'exploitation ou en travaillant comme sur un microcontrôleur, sans se soucier de problèmes de MMU & co.
Voici l'exemple du classique hell owo rl d qui est disponible dans le répertoire examp 1 es de u-boot
/*
*    (C) Copyright 2000
*    Wolfgang Denk, DEMI Software Engineering, wdOdenx.de. *1
#include <common.h> #include <exports.h>
int hello_world (int argc, char *argv[])
int i;
/* Print the ABI version */
app_startup(argv);
printf ("Example expects ABI version %d\n", XF_VERSION); printf ("Actual U-Bout ABI version %d\n", (int)get_ version());
printf ("Hello World\n"); printf ("argc r %d\n", argc);
for (i.0; i<=argc, ++i)
printf ("argv[%d] r
argv[i] ? argv[i] :
printf (lit any key tu exit ... while (!tstc())
/* consume input */ (void) getc();
printf (" \n\n"); return (0);
Une fois compilé, nous copions examp I es/hell o_wo rl d . hi n dans le répertoire du serveur TFTP.
Puis sur la carte
U-Bout 1.1.4 (Feb 24 2006 - 12:54:27)
U-Bout code: A1000000 -> A101F8E4 BSS: -> A105435C
RAM Configuration:
Bank 4: a0000000 64 MB Bank #1: a4000000 0 kB Bank #2: a8000000 0 kB Bank #3: ac000000 0 kB Flash: 32 MB
In:    serial
Out:    serial
Err:    serial
Hit any key tu stop autoboot: 0 CPUPXA255> tftp a2000000 hello world.bin dm9000 i/o: Oxt000000, id: Ox90000a46 MAC: 00:0:ca:f1:3c:d2
operating ut 100M full duplex mode
TFTP from server 192.168.1.5; our IP address is 192.168.1.99
Filename 'hello_world.bin'.
Load address: Oxa2000000
Loading: #
done
Bytes transferred = 499 (1f3 hex) CPUPXA255> go a2000000
## Starting application at OxA2000000 Example expects ABI version 2
Actual U-Bout ABI version 2
Hello World
argc = 1
argv[0] r a2000000"
argv[1] = "<NULL>"
Hit any key tu exit ...
## Application terminated, rc r 0x0 CPUPXA255>
11 devient ainsi très facile de développer des petites applications de test ou de démonstration. L'accès au matériel est direct et se fait simplement en utilisant les adresses physiques des registres.
6.ADAPTATION DU NOYAU
Nous avons à présent une carte sur laquelle un bootloader est installé et a permis de valider la stabilité du matériel, Il est grand temps d'installer un noyau Linux dessus afin d'exploiter tout le potentiel de l'architecture.
6.1 SOURCES DU NOYAU
Depuis la génération 2.6 du noyau, un effort particulier est fait pour que les patchesARM intègrent au plus vite le noyau officiel. Ainsi, les patches soumis au maintainer de l'architecture ARM, Russell King, sont disponibles sur l'interface web de

gestion du suivi des patches : http:/Iwww.arm.linux.org. uk/developer/patches/.
Un patch suit le parcours Incoming => Pending =-> Applied ou Rejected.
Avant d'en arriver là, les personnes s'occupant d'une architecture réalisent souvent des patches qui supportent plus complètement leur matériel mais ne sont pas encore suffisamment finalisés pour intégrer le noyau officiel.
Par exemple :
•    AT91RM9200 : http://maxim.org.za/AT9I RM9200/2.6/
♦ TI OMAP :http://source.mvista.com/git/gitweb.cgi?p=linuxomap-2.6.git;a=log
•    Cirrus EP93xx :http://www.kernelorglpub/scrn/linux/kernell gibmburian/linux-2.6-ep93xx.git/
6.2 AJOUT DE NOTRE ARCHITECTURE
Une fois dans l'arborescence du noyau Linux, tout ce qui concerne l'ARM se situe dans a r c h / a rm, les drivers restant dans les répertoires habituels : dr i vers & sound.
•    boot : comprend les routines de décompression du noyau, c'est ce qui sera appelé par le bootloader lors du chargement du noyau ;
•    configs :contient les fichiers de configuration par défaut des architectures supportées. Ce sont les fichiers qui une fois copiés à la racine du noyau et renommés en .config permettent de générer un noyau adapté à ces architectures. Ils servent notamment au projetARM Linux Kernel Autobuild : http://armlinux.simtec.co.uk/kautobuild/ .
•    kernel : contient les fichiers clefs du noyau propres aux architectures ARM ;
•    lib: la librairie pour ARM ;
•    ma c h - xxx :les fichiers de support spécifique de l'architecture XXX ;
•    mm : tout ce qui est gestion de la mémoire, mmu & caches pour chaque version d'ARM ;
•    nwfpe : une des deux émulations de flottants présentes dans le noyau ;
•    vfp : Vector Floating Point — le dernier coprocesseur d'ARM.
Les deux répertoires dans lesquels nous pouvons être amenés à travailler, sous réserve que le processeur sur lequel nous travaillons est déjà supporté par le noyau, sont : boot pour la phase de décompression du noyau et mach - xxx pour le support spécifique de notre carte.
Prenons par exemple le cas de la carte CPUAT9 I (noyau 2.6.14). Le répertoire contenant l'architecture est : mach - at9lrm92(30. Nous créons un fichier board-cpuat91.c qui a le contenu suivant (seules les sections intéressantes sont reproduites ici) :
static void _init cpuat9l_init_irq(void)
/* Initialize AIC controller */ at9lrm9200_init_irg(NULL);
/* Set up the GPIO interrupts */ at9l_gpio_ircsetup(POFP_GPIOJANKS);
La fonction d'initialisation des interruptions, dans laquelle nous précisions que nous sommes sur un processeur en boîtier PQFP (car le BGA a plus de GPIO et donc un bank supplémentaire pouvant générer des interruptions).
/*
*    Serial port configuration.
*    0 .. 3 = USART0    USART3
*    4    = DBGU
*/
/* ttyS0,    t tyS4 */
#define CPUAT91_UART_MAP {4,0,1,2,3}
/* ttyS0 */
#define CPUAT91_SERIAL_CONSOLE 0
Nous utilisons les 5 UARTS, et affectons le DBGU (UART orienté vers la fonction de debug) à t y SO et à la console.
static void _init cpuat9l_map_io(void)
int serial[AT91C_NR_UART] = CPUAT91_UART_MAP; int i;
at9lrm9200_map_io();
/* Initialize clocks: 18.432 MHz crystal */ at91_clock_init(18432000);
#ifdef CONFIG_SERIAL_AT91
at9l_console_port = CPUAT91_SERIAL_CONSOLE; memcpy(at9l_serial_map, serial, sizeof(serial));
/* Register UARTs */
for (i = 0; i < AT91C_NR_UART; i++) {
if (at9l_serial_map[i] >= 0)
at9l_register_uart(i, at9l_serial_magil);
#endif
Nous utilisons un quartz à 18.432 MHz. Le noyau doit le savoir car cela impacte le réglage des PLL pour les périphériques du processeur.
static struct at9l_eth_data _initdata cpuat9l_eth_data = { .is_rmii    = 1,
Le contrôleur Ethernet est câblé en RMII (moitié moins de fils qu'un MII, mais une fréquence d'échange des données double).
arch/arm S ls boot
common configs Kconfig
mach-clps111x    mach-iop3xx    mach-realview    nwfpe
mach-clps7500    mach-ixp2000    mach-rpc    oprofile
mach-ebsall0    mach-ixp4xx    mach-s3c2410    plat-omap
mach-emulOdb    mach-17200    mach-sa1100    tools
Kconfig.debug mach-footbridge mach-lh7a40x mach-shark    vfp
kernel    mach-h720x    ma ch -omapl    mach-versatile
1 i b    mach-imx    ma ch -omap2    Makef i le
mach-aaec2000 mach-integrator mach-pxa    MM

    static struct at9l_usbh_data    initdata cpuat9l_usbh_data = {
.ports    = 1,
Le contrôleur OHCI a un seul port.
static struct at9Ludc_data __initdata cpuat9Ludc_data = {
.vbus_pin    = AT91_PIN_PC15,
.pullup_pin    = AT91_PIN_PC14,
Il nous reste à modifier les fichiers Kconf i g et Makefi le avant de pouvoir sélectionner notre architecture et compiler le noyau.
Kconfig :
config MACH_CPUAT91
boni "Eukrea CPUAT91"
depends on ARCH_AT91RM9280
help
Select this if you are using Eukrea's AT918M9200 board
Nous utilisons la GPIO CI4 pour activer ou désactiver la résistance permettant à un hôte de détecter notre carte lorsqu'elle est connectée. Et nous utilisons la GPIO CI5 pour détecter la présence des 5 volts fournis par l'hôte et ainsi détecter que la carte vient d'être connectée.
Le contrôleur SDCard/MMC est connecté en 4 fils, et utilise la GPIO C2 pour détecter l'insertion d'un carte.
static void __init cpuat9l_board_init(void)
/* Ethernet */
at9l_add_device_eth(&cpuat9l_eth_data); /* USB Hast */
at9l_add_device_usbh(&cpuat9l_usbh_data); /* USB Device */
at9l_add_device_udc(&cpuat9Ludc_data): /* MMC */
at9l_add_device_mmc(&cpuat91_mmc_data):
La fonction d'initialisation de notre carte qui ajoute chaque device avec sa structure de configuration.
Et enfin la définition de notre machine :
•    CPUAT91 est le numéro sous lequel notre plate-forme est enregistrée et que le bootloader doit passer en paramètre
•    p hy s_r am est l'adresse de base de la SDRAM
•    boot_pa rams est l'adresse à laquelle le bootloader va
déposer la ligne de configuration du boot du noyau
•    t i mer , map_io, i ni t_i r g et i n t_machi ne sont les fonctions qui remplissent chacune des fonctionnalités décrites par leur nom.
Makefile :
obj-S(CONFIG_MACH_CPUAT91)    += board-cpuat91.o
led-S(CONFIG_MACH_CPUAT9I) += leds.o
•    Les routines de détection de la connexion à un hôte USB
•    Les adresses de base et l'affectation de l'IRQ du contrôleur Ethernet
é    Les routines de gestion du backlight (on/off/niveau) et de l'alimentation de l'écran
é    La configuration du framebuffer (nombre de couleurs,
marges, fréquence, polarité des signaux, timings, etc.)
•    Les routines d'initialisation du contrôleur SD/MMC
•    La routine principale qui initialise les GPIO et affecte les fonctions à chaque GPIO.
Ce dernier point est important car sur des processeurs complexes tels que les PXA, les IXP, les AT9 I, les EP93xx, les MX ou les OMAP, les fonctionnalités sont très souvent multiplexées sur chaque GPIO.Ainsi, on peut parfois arriver à une impossibilité car la fonctionnalité A affectée à la GPIO
n    bloque la fonctionnalité C de cette même GPIO. Ce multiplexage peut parfois rendre la conception d'une carte électronique plus complexe en raison de la multitude de choix possibles (une même fonction est par exemple présente sur 7 GPIO différentes sur un PXA270 !).
6.3 CONFIGURATION ET COMPILATION
make ARCH=arm CROSS_COMPILE=arm-linux- menuconfig
On pourra éditer le fichier Ma kef ile à la racine du noyau pour forcer ARCH et C RO S S_COMP L E aux bonnes valeurs et pouvoir simplement taper ma k e me n u con f g.
static struct at9l_mmc_data _initdata cpuat9l_mmc_data = {       
.is_b    =    0,
.wire4    =    4,
.det_pin    = AT91_PIN_PC2,   
};
MACHINE_START(CPUAT91, /* Maintainer: .phys_ram .phys_io .io_pg_offst .boot_params .timer
.map_io .init_irq .init_machine
MACHINE_END
"EUKREA CPUAT91 SBC")
EUKREA Electromatique - Eric Benard */ = AT91_SDRAM_BASE,
= AT91C_BASE_SVS,
= (AT91C_VA_BASE_SYS » 18) & Oxfffc, = AT91 SDRAM BASE + 0x100,
= &at9irm920i_timer,
= cpuat9l_map_io,
= cpuat9l_init_irq,
= cpuat9l_board_init,
Profitons du fait que nous parlons de l'inclusion du fichier 1 e d s .0 dans le noyau pour décrire cette option :elle permet d'affecter deux GPIO, idéalement connectées à deux LED (une rouge et une verte si possible ;-) qui permettront de visualiser simplement : que le noyau est en vie (option L ED S_T I MER) et la charge CPU (option LEDS_CPU). Une fois ces options validées et les bonnes GPIO affectées dans le fichier 1 eds . c, la LED verte clignotera environ toutes les secondes et-la
LED rouge sera d'autant plus allumée que le processeur est'-,„, sollicité. La fonction peut à première vue paraître gadget, mais    --„
en fait elle permet souvent de voir immédiatement si une
bêtise a été faite quelque part ou si un bout de code doit être optimisé car la LED est rouge de colère.
Dans le cas d'un processeur PXA, le fichier d'initialisation de l'architecture contient

DÉDIÉ
Un point clef de la configuration du noyau est la partie MTD : Memory Technology Devices. Le menu est situé sous Device Drivers > Memory Technology Devices (MTD). Ce support est nécessaire pour pouvoir utiliser la flash du système comme périphérique de stockage.
Les options importantes sont :
[*]    MTD partitioning support
[*]    Command line partition table parsing
<*>    Direct char device access to MTD devices
<*>    Caching block device access to MTD devices
qui permettent respectivement :
•    D'autoriser le partitionnement de la flash ;
•    De prendre la configuration du partitionnement passée dans la ligne de configuration du noyau ;
♦    D'offrir un device d'accès à la flash en mode char (pour
envoyer des commandes : effacement, protection, etc.)
♦    D'offrir un device d'accès à la flash en mode block (pour recevoir un système de fichiers qui peut être géré comme un disque dur ou une clef USB).
Le menu RAMIROM/Flash chip drivers permet de choisir le type de mémoires que MTD va supporter. Nous sélectionnons les options suivantes :
<*> Detect flash chips by Common Flash Interface (CFI) probe
L*] Flash chip driver advanced configuration options [*]    Specific CFI Flash geometry selecti on
[*]    Support 16-bit buswidth
[*]    Support 1-chip flash interleave
<*> Support for Intel/Sharp flash chips qui permettent respectivement :
D'autoriser l'autodétection des flashs par la Common Flash Interface (standard que les fabricants de flashs respectent... plus ou moins ;-) ;
à. De supporter une flash sur 16 bits ; De supporter les flashs Intel/Sharp.
Enfin, le menu Mapping drivers for chip access permet de définir le mapping mémoire de notre flash :
<*> CFI Flash device in physical memory map (0x10000000) Physical start address of flash mapping (0x1000000) Physical length of flash mapping
(2)    Bank width in octets
Nous informons la couche MTD que :
•    Notre flash est mappée physiquement en 0x10000000 ;
•    Qu'elle a une taille de 0x1000000 ;
•    Qu'elle est interfacée sur une largeur de données de 16 bits.
Une fois notre noyau configure, il est temps de le compiler par la commande :
S make ulmage
Image Name:    Linux-2.6.14-csb
Created:    Sun Mar 12 18:10:37 2006
Image Type:    ARM Linux Kernel Image (uncompressed)
Data Size:    1260196 Bytes    1230.66 kB = 1.20 MB
Load Address: 0x20008000 Entry Point: 0x20008000 Image arch/arm/boot/ulmage is ready
Le bon déroulement de cette compilation demande que le binaire mki mage soit disponible dans le chemin courant (ce binaire est compilé lors de la génération de u-boot, et est disponible dans le répertoire tool s de u-boot). mki mage permet d'encapsuler l'image noyau dans un fichier contenant les informations nécessaires à u-boot pour charger et exécuter le noyau.
$ mkimage
Usage: mkimage -1 image
-1 => list image header information
mkimage [-x] -A arch -0 os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image
-A => set architecture to 'arch' -0 => set operating system to 'os' -T    set image type to 'type'
-C ==> set compression type 'comp'
-a => set load address to 'addr' (hex) -e => set entry point to 'ep' (hex)
-n => set image name to 'name'
-d ==> use image data from 'datafile' -x ==> set XIP (execute in place)
6.4 INSTALLATION ET DÉMARRAGE
L'installation consiste simplement à charger l'image u Image  sur la carte (en SDRAM dans un premier temps) puis à la copier en flash, à l'adresse souhaitée.
IIIL
111111111111fflt
Arrow keys nevigate the menu. <Enter> select, submenun --->. nighlighted lettets are hockeys. Pressing <T> includes, <N> excludee. en> modularizes features. Press efsc><Eroc> to exit, 0> Cor Help, cor Search. Legend, () bullt-ln ( ] excluded en> module < >
TSIRM4200 Implementation. ---> --- Processor Type
[.] rapport APP19:07 processor
--- Processor Tentures
[ ] upport Miura> user binaries
(    inapte I-Cache
(leable D-Cache
[ ]    orce irrite through D-cache
Sélection de l'architecture (AT91RM9200 dans notre cas) et de
l'implémentation (CPUAT91 dans notre cas)
Linux Ternel YI...£.14 Configuration
Peros keys nayignte the menu. <Enter> selects submenus --->. Highlighted lettere are hockeys. Pressing <T> includes, <N> excludes, en> modularizes teatures. Pte», ersc>efsc> to exit, .0> for Rein, <i> for Search. Legend: [•]    [ ] excluded <M> module < >
[ ] reemptible Ternel [EXPEPIIKENTIL, [ ] yruneic tick rimer renty[nodellfintneteory,
saikmmesammErumm:
[•]    mer LED
[•]    PU usage LED
ecta
Activation de l'option des LED Timer et CPU