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

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)

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_size=12288 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)

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é).
>
> > [...]
>
> > "root=/dev/ram0 rootfstype=ext2.gz initrd=0x02000000
> > ramdisk_size=12288 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=00:04:9f:b5:69:3a root=/dev/mtdblock2 rootfstype=jffs2
noinitrd ip=none mtdparts=phys_mapped_flash:256k(Colilo),2816k(kern el),
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

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.

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

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 remplir
> à 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 ramdisk
> positionne probablement le périphérique "n'importe où" dans la mémoire
> physique.

C'est ce que je crains ...

> Sans garantie, car je n'ai jamais regardé de près, romfs est peut-être 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

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

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.
>
--
Kevin

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.

Samuel Colin <Samuel.Colin@localhost.localdomain.invalid> a écrit:

> Notons que travailler uniquement avec l'initrd, ça ferait quand même
> de l'initrd d'une taille conséquente.

Et c'est là - en fonction des contraintes - que l'initramfs peut devenir
sympathique.

--
Nicolas S.

Kevin Denis <kevin@nowhere.invalid> a écrit:

> L'initrd n'est pas compilé lors de la construction du noyau, c'est
> toi qui le crée.

Tout dépend des distributions en fait; l'outil genkernel chez Gentoo,
par exemple, en crée un par défault même si ce n'est pas demandé
explicitement.

--
Nicolas S.

On 2008-04-02, Nicolas S. <ni.s-factice@laposte.net> wrote:
>> Notons que travailler uniquement avec l'initrd, ça ferait quand même
>> de l'initrd d'une taille conséquente.
>
> Et c'est là - en fonction des contraintes - que l'initramfs peut devenir
> sympathique.
>
Peux tu broder? Sur les contraintes, et sur la sympathie nouvelle
de l'initramfs?
--
Kevin

Bonsoir,

Quelques chose m'échappe ... d'après ce que vous me dites, il serait
impossible d'avoir son système de fichier placé en RAM puis passé au
kernel, il faudrait fatalement passer par un support persistant
accessible par le linux (NFS, flash ...) ... pourtant c'est bien ce
que faisait le BSP basé sur 2.4 que j'ai utilisé ...
je chargeait en RAM mon image.bin (cat de linux.bin et romfs.bin) je
bootais simplement avec la commande root=/dev/ram et tout allait pour
le mieux ...

Aux vues de vos réponses, le Linux doit écraser la RAM en se lançant
(sauf l'endroit où il s'exécute) ... donc, dans le cas de ce BSP Linux
2.4, il devait y avoir un mécanisme qui protégeais le romfs ... et
ensuite il devait savoir où trouver exactement ce romfs :

RAMDISK: romfs filesystem found at block 0
RAMDISK: Loading 6090 blocks [1 disk] into ram disk... done.
Freeing initrd memory: 762k freed
VFS: Mounted root (romfs filesystem) readonly.

j'avais essayé de le déplacer un peu plus loin après le kernel ... il
n'était plus trouvé ... il y a sûrement une histoire de point d'entré
précis... mais je n'ai rien trouvé de plus.

Bonne soirée
Pk

Kevin Denis <kevin@nowhere.invalid> a écrit:

> Peux tu broder? Sur les contraintes, et sur la sympathie nouvelle
> de l'initramfs?

Je pensais à la supériorité de l'initramfs quant à l'espace en mémoire
nécessaire et réellement occupée. C'est plutôt bien expliqué ici:
http://linuxdevices.com/articles/AT4017834659.html

--
Nicolas S.

pk <PkGroupe@gmail.com> a écrit:

> Quelques chose m'échappe ... d'après ce que vous me dites, il serait
> impossible d'avoir son système de fichier placé en RAM puis passé au
> kernel

En effet, c'est impossible à ma connaissance. Mais je pense que tu
t'embrouilles les idées en raison d'un problème de formulation.
Le kernel accepte un initrd ou un initramfs (passé en paramètre) mais en
pratique, c'est d'abord le noyau qui est chargé.

> kernel, il faudrait fatalement passer par un support persistant
> accessible par le linux (NFS, flash ...) ... pourtant c'est bien ce
> que faisait le BSP basé sur 2.4 que j'ai utilisé ...

À cette époque, il s'agissait plutôt d'un fichier de type block device
monté en loopback. Seul initramfs est un système de fichiers.


--
Nicolas S.

pk wrote:

> Bonsoir,
>
> Quelques chose m'échappe ... d'après ce que vous me dites, il serait
> impossible d'avoir son système de fichier placé en RAM puis passé au
> kernel, il faudrait fatalement passer par un support persistant
> accessible par le linux (NFS, flash ...) ..

A priori, sur un système embarqué autonome viable, il faut bien qu'au moins
le noyau soit sur un support "persistant" avant son chargement, quel que
soit le mode d'accès à ce support.
Ensuite le noyau peut utiliser un système de fichier sur support persistant
ou le charger en ramdisk depuis un support persistant, sachant que le noyau
voit le ramdisk comme un periphérique et non comme une zone mémoire.


> pourtant c'est bien ce
> que faisait le BSP basé sur 2.4 que j'ai utilisé ...

Qu'est ce qu'un BSP ?



> je chargeait en RAM mon image.bin (cat de linux.bin et romfs.bin) je
> bootais simplement avec la commande root=/dev/ram et tout allait pour
> le mieux ...

Cela ressemble un peu à ce qu'on fait en recopiant un noyau et une image de
système à la queue leu leu sur une disquette avec une commande dd, sans
formatage, puis en modifiant in situ le noyau (commande rdev) pour lui
indiquer ou trouver le-dit système pour le charger en ramdisk.

C'est une manipulation que je sais faire avec les noyaux de la série 2.4.,
mais dont je suppute qu'elle n'est plus possible avec les noyaux de la
série 2.6, puisque ceux-ci ne supportent plus le boot direct.

Pour réaliser la même opération, il faut formater la disquette en ext2, y
recopier par cp le noyau et l'image du système, construire un lilo.conf ad
hoc et installer le booteur. C'est un mécanisme d'initrd qui est alors mis
en oeuvre.

(Notez que vous spécifiez /dev/ram et non /dev/ram0 comme mentionné dans vos
précédent messages.)

>
> Aux vues de vos réponses, le Linux doit écraser la RAM en se lançant
> (sauf l'endroit où il s'exécute) ... donc, dans le cas de ce BSP Linux
> 2.4, il devait y avoir un mécanisme qui protégeais le romfs ... et
> ensuite il devait savoir où trouver exactement ce romfs :
>
> RAMDISK: romfs filesystem found at block 0
> RAMDISK: Loading 6090 blocks [1 disk] into ram disk... done.
> Freeing initrd memory: 762k freed
> VFS: Mounted root (romfs filesystem) readonly.
>
> j'avais essayé de le déplacer un peu plus loin après le kernel ... il
> n'était plus trouvé ... il y a sûrement une histoire de point d'entré
> précis... mais je n'ai rien trouvé de plus.

Il n'est pas impossible, dans cette démarche, que le ramdisk ait été créé
ailleurs dans la mémoire puis rempli à partir des octets présents juste
après le noyau en mémoire.

Quand vous écrivez que vous chargiez en RAM la concaténation du noyau et de
l'image du système de fichier, est ce une copie directe, ou l'outil de
chargement est il susceptible de simuler dans la ram un support de
disquette ou autre ?

Incidemment, je ne suis pas sur que nous ayons la même vision de ce qu'est
un romfs :-)

Incidemment numéro deux, connaissez qemu ? C'est outil est un peu casse-pied
a utiliser mais je n'ai rien trouvé de mieux pour essayer un système
embarqué sans machine cible.

--
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

Merci pour vos réponses,


On Apr 4, 9:34 am, Dominique MICOLLET <Dominique.Micol...@u-
bourgogne.fr.fr.fr> wrote:

> A priori, sur un système embarqué autonome viable, il faut bien qu'au moins
> le noyau soit sur un support "persistant" avant son chargement, quel que
> soit le mode d'accès à ce support.

Oui c'est évident, ce que je voulais dire, c'est que le Linux ne
voyait pas ce support ...
Par exemple, dans l'application où j'ai utilisé le 2.4, le fichier
(noyau + romfs) était stocké en Flash.
à la mise sous tension, un "moniteur" très basique copiait directement
ce fichier en RAM, et bootait... mais en aucun cas le Linux alors
lancé ne voyait cette flash.


> Qu'est ce qu'un BSP ?

pardon, c'est ensemble noyau + application + outils de compilation
prévu spécialement pour un processeur et une carte précise (c'est le
linux fournis par freescale pour leur carte d'évaluation).


> C'est une manipulation que je sais faire avec les noyaux de la série 2.4..,
> mais dont je suppute qu'elle n'est plus possible avec les noyaux de la
> série 2.6, puisque ceux-ci ne supportent plus le boot direct.

Ok...

> (Notez que vous spécifiez /dev/ram et non /dev/ram0 comme mentionné dans vos
> précédent messages.)

il me semblait avoir compris que /dev/ram pointait vers /dev/ram0,
d'où ma façon de les mélanger allègrement ...


> Il n'est pas impossible, dans cette démarche, que le ramdisk ait étécréé
> ailleurs dans la mémoire puis rempli à partir des octets présents juste
> après le noyau en mémoire.

Oui, c'est ce que j'aurai aimé faire avec le 2.6 aussi ... mais
j'avoue que même sur le 2.4 pour moi c'est un peu de la magie !

> Quand vous écrivez que vous chargiez en RAM la concaténation du noyau et de
> l'image du système de fichier, est ce une copie directe, ou l'outil de
> chargement est il susceptible de simuler dans la ram un support de
> disquette ou autre ?

nonon c'est bien une copie directe ( boucle for de copie ... rien de
plus)!

> Incidemment, je ne suis pas sur que nous ayons la même vision de ce qu'est
> un romfs :-)

C'est bien possible ...
Pour moi c'est un type de système de fichiers en lecture seul prévu
pour être placé en RAM ...
et pour vous ?

> Incidemment numéro deux, connaissez qemu ? C'est outil est un peu casse-pied
> a utiliser mais je n'ai rien trouvé de mieux pour essayer un système
> embarqué sans machine cible.

j'en ai entendu parlé, mais je ne l'ai jamais utilisé ....
que m'apporterait son utilisation, sachant que j'ai la machine cible
(carte d'évaluation coldfire) ?


> Cordialement

Encore merci,
Cordialement,
Pk

On 2008-04-03, pk <PkGroupe@gmail.com> wrote:
> Quelques chose m'échappe ... d'après ce que vous me dites, il serait
> impossible d'avoir son système de fichier placé en RAM puis passé au
> kernel,

Mais si.
Mais cela dépend ce que tu appelles ton système de fichier.

Aujourd'hui, un noyau linux peut booter en deux temps:
1. le noyau démarre.
2. le noyau charge un intramfs (ou initrd).
3. la racine est montée.

Parti de la, tu as deux solutions:
-rester ad vitam dans ton init[rd|ramfs]. Ca pose pas de problème,
ca fonctionne bien.
-utiliser l'initrd pour créer un système de fichier en RAM, copier
des fichiers la dedans, et monter la racine dans ce ramfs. Ca m'a
l'air compliqué pour pas grand chose.

Donc, ma question est:
si tu veux tout mettre en RAM, c'est que tu ne dois pas avoir grand chose,
car la RAM devra contenir ta racine, tes fichiers, et de l'espace
suffisant pour bosser.
Donc, la distribution que tu as créée, mets la dans un initrd ou
initramfs, et démarre un linux en lui passant cet initrd en
argument. Le noyau va démarrer tout ça. Le but consiste donc à ne
jamais sortir de ton initrd.
--
Kevin