Je travail actuellement sur le test d'un syst=E8me Linux sur coldfire
5485.
J'utilise le BSP Linux, bas=E9 sur le noyau 2.6.10, fournit par
freescale, et leur carte d=E9valuation 5485.
Jusqu'=E0 pr=E9sent, je r=E9alisait mes essais en montant le syst=E8me de
fichiers root sur NFS ou en Flash (jffs2).
J'ai maintenant besoin d'utiliser un syst=E8me _exclusivement_ en RAM
(noyau + Syst=E8me de fichiers), mais je ne comprend pas bien comment
proc=E9der ...
J'utilise le bootloader Colilo (d=E9riv=E9 de Lilo).
Dans les options de compilation du noyau, j'ai le choix, pour un
syst=E8me de fichiers root en RAM, entre "cramfs" et "ext2.gz Ramdisk".
J'ai essay=E9 d'utiliser "ext2.gz Ramdisk". La compilation me g=E9n=E8re
alors le noyau "vmlinux.bin" (2.6Mo) et le syst=E8me de fichiers
"rootfs.ext2.gz" (3Mo, 9Mo d=E9compress=E9).
J'ai activ=E9 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=E9d=E9 de la fa=E7on suivante :
- placement du "rootfs.ext2.gz" en RAM (0x02000000)
- placement du noyau "vmlinux.bin" en RAM (0x1000)
- ligne de commande de colilo :
"root=3D/dev/ram0 rootfstype=3Dext2.gz initrd=3D0x02000000
ramdisk_size=3D12288 load_ramdisk=3D1 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=3D" 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=E8me en RAM, qu'est
ce qui ne vas pas ici ? Comment indiquer le rootfs au noyau ?
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)
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)
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
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é).
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)
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é).
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é).
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
On Mar 31, 1:28 pm, Samuel Colin wrote:
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é).
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
On Mar 31, 1:28 pm, Samuel Colin
<Samuel.Co...@localhost.localdomain.invalid> wrote:
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é).
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=00: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
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é).
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
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.
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.
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
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 wrote:
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.
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
<Samuel.Co...@localhost.localdomain.invalid> wrote:
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.
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 wrote:
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
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 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
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
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
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 ... :-))
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
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
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
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
On 2008-04-02, Samuel Colin wrote:
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
On 2008-04-02, Samuel Colin <Samuel.Colin@localhost.localdomain.invalid> wrote:
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.
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
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.
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.
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.
