Hi,
Just wondering if it is possible to omit EMMC usage all together currently ? Noticed that when using NVME as storage, EMMC still gets populated even if NVME is selected to be used ? Even if orin-nx emulation configuration is used EMMC still gets populated. As far as I have understood Orin NX does not have EMMC included.
Is boot using QSPI and NVME only currently possible with Orin AGX ?
Yes, I think it is possible. I am not sure about your definition of “populated”.
If emmc is populated but not in use, then I think it is normal. Just as you plug in a sdcard, you won’t use it to boot up, but it is still showing up.
Hi,
By populating I meant that EMMC has partitions made according to to used
partition definition. However, I am bit baffled how achieve QSPI+NVME boot with
current Jetpack 5.0.2.
I first used nvsdkmanager_flash.sh to install content to dev board with NVME disk
(used command line: ./nvsdkmanager_flash.sh --storage nvme0n1p1)
This works fine and system gets installed to dev board with NVME disk
attached. System boots up and works fine.
(Well, not setup for somereason was not available via /dev/ttyACM, even
if ttyACM0 stated: “[ 18.810610] Please complete system configuration setup
on the serial port provided by Jetson’s USB device mode connection.
e.g. /dev/ttyACMx where x can 0, 1, 2 etc.”, via monitor setup was ok)
After installation I assume that QSPI is flashed ok (as system boots).
Via blkid command I can see that EMMC has partitions as follows:
/dev/mmcblk0p1: UUID="9ec30524-5913-407d-95fd-48b39af653ed" TYPE="ext4" PARTLABEL="APP" PARTUUID="57097ed6-c914-47c4-bcd0-4f2e256c2270"
/dev/mmcblk0p2: PARTLABEL="A_kernel" PARTUUID="77b49191-0803-41ee-97c3-8b7a4ae41575"
/dev/mmcblk0p3: PARTLABEL="A_kernel-dtb" PARTUUID="145001f5-e40d-41c7-abf6-b427421f4a21"
/dev/mmcblk0p4: PARTLABEL="A_reserved_on_user" PARTUUID="23258881-4188-403e-bcfd-a055cb375c18"
/dev/mmcblk0p5: PARTLABEL="B_kernel" PARTUUID="1918ed4f-d9fb-43f5-b951-e359f05b6203"
/dev/mmcblk0p6: PARTLABEL="B_kernel-dtb" PARTUUID="3acb8a0c-fa03-4b71-8711-a66be420596c"
/dev/mmcblk0p7: PARTLABEL="B_reserved_on_user" PARTUUID="6f71abe7-103b-49fc-9d1a-7a265d93645b"
/dev/mmcblk0p8: PARTLABEL="recovery" PARTUUID="68da8d24-8f20-4560-a51f-633f1d66d55d"
/dev/mmcblk0p9: PARTLABEL="recovery-dtb" PARTUUID="524bd086-a25d-4a9b-8b69-7a361762004a"
/dev/mmcblk0p10: UUID="16C9-5E6A" TYPE="vfat" PARTLABEL="esp" PARTUUID="1c89aa60-2ca2-4106-a246-163f55acd930"
/dev/mmcblk0p11: PARTLABEL="reserved" PARTUUID="72ce10af-3d4d-46cb-97cb-23523099f315"
And NVME has following partitions:
/dev/nvme0n1p1: UUID="00232e0e-131b-4e1d-b01a-b28a34c60ed6" TYPE="ext4" PARTLABEL="APP" PARTUUID="05e9febb-2d3d-4149-ba7f-cd055ee79c0f"
/dev/nvme0n1p2: PARTLABEL="kernel" PARTUUID="6a189e76-640d-4c18-809b-7a6b35dbd102"
/dev/nvme0n1p3: PARTLABEL="kernel_b" PARTUUID="3802d2a6-8290-47e2-af57-3370decf5114"
/dev/nvme0n1p4: PARTLABEL="kernel-dtb" PARTUUID="09b2e8a3-9fbb-4fe6-b5d7-f5352ecc635f"
/dev/nvme0n1p5: PARTLABEL="kernel-dtb_b" PARTUUID="31a50438-e835-4894-951c-ff11d2289323"
/dev/nvme0n1p6: PARTLABEL="recovery" PARTUUID="5cdf03de-30c5-4708-8a2f-a50a40404d00"
/dev/nvme0n1p7: PARTLABEL="recovery-dtb" PARTUUID="2eb62d5a-b126-4933-96bd-2e4f05fec817"
/dev/nvme0n1p8: PARTLABEL="RECROOTFS" PARTUUID="0766855d-d2a0-4089-b846-975e57597178"
/dev/nvme0n1p9: UUID="1E03-3828" TYPE="vfat" PARTLABEL="esp" PARTUUID="042b5c22-7968-4d60-aae1-8c4298fa436e"
/dev/nvme0n1p10: PARTLABEL="UDA" PARTUUID="3978dd75-7c2a-4e07-8dd5-15711cb07b71"
Now that NVME should be correctly initialized, I reflashed dev board again
with flash.sh (./flash.sh jetson-agx-orin-devkit-as-nx-8gb nvme0n1p1). Since I
am interested in Orin NX, I assumed that EMMC would still contain partitions
and NVME ones would be used instead.
Dev board gets flashed ok, boots up and partitions are as follows:
EMMC:
/dev/mmcblk0p1: UUID="c77feae3-9132-40c4-b5d3-7f6729937d6b" TYPE="ext4" PARTLABEL="APP" PARTUUID="09190b3e-48e4-41bb-b284-dd7e42c2e902"
/dev/mmcblk0p2: PARTLABEL="A_kernel" PARTUUID="6db9d501-7c6d-489a-9464-6a751d02184a"
/dev/mmcblk0p3: PARTLABEL="A_kernel-dtb" PARTUUID="4be5515e-66c5-4e11-bf7a-345bfb547947"
/dev/mmcblk0p4: PARTLABEL="A_reserved_on_user" PARTUUID="453b38d5-3f44-48e5-863e-e92fa4080655"
/dev/mmcblk0p5: PARTLABEL="B_kernel" PARTUUID="79d0b704-97cd-433f-97a0-e303f175276b"
/dev/mmcblk0p6: PARTLABEL="B_kernel-dtb" PARTUUID="6a53ab0c-292b-4a41-ad9f-5d4afb81c76e"
/dev/mmcblk0p7: PARTLABEL="B_reserved_on_user" PARTUUID="7185f45a-dc3d-493f-9722-fd61c58ae53b"
/dev/mmcblk0p8: PARTLABEL="recovery" PARTUUID="1cef596f-2cde-46c9-945c-147a6937a624"
/dev/mmcblk0p9: PARTLABEL="recovery-dtb" PARTUUID="2d2d7a9c-e797-45d8-9e78-20719d4fe71a"
/dev/mmcblk0p10: UUID="297B-860E" TYPE="vfat" PARTLABEL="esp" PARTUUID="1e736404-dcb3-468a-ba51-ff6463b5586a"
/dev/mmcblk0p11: PARTLABEL="reserved" PARTUUID="649c4378-cbfa-4033-9e0a-d2314d7cd729"
NVME:
/dev/nvme0n1p1: UUID="00232e0e-131b-4e1d-b01a-b28a34c60ed6" TYPE="ext4" PARTLABEL="APP" PARTUUID="05e9febb-2d3d-4149-ba7f-cd055ee79c0f"
/dev/nvme0n1p2: PARTLABEL="kernel" PARTUUID="6a189e76-640d-4c18-809b-7a6b35dbd102"
/dev/nvme0n1p3: PARTLABEL="kernel_b" PARTUUID="3802d2a6-8290-47e2-af57-3370decf5114"
/dev/nvme0n1p4: PARTLABEL="kernel-dtb" PARTUUID="09b2e8a3-9fbb-4fe6-b5d7-f5352ecc635f"
/dev/nvme0n1p5: PARTLABEL="kernel-dtb_b" PARTUUID="31a50438-e835-4894-951c-ff11d2289323"
/dev/nvme0n1p6: PARTLABEL="recovery" PARTUUID="5cdf03de-30c5-4708-8a2f-a50a40404d00"
/dev/nvme0n1p7: PARTLABEL="recovery-dtb" PARTUUID="2eb62d5a-b126-4933-96bd-2e4f05fec817"
/dev/nvme0n1p8: PARTLABEL="RECROOTFS" PARTUUID="0766855d-d2a0-4089-b846-975e57597178"
/dev/nvme0n1p9: UUID="1E03-3828" TYPE="vfat" PARTLABEL="esp" PARTUUID="042b5c22-7968-4d60-aae1-8c4298fa436e"
/dev/nvme0n1p10: PARTLABEL="UDA" PARTUUID="3978dd75-7c2a-4e07-8dd5-15711cb07b71"
System boots up as expected.
After this I remove NVME disk from system, assumption would be that if NVME
is used, kernel would not be found, but instead system boots and dies only
when root device (/dev/nvme0n1p1) is not found. Thus I suspect that kernel
gets loaded from EMMC and not from NVME.
Attached NVME disk again and system boots normally. Did wipefs -a -f
/dev/mmcblk0 and rebooted.
System enters bootloop and stays there with following logs:
L4TLauncher: Attempting GRUB Boot
L4TLauncher: Attempting Direct Boot
ASSERT [DtPlatformDxe] /dvs/git/dirty/git-master_linux/out/nvidia/bootloader/uefi/Jetson_RELEASE/edk2-nvidia/Silicon/NVIDIA/Library/MceAriLib/MceAriLib.c(385): Cluster < (LibPcdGet32(59U))
Resetting the system in 5 seconds.
L4TLauncher: Attempting Recovery Boot
ASSERT [DtPlatformDxe] /dvs/git/dirty/git-master_linux/out/nvidia/bootloader/uefi/Jetson_RELEASE/edk2-nvidia/Silicon/NVIDIA/Library/MceAriLib/MceAriLib.c(385): Cluster < (LibPcdGet32(59U))
Resetting the system in 5 seconds.
So question remains: If Orin can be successfully booted from QSPI+NVME combination, howto do it with SDK manager or related scripts that are supplied with Jetpack 5.0.2 ?
Apparently using emulation configuration does not do this as when EMMC gets wiped, boot process is broken.
Hi,
I think there is one point to clarify.
“./flash.sh jetson-agx-orin-devkit-as-nx-8gb nvme0n1p1” won’t really flash thing to nvme drive. It is just configuring the extlinux.conf on your emmc to mount nvme as rootfs.
The one who decides which storage to load kernel is the UEFI. You should check UEFI log and see which disk is the kernel got loaded.
Yep, it does not install anything to NVME, but NVME has the right content already. Based on what you said, UEFI configuration is likely to be wrong. I’ll check that.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.