Fehler beim Drucken:
VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
0100 16384 ram0
(driver?)
0101 16384 ram1
(driver?)
0102 16384 ram2
(driver?)
0103 16384 ram3
(driver?)
0104 16384 ram4
(driver?)
0105 16384 ram5
(driver?)
0106 16384 ram6
(driver?)
0107 16384 ram7
(driver?)
0108 16384 ram8
(driver?)
0109 16384 ram9
(driver?)
010a 16384 ram10
(driver?)
010b 16384 ram11
(driver?)
010c 16384 ram12
(driver?)
010d 16384 ram13
(driver?)
010e 16384 ram14
(driver?)
010f 16384 ram15
(driver?)
1f00 1024 mtdblock0
(driver?)
1f01 128 mtdblock1
(driver?)
1f02 4096 mtdblock2
(driver?)
1f03 128 mtdblock3
(driver?)
1f04 5120 mtdblock4
(driver?)
1f05 22272 mtdblock5
(driver?)
b300 15138816 mmcblk0
driver: mmcblk
b301 512000 mmcblk0p1 f7632111-01
b302 14625792 mmcblk0p2 f7632111-02
b308 7634944 mmcblk1
driver: mmcblk
b309 7634936 mmcblk1p1 9269d97b-01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
CPU0: stopping
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-xilinx-v2020.2 #1
Hardware name: Xilinx Zynq Platform
[<c010e37c>] (unwind_backtrace) from [<c010a128>] (show_stack+0x10/0x14)
[<c010a128>] (show_stack) from [<c0752204>] (dump_stack+0xb4/0xd0)
[<c0752204>] (dump_stack) from [<c010c964>] (ipi_cpu_stop+0x3c/0x98)
[<c010c964>] (ipi_cpu_stop) from [<c010d1b0>] (handle_IPI+0x64/0x80)
[<c010d1b0>] (handle_IPI) from [<c0364fa4>] (gic_handle_irq+0x84/0x90)
[<c0364fa4>] (gic_handle_irq) from [<c0101a8c>] (__irq_svc+0x6c/0xa8)
Exception stack(0xc0c01ee0 to 0xc0c01f28)
1ee0: 00000000 00000000 2ec8c000 ef7d0180 c0c2b9e4 00000000 ef7cf578 00000000
1f00: 69a89591 69fce0e3 00000000 00000000 fffffff5 c0c01f30 c0561c54 c0561c78
1f20: 60000013 ffffffff
[<c0101a8c>] (__irq_svc) from [<c0561c78>] (cpuidle_enter_state+0xec/0x288)
[<c0561c78>] (cpuidle_enter_state) from [<c0561e50>] (cpuidle_enter+0x28/0x38)
[<c0561e50>] (cpuidle_enter) from [<c013ecac>] (do_idle+0x230/0x258)
[<c013ecac>] (do_idle) from [<c013ee38>] (cpu_startup_entry+0x18/0x1c)
[<c013ee38>] (cpu_startup_entry) from [<c0b00ca0>] (start_kernel+0x388/0x424)
[<c0b00ca0>] (start_kernel) from [<00000000>] (0x0)
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---
Fehleranalyse:
Ich weiß nicht, wo ich die Rootfs booten soll, aber die verschiedenen Bereiche der SD-Karte wurden gescannt.
Einige bei der Lösung des Problems festgestellte Probleme:
Problem:
(1) Beim Dekomprimieren des komprimierten Pakets der von PetaLinux generierten RootFS-Datei ist ein Fehler aufgetreten. Fehlermeldung
:
Die Verwendung von Bandzip zum Dekomprimieren unter Windows meldet einen Fehler. Doppelte Dateien können nicht sein Hier gelöst, empfiehlt es sich, diese direkt unter Ubantu zu beziehen.
Wenn Sie auf einem Remote-Ubantu-System kompilieren, fügen Sie zunächst Berechtigungen hinzu, kopieren Sie in den freigegebenen Windows-Ordner, kopieren Sie dann vom Remote-Ende zum lokalen Windows und dann vom lokalen Windows zum lokalen Ubantu.
Beim Dekomprimieren unter Ubantu kommt es häufig zu Fehlern wie „Berechtigung verweigert“ und „Ungültiger Betrieb“, hauptsächlich weil für die Dekomprimierung des Root-Dateisystems bestimmte Berechtigungen erforderlich sind. Nachdem ich hier lange recherchiert hatte, stellte ich fest, dass das Remote-Ubantu normal dekomprimiert werden kann. Wenn die TAR-Datei jedoch zur Dekomprimierung auf das lokale Ubantu kopiert wird, werden viele Fehler gemeldet. Die Untersuchung ergab, dass es besser ist, die Berechtigungen am entfernten Ende festzulegen und dann die Root-Berechtigung zum Dekomprimieren des lokalen Ubantu zu verwenden. Der Dekomprimierungsbefehl ist unten dargestellt, und es liegt kein Fehler vor. Wenn Sie direkt in ein lokales Verzeichnis statt auf eine SD-Karte entpacken, kann es beim Kopieren auf die SD-Karte immer noch zu Berechtigungsproblemen kommen. Verwenden Sie daher die virtuelle Maschine, um direkt auf die SD-Karte zuzugreifen und auf die SD-Karte zu kopieren.
Lösung:
Kopieren Sie es zuerst in ein Verzeichnis außerhalb des Projekts, fügen Sie einige Berechtigungen hinzu und dekomprimieren Sie es dann unter Ubantu unbedingt auf die SD-Karte. Nach der Dekomprimierung müssen Sie zum Synchronisieren sync und schließlich umount eingeben.
Führen Sie am besten eine Reihe von Partitionierungen und Initialisierungen Ihrer SD-Karte gemäß dem pünktlichen atomaren Prozess durch. Weitere Informationen finden Sie in Abschnitt 6.2.10 im Navigator ZYNQLinux-Entwicklungshandbuch.
Der Prozess ist wie folgt:
cp rootfs.tar.gz /home/dante
cd /home/dante/
chmod 777 rootfs.tar.gz
sudo tar -xzf rootfs.tar.gz -C /media/dante/rootfs
sync
umount /dev/sdb2
Hier ist /media/dante/rootfs das Verzeichnis, in dem Sie die zweite Partition der SD-Karte mounten. Wenn die SD-Karte gemäß dem ZYNQ-Handbuch erstellt wurde, lautet ihr Name rootfs.
Wenn Sie immer vermuten, dass ein Problem mit dem Root-Dateisystem vorliegt, empfehle ich Ihnen eine einfache Methode: Dekomprimieren Sie es direkt in den NFS-Ordner des lokalen Ubantu und lesen Sie dann das ZYNQ-Handbuch 11.6, um das Root-Dateisystem für die Netzwerkmontage anzugeben Während der Startphase und dann siehe Erste Schritte Wenn Sie aufstehen können, bedeutet dies, dass an der Generierung und Dekomprimierung des Root-Dateisystems nichts auszusetzen ist. Das könnte Problem (2) sein oder etwas, das mit den Einstellungen der SD-Karte nicht stimmt.
(2) Der Kernel konnte nicht gestartet werden und das Root-Dateisystem konnte nicht gefunden werden.
Wenn Sie die obigen Schritte ausführen, verfügt die erste SD-Partition über fünf Dateien: BOOT.BIN, system.dtb, system.bit, boot.src und zImage. Achten Sie zunächst darauf, ob bei der Generierung dieser Dateien ein Problem vorliegt.
Zu prüfende Punkte:
1. Geben Sie in der PetaLiunx-Konfiguration petalinux-config ein, um das Menü „Image-Packaging-Konfiguration“ aufzurufen, suchen Sie den Root-Dateisystemtyp und setzen Sie ihn auf EXT4. Wenn es sich um die Standardeinstellung INITRD handelt, wird das Root-Dateisystem nicht geladen auf der SD-Karte. Es wird bei jedem Start das Standarddateisystem sein (deshalb werden bei jedem Start keine Dateien angezeigt). 2.
Überprüfen Sie den Gerätebaum , die Gerätebaumdatei: system_user.dtsi, in Tatsächlich wird, wenn Sie dem pünktlichen atomaren Prozess folgen, um 6.2 auszuführen, um 7 Uhr die Gerätebaumdatei (4_Source_Code\3_Embedded_Linux\zynq_petalinux\zynq7020\1_customize_linux\device-tree file) direkt ersetzt, aber die Gerätebaumdatei in Dieses Verzeichnis ist eigentlich für den Fall gedacht, dass keine Rootfs-Datei vorhanden ist. Diese Gerätebaumdatei enthält Folgendes nicht :
chosen {
bootargs = "console=ttyPS0,115200 cma=50M earlycon root=/dev/mmcblk0p2 rw rootwait";
stdout-path = "serial0:115200n8";
};
Die Gerätebaumdatei, die diesen Teil tatsächlich enthält, befindet sich im Kernel-Quellcode, der von punctual atom bereitgestellt wird: system_user.dtsi unter atk-zynq-linux-xlnx/arch/arm/boot/dts.
Ohne diesen Teil weiß Petalinux natürlich nicht, wo es beim Erstellen den Kernel laden und Rootfs mounten soll. Ersetzen Sie es durch das Petalinux-Gerätebaumverzeichnis und kompilieren Sie es erneut. Im Prinzip sollten Sie nur zImage und system.dtb (diejenigen, die am meisten geändert werden müssen) erneut kopieren müssen.
Tatsächlich wird dieses Problem nicht auftreten, wenn der Vermieter den Prozess des pünktlichen Atoms vollständig befolgt . Der Vermieter war faul und fragte sich, ob das Quellcodeverzeichnis überhaupt in Petalinux angegeben wurde. Kann er das Verzeichnis seines eigenen Gerätebaums einfach ignorieren? Dieser kleine Unterschied besteht darin, dass ich das RootFS-System erneut überprüfe, ohne es zu mounten. Es wurde festgestellt, dass das pünktliche Atom hat es kommentiert. Wenn Sie dem pünktlichen atomaren Prozess folgen, heißt das: (1) Verwenden Sie BOOT.BIN, boot.scr (mkimage), system.bit, die unter PetaLinux generiert wurden; (2) Verwenden Sie das von PetaLinux generierte Root-Dateisystem. (2) Verwenden Sie den Quellcode, um das große Kernel-zImage und die Gerätebaumdatei system.dtb zu kompilieren und zu generieren. Im Prinzip reicht es also aus, zImage und system.dtb zu ändern, aber da die Verpackung von BOOT.BIN möglicherweise andere Dateien umfasst, ist es besser, sie alle zu ändern. Derzeit hat der Vermieter dieses Problem gelöst und die SD-Karte erfolgreich zum Mounten des ROOTFS-Systems verwendet.