My environment >>
Development board: JetsonXavierNx
Jetson_Linux version: Jetson_Linux_R32.7.2/Jetson_Linux_R35.4.1
Both mmcblk0p1 and nvme0n1p1 have file systems before upgrading
Question >
I started rootfs from nvme (migrated in advance) after using “sudo ./flash.sh jetson-xavier-nx-devkit-emmc nvme0n1p1” command to write. When I removed nvme and powered it on again, I found that the boot stuck in the kernel boot phase, as follows.
If I want to implement a dual system, how do I automatically mount rootfs from emmc and boot when nvme is absent or corrupted? How do I modify the driver?
Are you using the devkit or custom board for Xavier NX?
SD or eMMC module?
I am using the JetsonXavierNx devkit board suite, emmc mode
“Which Jetpack release you are using?”
Mainly used Jetson_Linux_R32.7.2 development package, Jetson_Linux_R35.4.1 also tried to use, the phenomenon is the same.
“It is not a valid command to flash the board. You should use initrd flash instead of flash.sh to flash the external SSD.”
The command for initrd is: sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c ./tools/kernel_flash/flash_l4t_nvme.xml -S 8GiB --showlogs jetson-xavier nvme0n1p1 ?
“It depends on your boot-order, your current boot-order seems correct for this use case.
If NVMe does not exist, it will boot from eMMC.”
I thought so, but emmc was not mounted after nvme was removed.
My current equipment:
xx@ubuntu:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mtdblock0 31:0 0 32M 0 disk
mmcblk0 179:0 0 14.7G 0 disk
├─mmcblk0p1 179:1 0 14G 0 part /
…
nvme0n1 259:0 0 119.2G 0 disk
└─nvme0n1p1 259:1 0 119.2G 0 part /mnt
An error occurred when I implemented the “sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1 -c ./tools/kernel_flash/flash_l4t_nvme.xml --external-only -S 14GiB jetson-xavier-nx-devkit-emmc nvme0n1p1” command on my board to burn external nvme:
As a result, the nvme upgrade failed
Let’s focus and debug on the specific version, maybe verify with R32.7.4 first.
Are you using Xavier NX or Xavier AGX?
They should use different board config.
Please remove the NVMe and flash the BSP package into eMMC.
If you are using the devkit, you could use SDKM to perform this first and check if it could boot from eMMC as expected.
We are currently using Jetson_Linux_R32.7.2 version and have made many adaptations, 32.7.4 Is there anything special about it?
2.I‘m using XavierNX
When I flash to emmc, I can start directly in emmc. But because of emmc’s smaller storage, my goal is to be able to start rootfs in nvme with emmc as a backup
What we do is product, I would like to ask if our sdk can enable rootfs to be launched in nvme and automatically boot rootfs from emmc in cboot order when nvme is corrupted?
I tried a few things,
Manually migrate rootfs to the nvme and run commands to boot from the nvme
Result: The implementation system starts rootfs from nvme, but the kernel fails to start once nvme is uninstalled
Use l4t_initrd_flash.sh tool to burn directly to nvme to check whether my purpose can be achieved, but so far flash has not succeeded
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1 -c ./tools/kernel_flash/flash_l4t_nvme.xml --external-only -S 14GiB jetson-xavier-nx-devkit-emmc nvme0n1p1
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1 -c ./tools/kernel_flash/flash_l4t_nvme.xml --external-only -S 14GiB --network usb0 jetson-xavier-nx-devkit-emmc nvme0n1p1
/home/hxh/workspace/c30n/jetson-xavier-nx-8gemmc
***************************************
* *
* Step 3: Start the flashing process *
* *
***************************************
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Timeout
Cleaning up...