1 votes

Système de fichiers racine Linux sur matériel personnalisé

J'ai un SoC personnalisé conçu sur FPGA, basé sur un clone de processeur ARM, sur lequel j'essaie de démarrer Linux (noyau 3.10).

J'ai ajouté avec succès le support de mes périphériques personnalisés (un USART, un contrôleur d'interruptions et un minuteur), ce qui me permet de voir les messages printk affichés par le noyau jusqu'au moment où j'essaie de monter le système de fichiers racine.

J'ai une mémoire non volatile personnalisée de 2 Go, en accès aléatoire, en lecture/écriture, mappée de l'adresse 0 à 0x7FFFFFFF à partir de laquelle le chargeur de démarrage s'exécute, et qui contient le noyau et la partition du système de fichiers. Le chargeur de démarrage copie le noyau dans la RAM (256 Mo, de 0x80000000 à 0x8FFFFFFF) puis passe le contrôle à Linux, qui échoue au point : "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)".

D'après mes débugs et mes recherches sur internet, il semble que le noyau ne reconnaisse pas ma mémoire non volatile, et donc ne peut pas monter le système de fichiers.

Comment puis-je dire au noyau qu'il doit démarrer à partir de cette mémoire, et quel code doit être ajouté au noyau ? Par exemple, serait-il possible de faire croire au noyau que ma mémoire est un Nand, et de modifier les pilotes Nand pour y accéder correctement ?

Merci d'avance pour toute aide et suggestions.

0voto

LawrenceC Points 70381

Je ne suis pas sûr de ce que vous faites actuellement pour votre "partition de système de fichiers." Mais vous pouvez placer un initrd dans votre stockage non volatile qui ressemble/agit comme de la RAM, puis demander à votre chargeur d'amorçage de dire à Linux d'utiliser l'initrd.

La plupart des initrds effectuent une installation puis essaient de ré-monter un système de fichiers racine sur un périphérique de blocs. Dans votre cas, votre initrd serait votre véritable système de fichiers racine et vous devriez placer des utilitaires comme des shells, etc. dans l'initrd.

Lors du démarrage sur ARM en utilisant U-Boot, les commandes de démarrage chargent le noyau et l'initrd depuis un périphérique de stockage dans un emplacement RAM fixe, puis l'adresse de l'initrd est transmise au noyau en tant que paramètre de ligne de commande, en spécifiant l'adresse.


Eh bien, le pilote MTD peut prendre une section de RAM (il y a une option "RAM système physique" dans le pilote MTD sur make menuconfig) et le transformer en un périphérique de blocs, si vous avez vraiment besoin d'un périphérique de blocs en lecture/écriture. Il peut être utilisé pour monter la RAM de la carte graphique comme une petite partition d'échange, par exemple. Voir ceci.

Je pense que la commande pour le faire serait modprobe phram phram=0x00100000;256MiB, si vous avez un système de fichiers de 256Mio à l'emplacement mémoire 0x00100000. Ensuite modprobe mtdblock ce qui crée /dev/mtdblock0. Vous pouvez ensuite faire des choses comme mount /dev/mtdblock0 et ainsi de suite. Donc vous auriez besoin d'un petit script dans un initrd qui fait ce qui précède, puis fsck /dev/mtdblock0, et ensuite démarre votre init ou tout autre processus 1.

Vous pourriez même spécifier tout cela sur la ligne de commande du noyau d'une manière ou d'une autre mais je ne suis pas sûr que ce soit pris en charge. Vous voudrez peut-être utiliser un petit initrd de toute façon pour être flexible.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X