Orin NX Partition Explaination

[retro]

Hi, I am trying to understand what all of these partitions do.

/dev/nvme0n1p1: UUID=“85a35ccd-a620-43b8-9643-9499f1263661” TYPE=“ext4” PARTLABEL=“APP” PARTUUID=“195d8858-d19a-4064-ab8b-910c66f60c1e”
/dev/nvme0n1p2: PARTLABEL=“kernel” PARTUUID=“651f5590-b948-4005-a888-590a0368d22f”
/dev/nvme0n1p3: PARTLABEL=“kernel-dtb” PARTUUID=“3dee94b4-1a2a-4225-9b58-bb306d681947”
/dev/nvme0n1p4: PARTLABEL=“reserved_for_chain_A_user” PARTUUID=“2b314d3a-b5c0-4cec-9047-be0fd5749613”
/dev/nvme0n1p5: PARTLABEL=“kernel_b” PARTUUID=“5db746a9-9b8d-47c0-8301-754ae1339202”
/dev/nvme0n1p6: PARTLABEL=“kernel-dtb_b” PARTUUID=“3eb70ecb-88d9-4e6b-b763-ad7f8808fc08”
/dev/nvme0n1p7: PARTLABEL=“reserved_for_chain_B_user” PARTUUID=“68413710-f333-4448-827d-fe518668d60f”
/dev/nvme0n1p8: PARTLABEL=“recovery” PARTUUID=“6a3e7540-b766-4761-9086-9e7473786d01”
/dev/nvme0n1p9: PARTLABEL=“recovery-dtb” PARTUUID=“2d85a5a3-0346-4c5b-ba34-6a2833fba412”
/dev/nvme0n1p10: PARTLABEL=“RECROOTFS” PARTUUID=“4c60bc8e-bda2-42c3-b663-774242514f0a”
/dev/nvme0n1p11: UUID=“06FD-3C0B” TYPE=“vfat” PARTLABEL=“esp” PARTUUID=“14e8d7cc-bb51-4332-afb9-685106251a40”
/dev/nvme0n1p12: PARTLABEL=“recovery_alt” PARTUUID=“301f7112-017f-4127-9b99-b053bbb7d60d”
/dev/nvme0n1p13: PARTLABEL=“recovery-dtb_alt” PARTUUID=“58e79d0d-9b5e-4e25-9ceb-6810d8ab9e17”
/dev/nvme0n1p14: PARTLABEL=“esp_alt” PARTUUID=“3c912437-4f53-4016-a0b4-9a20485bd224”
/dev/loop0: SEC_TYPE=“msdos” LABEL_FATBOOT=“L4T-README” LABEL=“L4T-README” UUID=“1234-ABCD” TYPE=“vfat”
/dev/zram0: UUID=“a6dcfc56-1834-45f7-b4ac-9719eb62a5f2” TYPE=“swap”
/dev/zram1: UUID=“abfd3f90-9341-4b65-9d92-5ab646274fd2” TYPE=“swap”
/dev/zram2: UUID=“aa3da3ac-c92b-4628-a61f-bf64ec06704f” TYPE=“swap”
/dev/zram3: UUID=“b67c8fab-3ca8-4245-9ecf-8c42dc47ef90” TYPE=“swap”

[linuxdev]

I cannot tell you all of that, but I can get this started…

Jetsons do not have a BIOS. All of the equivalent of the BIOS, along with bootloader and firmware and boot code goes into partitions of the eMMC models (or QSPI of SD card models). So all of the nvme0n1 partitions are this.

In a case where A/B partition redundancy is set, there are an A and B copy.

The zram partitions are not real partitions, they exist in compressed RAM. They are used in place of swap on actual disk. Speed is a very big advantage there, but also it has no wear on solid state memory. The disadvantages include of course using up RAM, plus there is no ability (normally, not always) to hibernate or suspend unless steps have been taken to either preserve the zram partitions or not use them during suspend or hibernation.

The loop0 is more interesting. Loopback is used to take a file and make it “pretend” to be a partition or entire disk. In this case the file is located at “/opt/nvidia/l4t-usb-device-mode”, and is “filesystem.img”. The device mode USB is set up by default such that if a type-B connector is used (type-B means it attached to a device; type-A means it attached to a host; there is always a type-A to type-B between a host and device; OTG connectors have an ID pin to know which, type-C connectors are just type-A and type-B simultaneously due to extra wiring), then it is in device mode, and sets up emulating some USB devices.

The USB devices emulated when in device mode are (A) a network router device, and (B) the L4T-README file on what appears to be an external storage device (read-only mode). Your host PC, when you plug that cable in, and if security allows it, will use DHCP and take on address 192.168.55.100, while the Jetson takes on address 192.168.55.1. The USB storage device would be mounted on the host, and the L4T-README file would be visible on the host. The USB trickery (“these ARE the droids you are after” :P) uses the Linux kernel’s “Gadget” framework for emulating some standard USB devices after filling in some details (such as a partition to become mass storage, which is a loopback partition on a file).