Linux en RAM

Le
pk
Bonjour,

Je travail actuellement sur le test d'un système Linux sur coldfire
5485.
J'utilise le BSP Linux, basé sur le noyau 2.6.10, fournit par
freescale, et leur carte dévaluation 5485.

Jusqu'à présent, je réalisait mes essais en montant le système de
fichiers root sur NFS ou en Flash (jffs2).
J'ai maintenant besoin d'utiliser un système _exclusivement_ en RAM
(noyau + Système de fichiers), mais je ne comprend pas bien comment
procéder

J'utilise le bootloader Colilo (dérivé de Lilo).

Dans les options de compilation du noyau, j'ai le choix, pour un
système de fichiers root en RAM, entre "cramfs" et "ext2.gz Ramdisk".

J'ai essayé d'utiliser "ext2.gz Ramdisk". La compilation me génère
alors le noyau "vmlinux.bin" (2.6Mo) et le système de fichiers
"rootfs.ext2.gz" (3Mo, 9Mo décompressé).

J'ai activé les supports suivants pour le noyau :

<*> RAM disk support
(5) Default number of RAM disks
(12288) Default RAM disk size (kbytes)
[*] Initial RAM disk (initrd) support
<*> Second extended fs support
[*] Ext2 extended attributes
<*> ROM file system support
[*] /dev file system support
[*] Virtual memory file system support
[*] tmpfs Extended Attributes

Ensuite, j'ai procédé de la façon suivante :
- placement du "rootfs.ext2.gz" en RAM (0x02000000)
- placement du noyau "vmlinux.bin" en RAM (0x1000)
- ligne de commande de colilo :
"root=/dev/ram0 rootfstype=ext2.gz initrd=0x02000000
ramdisk_size=12288 load_ramdisk=1 keepinitrd"
- lancement du noyau (g 0x2000)

"starting up linux rev 0.2: startmem 0xc022c000, size 125MB
[]
Memory: 127848k/131072k available (1568k kernel code, 1384k data, 80k
init)
[]
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: devfs_debug: 0x0
devfs: boot_options: 0x1
[]
RAMDISK driver initialized: 5 RAM disks of 12288K size 1024 blocksize
[]
VFS: Cannot open root device "ram0" or unknown-block(1,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-
block(1,0)"

Pouvez-vous, svp, m'expliquer comment avoir mon système en RAM, qu'est
ce qui ne vas pas ici ? Comment indiquer le rootfs au noyau ?

Merci de votre aide,
Pk
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mihamina Rakotomandimby
Le #1963865
pk wrote:
Bonjour,


Bonjour,

J'ai maintenant besoin d'utiliser un système _exclusivement_ en RAM
(noyau + Système de fichiers),


J'ai peut-être tres mal compris ce que tu veux faire, mais il me semble
que la RAM est quelquechose qui s'efface au moins à chaque coupure
d'alimentation. Ce qui veut dire qu'apres un cycle de mise hors tension
+ remise sous tension, ce qui est dans la RAM sera perdu.
Il te faudra donc un support moins volatile pour tout remettre dans la
RAM. Ce qui revient à utiliser autre chose que la RAM...

--
Huile Essentielle de Camphre http://www.huile-camphre.fr
Infogerance http://www.infogerance.us
(Serveurs, Postes de travail, Développement logiciel)

Samuel Colin
Le #1964409
Dixit pk :
Bonjour,

Bonjour,


J'ai essayé d'utiliser "ext2.gz Ramdisk". La compilation me génère
alors le noyau "vmlinux.bin" (2.6Mo) et le système de fichiers
"rootfs.ext2.gz" (3Mo, 9Mo décompressé).

[...]

"root=/dev/ram0 rootfstype=ext2.gz initrd=0x02000000
ramdisk_size288 load_ramdisk=1 keepinitrd"

Hmmm, tu as compilé aussi un initrd ? Sinon je vois pas (il faudrait que

j'essaie de faire la même chose pour voir où pourrait se trouver le
problème mais j'ai pas le temps)

pk
Le #1964402
On Mar 31, 1:28 pm, Samuel Colin
Dixit pk :> Bonjour,

Bonjour,

J'ai essayé d'utiliser "ext2.gz Ramdisk". La compilation me génère
alors le noyau "vmlinux.bin" (2.6Mo) et le système de fichiers
"rootfs.ext2.gz" (3Mo, 9Mo décompressé).

[...]

"root=/dev/ram0 rootfstype=ext2.gz initrd=0x02000000
ramdisk_size288 load_ramdisk=1 keepinitrd"


Hmmm, tu as compilé aussi un initrd ? Sinon je vois pas (il faudrait que
j'essaie de faire la même chose pour voir où pourrait se trouver le
problème mais j'ai pas le temps)


Bonjour,
Non je n'ai pas de initrd compilé, j'ai surement mal compris cette
notion ...
quand je travaillait avec un système de fichiers en Flash, j'avais la
ligne de commande suivante, et tout marchait très bien :
"set cl mac0:04:9f:b5:69:3a root=/dev/mtdblock2 rootfstype=jffs2
noinitrd ip=none mtdparts=phys_mapped_flash:256k(Colilo),2816k(kernel),
3072k(user),-(others)"

En fait, je voudrait faire exactement la même chose, mais avec un
système de fichier en RAM ... sauf que je n'arrive pas à comprendre
comment faire pointer le noyau vers l'adresse où je charge mon système
de fichiers (dans mes tests un ext2.gz)...
En flash c'était plus simple, puisque je donnait le mapping, et je
savait donc mtdblock2 =0x....
Là j'ai des ramdisks ram0, ram1 et ram2 ... mais je ne sait pas à
quelles adresses physiques ils correpondent ...
au boot, j'ai la ligne suivante :
"starting up linux rev 0.2: startmem 0xc0204000, size 125MB"
ou encore :
"Memory: 128008k/131072k available (1424k kernel code, 1368k data, 80k
init)"

Je me suis dis que mon ram0 était peut-être en 0xc0204000, et j'ai
essayer d'y charger mon rootfs.ext2.gz, ou sa version décompressée
rootfs.ext2 ... sans succès ...

Je passe probablement à côté d'une notion essentielle ...
Merci de votre aide,
Pk


Samuel Colin
Le #2051981
Dixit pk :

Bonjour,
Non je n'ai pas de initrd compilé, j'ai surement mal compris cette
notion ...
[...]
En fait, je voudrait faire exactement la même chose, mais avec un
système de fichier en RAM ... sauf que je n'arrive pas à comprendre
comment faire pointer le noyau vers l'adresse où je charge mon système
de fichiers (dans mes tests un ext2.gz)...

Ça doit se faire en deux temps.

Quand tu montais le root dans la flash, le système était déjà présent
dans la flash. Y'avait qu'à démarrer init et c'était bon.

En RAM c'est plus compliqué : il faut charger le système voulu (depuis
une mémoire flash, depuis du nfs, etc, etc) avant de pouvoir le monter
et charger init et le reste.
Donc le principe est de construire un initrd qui contiendra un système
minimal capable d'aller chercher une image du système et de la mettre à
la bonne place (ici dans un ramdisk) et seulement ensuite de monter le
ramdisk et démarrer dessus.

Une recherche google avec les mots-clefs diskless et ramdisk peut aider,
aussi.

pk
Le #2051961
Ok je comprend un peu mieux, merci !

Mais je me demande autre chose : est-ce que je ne pourrai pas
reproduire les conditions du montage sur flash ?

Je veux dire par là que si je connaissais l'adresse physique ou
pointe /dev/ram0 (ce qui n'est pas le cas), je pourrai directement y
charger le système de fichier décompressé (rootfs.ext2) et passer en
ligne de commande quelque chose comme "noinitrd root=/dev/ram0
rootfstype=ext2" ... tout faux ?

Encore merci

Pk

On Apr 2, 4:04 pm, Samuel Colin
Dixit pk :

Bonjour,
Non je n'ai pas de initrd compilé, j'ai surement mal compris cette
notion ...
[...]
En fait, je voudrait faire exactement la même chose, mais avec un
système de fichier en RAM ... sauf que je n'arrive pas à comprendre
comment faire pointer le noyau vers l'adresse où je charge mon systè me
de fichiers (dans mes tests un ext2.gz)...


Ça doit se faire en deux temps.
Quand tu montais le root dans la flash, le système était déjà pr ésent
dans la flash. Y'avait qu'à démarrer init et c'était bon.

En RAM c'est plus compliqué : il faut charger le système voulu (depuis
une mémoire flash, depuis du nfs, etc, etc) avant de pouvoir le monter
et charger init et le reste.
Donc le principe est de construire un initrd qui contiendra un système
minimal capable d'aller chercher une image du système et de la mettre à
la bonne place (ici dans un ramdisk) et seulement ensuite de monter le
ramdisk et démarrer dessus.

Une recherche google avec les mots-clefs diskless et ramdisk peut aider,
aussi.



Dominique MICOLLET
Le #2054811
pk wrote:

Mais je me demande autre chose : est-ce que je ne pourrai pas
reproduire les conditions du montage sur flash ?

Je veux dire par là que si je connaissais l'adresse physique ou
pointe /dev/ram0 (ce qui n'est pas le cas), je pourrai directement y
charger le système de fichier décompressé (rootfs.ext2)


Question : comment ferez-vous ce chargement ?
N'oubliez pas qu'une mémoire flash est pérenne - donc qu'on peut la remplir
à l'avance - alors qu'une mémoire ram est par définition volatile.


et passer en
ligne de commande quelque chose comme "noinitrd root=/dev/ram0
rootfstype=ext2" ... tout faux ?


A priori pourquoi pas, encore que le pilote de périphérique des ramdisk
positionne probablement le périphérique "n'importe où" dans la mémoire
physique.
Sans garantie, car je n'ai jamais regardé de près, romfs est peut-être plus
prévisible dans son comportement.

Indication : avec lilo, quand je monte un système en ramdisk, c'est /dev/ram
qui contient le rfs. Ça dépend peut-être du noyau.


--
Cordialement

Dominique MICOLLET Email : enlever deux fr
Universite de Bourgogne
9, Avenue Alain SAVARY BP 47870 Tel : +33/(0)3-80-39-59-27
21078 DIJON CEDEX FRANCE Tfx : +33/(0)3-80-39-68-69

pk
Le #2054761
Bonsoir,

Je veux dire par là que si je connaissais l'adresse physique ou
pointe /dev/ram0 (ce qui n'est pas le cas), je pourrai directement y
charger le système de fichier décompressé (rootfs.ext2)


Question : comment ferez-vous ce chargement ?
N'oubliez pas qu'une mémoire flash est pérenne - donc qu'on peut la re mplir
à l'avance - alors qu'une mémoire ram est par définition volatile.



Mon bootloader/debogueur (Colilo) possède un client tftp ... je
l'utilise pour charger directement en ram le noyau (et je pensai
pouvoir en faire de même pour le rfs)

et passer en
ligne de commande quelque chose comme "noinitrd root=/dev/ram0
rootfstype=ext2" ... tout faux ?


A priori pourquoi pas, encore que le pilote de périphérique des ramdis k
positionne probablement le périphérique "n'importe où" dans la mém oire
physique.


C'est ce que je crains ...

Sans garantie, car je n'ai jamais regardé de près, romfs est peut-êt re plus
prévisible dans son comportement.



Justement, lorsque je fait des essais avec un vieux bsp linux basé sur
2.4, il fabrique tout seul un fichier image.bin, concaténation du
linux.bin et du romfs.bin

Mais avec le 2.6, il n'y a pas cette "image.bin" créée ... et il ne
propose pas de FS romfs ... cramfs seulement, mais c'est le même
problème, je n'arrive pas la faire pointer dessus (si si, j'ai bien
essayé de faire un cat de mon vmlinux.bin et de mon
cramfs.big ... :-))

Cordialement


Merci,
Bonne soirée,
Pk


Dominique MICOLLET
Le #2056491
pk wrote:


Mon bootloader/debogueur (Colilo) possède un client tftp ... je
l'utilise pour charger directement en ram le noyau (et je pensai
pouvoir en faire de même pour le rfs)



Si je comprends bien, colilo transfère des octets depuis quelque part vers
la mémoire du système cible, ces octets représentant le noyau et le rfs
Puis le noyau démarre : on peut imaginer que le noyau sait ou il est, et
qu'il ne s'écrasera pas lui-même.

Mais si vous transférez le rfs _avant_ le démarrage du noyau, ce rfs va
s'installer en un point quelconque que le noyau va superbement ignorer, et
joyeusement écraser. Il faudrait que colilo soit capable de forcer le noyau
à réserver un ramdisk à un endroit spécifique de la mémoire : j'ignore si
linux le permet (et je parierais qu'il ne le permet pas).

Et là, je ne vois pas de solution simple. Je crains qu'il ne faille
s'orienter vers la technique mise en oeuvre sur les systèmes diskless :
après démarrage du noyau le système est chargé par un tftp ou quelque chose
du genre (j'ai fait cela il y a très longtemps et j'ai oublié :-()


--
Cordialement

Dominique MICOLLET Email : enlever deux fr
Universite de Bourgogne
9, Avenue Alain SAVARY BP 47870 Tel : +33/(0)3-80-39-59-27
21078 DIJON CEDEX FRANCE Tfx : +33/(0)3-80-39-68-69

Kevin Denis
Le #2056441
On 2008-04-02, Samuel Colin
Non je n'ai pas de initrd compilé, j'ai surement mal compris cette
notion ...

L'initrd n'est pas compilé lors de la construction du noyau, c'est toi


qui le crée.
Aujourd'hui, c'est d'ailleurs plutôt un initramfs qui est utilisé,
mais qui est compatible initrd.

En fait, je voudrait faire exactement la même chose, mais avec un
système de fichier en RAM ... sauf que je n'arrive pas à comprendre
comment faire pointer le noyau vers l'adresse où je charge mon système
de fichiers (dans mes tests un ext2.gz)...


Vu le nom, je dirais que ca ressemble a un fichier loop, formatté ext2

et compressé? Ca doit donc pouvoir être utilisé comme un initrd.
bootes avec le lien justement: initrd=ext2.gz
Le noyau va monter le fichier ext2.gz, et exécuter le programme appelé
linuxrc à la racine d'icelui.
Si tu ne peux pas créer ce fichier linuxr, ajoutes en command line
parameter du noyau:
rdinit=/bin/cequetusouhaite

avec ce programme responsable du lancement de ton système.

Ça doit se faire en deux temps.
Quand tu montais le root dans la flash, le système était déjà présent
dans la flash. Y'avait qu'à démarrer init et c'était bon.

En RAM c'est plus compliqué : il faut charger le système voulu (depuis
une mémoire flash, depuis du nfs, etc, etc) avant de pouvoir le monter
et charger init et le reste.


Pourquoi ne pas travailler qu'uniquement avec l'initrd?

Donc le principe est de construire un initrd qui contiendra un système
minimal capable d'aller chercher une image du système et de la mettre à
la bonne place (ici dans un ramdisk) et seulement ensuite de monter le
ramdisk et démarrer dessus.

--

Kevin


Samuel Colin
Le #2060671
Dixit Kevin Denis :

En RAM c'est plus compliqué : il faut charger le système voulu (depuis
une mémoire flash, depuis du nfs, etc, etc) avant de pouvoir le monter
et charger init et le reste.


Pourquoi ne pas travailler qu'uniquement avec l'initrd?

Je sais, c'est possible, mais ma pratique date du temps où on faisait

la technique "mini-initrd" puis chargement du vrai système.
Notons que travailler uniquement avec l'initrd, ça ferait quand même
de l'initrd d'une taille conséquente.


Publicité
Poster une réponse
Anonyme