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 ?
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
pk
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
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.
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
Nicolas S.
Kevin Denis 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.
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
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.
Nicolas S.
pk 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 <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.
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.
Dominique MICOLLET
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
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
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
pk
Merci pour vos réponses,
On Apr 4, 9:34 am, Dominique MICOLLET 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é da ns 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 ju ste 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'e st 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
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é da ns 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 ju ste
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'e st
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) ?
On Apr 4, 9:34 am, Dominique MICOLLET 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é da ns 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 ju ste 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'e st 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
Kevin Denis
On 2008-04-03, pk 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
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
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
