Linux-Root-Dateisystem auf benutzerdefinierter Hardware

Linux-Root-Dateisystem auf benutzerdefinierter Hardware

Ich habe ein individuell entwickeltes, auf FPGA implementiertes SoC, das auf einem ARM-Prozessor-Klon basiert, auf dem ich versuche, Linux (Kernel 3.10) zu booten.

Ich habe erfolgreich Unterstützung für meine benutzerdefinierten Peripheriegeräte (einen USART, einen Interrupt Controller und einen Timer) hinzugefügt, sodass ich die vom Kernel angezeigten Printk-Meldungen bis zu dem Versuch sehen kann, das Root-Dateisystem zu mounten.

Ich habe einen 2 GB großen, nichtflüchtigen Speicher mit Direktzugriff, Lese- und Schreibzugriff, der von Adresse 0 bis 0x7FFFFFFF gemappt ist, von dem aus der Bootloader ausgeführt wird und der den Kernel und die Dateisystempartition enthält. Der Bootloader kopiert den Kernel in den RAM (256 MB, von 0x80000000 bis 0x8FFFFFFF) und übergibt dann die Kontrolle an Linux, das an folgender Stelle fehlschlägt: „Kernel-Panik – keine Synchronisierung: VFS: Root-FS kann nicht auf unbekanntem Block (0,0) gemountet werden“.

Aus meinen Debugging- und Internetrecherchen geht hervor, dass der Kernel meinen nichtflüchtigen Speicher nicht erkennen kann und daher das Dateisystem nicht mounten kann.

Wie sage ich dem Kernel, dass er von diesem Speicher booten soll, und welcher Code muss dem Kernel hinzugefügt werden? Wäre es beispielsweise möglich, den Kernel glauben zu lassen, mein Speicher sei ein NAND, und NAND-Treiber so zu ändern, dass sie richtig darauf zugreifen können?

Vielen Dank im Voraus für alle Hilfe und Vorschläge.

Antwort1

Ich bin nicht sicher, was Sie jetzt für Ihre „Dateisystempartition“ tun. Aber Sie können ein initrd in Ihren nichtflüchtigen Speicher legen, das wie RAM aussieht/funktioniert, und dann Ihren Bootloader Linux anweisen lassen, das initrd zu verwenden.

Die meisten Initrds führen einige Setups durch und versuchen dann, ein Root-Dateisystem auf einem Blockgerät erneut zu mounten. In Ihrem Fall wäre Ihr Initrd Ihr echtes Root-Dateisystem und Sie müssten Dienstprogramme wie Shells usw. im Initrd platzieren.

Beim Booten auf ARM mit U-Boot laden die Boot-Befehle grundsätzlich den Kernel und initrd von einem Speichergerät in einen festen RAM-Speicherort, und dann wird die Adresse von initrd als Befehlszeilenparameter an den Kernel übergeben, wobei die Adresse angegeben wird.


Nun, der MTD-Treiber kann einen Abschnitt des RAM (es gibt eine Option „Physical System RAM“ im MTD-Treiber make menuconfig) in ein Blockgerät umwandeln, wenn Sie wirklich ein lesbares/beschreibbares Blockgerät benötigen. Er kann beispielsweise verwendet werden, um den RAM der Grafikkarte als kleine Swap-Partition zu mounten. Sieh dir das an.

Ich glaube, der Befehl dafür wäre modprobe phram phram=0x00100000;256MiB, wenn Sie ein 256 MByte großes Dateisystem am Speicherort 0x00100000 haben. Dann modprobe mtdblockmacht das /dev/mtdblock0. Sie können dann mount /dev/mtdblock0solche Dinge tun. Sie brauchen also ein kleines Skript in einem initrd, das das oben genannte tut, dann fsck /dev/mtdblock0, und dann Ihren oder was auch immer Ihr Prozess 1 ist, startet init.

Möglicherweise können Sie das alles sogar irgendwie in der Kernel-Befehlszeile angeben, aber ich bin nicht sicher, ob das unterstützt wird. Vielleicht möchten Sie aus Flexibilität trotzdem ein kleines initrd verwenden.

verwandte Informationen