Error printing:
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) ]---
Error analysis:
Don’t know where to boot the rootfs, but the various areas of the SD card were scanned.
Some problems found in the process of solving the problem:
question:
(1) There is an error in decompressing the compressed package of the rootfs file generated by PetaLinux
Error message:
Using Bandzip to decompress under Windows will report an error, either it is linked in administrator mode, or there are duplicate files, which cannot be solved here, it is recommended to do it directly under Ubantu.
If you are compiling on a remote Ubantu system, first add permissions, copy to the Windows shared folder, then copy from the remote end to the local Windows, and then copy from the local Windows to the local Ubantu.
There are a lot of Permission denied and invalid operation errors when decompressing under Ubantu, mainly because the decompression of the root file system requires certain permissions. After researching here for a long time, I found that the remote Ubantu can be decompressed normally, but if the tar file is copied to the local Ubantu for decompression, a lot of errors will be reported. The research found that it is better to set the permissions at the remote end, and then use the root authority to decompress the local Ubantu. The decompression command is shown below, and there is no mistake. If you directly unzip to a local directory instead of an SD card, you may still have permission problems when copying to the SD card, so use the virtual machine to access the SD card directly and copy to the SD card.
Solution:
First copy it to a directory outside the project, add some permissions to it, and then be sure to decompress it to the SD card under Ubantu. After decompression, you need to enter sync to synchronize, and finally umount.
It is best to perform a series of partitioning and initialization of your SD card according to the punctual atomic process. For details, refer to 6.2.10 in the Navigator ZYNQLinux Development Manual.
The process is as follows:
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
Here /media/dante/rootfs is the directory where you mount the second partition of the SD card. If the SD card is made according to the ZYNQ manual, its name will be rootfs.
If you always suspect that there is a problem with the root file system, then I recommend you a simple method, directly decompress it to the NFS folder of the local Ubantu, and then refer to ZYNQ manual 11.6 to specify the network mount root file system during the boot phase, and then see Getting Started If you can get up, it means that there is nothing wrong with the generation and decompression of the root file system. That could be problem (2), or something wrong with the settings of the SD card.
(2) The kernel failed to start, and the root file system could not be found.
If you follow the above steps, the first SD partition has five files: BOOT.BIN, system.dtb, system.bit, boot.src, and zImage, first pay attention to whether there is any problem with the generation of these files.
Points to check:
1. In the PetaLiunx configuration, enter petalinux-config to enter the Image Packaging Configuration menu, find the Root filesystem type, and set it to EXT4. If it is the default INITRD, the root file system will not be loaded on the SD card, and it will be The default file system (this is why your files are lost every time you boot)
2. Check the device tree, the device tree file: system_user.dtsi, in fact, if you follow the process of punctual atom to achieve 6.2.7, it will directly replace the device tree file (4_Source_Code\3_Embedded_Linux\zynq_petalinux\ zynq7020\1_customize_linux\device-tree file), but the device tree file in that directory is actually for the case of no Rootfs file. This device tree file does not contain the following:
chosen {<!-- -->
bootargs = "console=ttyPS0,115200 cma=50M earlycon root=/dev/mmcblk0p2 rw rootwait";
stdout-path = "serial0:115200n8";
};
The device tree file that actually contains this part is in the kernel source code provided by punctual atom: system_user.dtsi under atk-zynq-linux-xlnx/arch/arm/boot/dts.
Without this part, Petalinux naturally does not know where to load the kernel and mount Rootfs when building. Replace it with the petalinux device tree directory and recompile. In principle, you should only need to re-copy zImage and system.dtb (the ones that need to be changed most).
In fact, if the landlord completely follows the process of punctual atom, this problem will not occur.
The landlord was lazy, wondering if the source code directory has been specified in Petalinux anyway, can he just ignore the directory of its own device tree, and this small difference is when I re-check the rootfs system without mounting it It was discovered that the punctual atom annotated it.
If you follow the process of the punctual atom, it is:
(1) Use BOOT.BIN, boot.scr (mkimage), system.bit generated under PetaLinux;
(2) Use the root file system generated by PetaLinux.
(2) Use the source code to compile and generate the large kernel zImage and the device tree file system.dtb.
So in principle, it is enough to change zImage and system.dtb, but since the packaging of BOOT.BIN may involve other files, it is better to change them all.
At present, the landlord has solved this problem and successfully used the SD card to mount the ROOTFS system.