Jetpack 5.2.1 creates 15 partitions on SSD

I have a Jetson Orin NX 16GB with Jetpack 5.2.1.

I notice that only about half of the 128GB SSD is available for linux. There are 15 partitions in total.
I understand that somewhere on the disk is a bootloader, but I wonder if all of these partitions are required?

Only partitions p1 and p11 are formatted for linux

Would it be possible to repartition and claim the unused partitions?

/dev/nvme0n1p1: UUID="2a392cbc-57d9-4305-bcfc-c46e58efbb50" TYPE="ext4" PARTLABEL="APP" PARTUUID="5039be82-c990-4a9d-ac9d-d01ae5baac98"
/dev/nvme0n1p11: UUID="0278-4FD6" TYPE="vfat" PARTLABEL="esp" PARTUUID="51813536-80e8-4216-9696-663ea5f52746"
/dev/nvme0n1p2: PARTLABEL="A_kernel" PARTUUID="36c8ccd4-7534-493c-8855-5425bd30ba43"
/dev/nvme0n1p3: PARTLABEL="A_kernel-dtb" PARTUUID="27c26e93-c8ec-442a-86d1-04541105d84c"
/dev/nvme0n1p4: PARTLABEL="reserved_for_chain_A_user" PARTUUID="74a6c06f-590d-48db-845a-e609648db664"
/dev/nvme0n1p5: PARTLABEL="B_kernel" PARTUUID="1c2f0392-8fad-4995-98c0-ab34e720e504"
/dev/nvme0n1p6: PARTLABEL="B_kernel-dtb" PARTUUID="3d450cd1-305d-459e-b0d6-586b2a1f7a3f"
/dev/nvme0n1p7: PARTLABEL="reserved_for_chain_B_user" PARTUUID="1c69160f-dd9a-4757-b6f2-c228e4dcc040"
/dev/nvme0n1p8: PARTLABEL="recovery" PARTUUID="269f1ff3-f228-4f3a-a880-030de04ef849"
/dev/nvme0n1p9: PARTLABEL="recovery-dtb" PARTUUID="238eb210-adbd-408f-8217-0268e47e575a"
/dev/nvme0n1p10: PARTLABEL="RECROOTFS" PARTUUID="49cc22f1-6c4a-4d56-a1af-111e85918e71"
/dev/nvme0n1p12: PARTLABEL="recovery_alt" PARTUUID="0af1d9f5-f09b-484c-8a83-de2a87dd2027"
/dev/nvme0n1p13: PARTLABEL="recovery-dtb_alt" PARTUUID="51e28048-4322-4f8a-aefe-052c198d270f"
/dev/nvme0n1p14: PARTLABEL="esp_alt" PARTUUID="5528737f-d4de-475e-84ac-a14e8f899171"
/dev/nvme0n1p15: PARTLABEL="UDA" PARTUUID="4eb6b278-9efa-4764-b366-52326bd25575"
Disk /dev/nvme0n1: 119.25 GiB, 128035676160 bytes, 250069680 sectors
Disk model: FORESEE XP1000F128G                     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0A0E9338-C3B9-47AF-BC60-93480EB59319

Device              Start       End   Sectors  Size Type
/dev/nvme0n1p1         40 167772199 167772160   80G Microsoft basic data
/dev/nvme0n1p2  167772200 168034343    262144  128M Microsoft basic data
/dev/nvme0n1p3  168034344 168035879      1536  768K Microsoft basic data
/dev/nvme0n1p4  168035880 168100647     64768 31.6M Microsoft basic data
/dev/nvme0n1p5  168100648 168362791    262144  128M Microsoft basic data
/dev/nvme0n1p6  168362792 168364327      1536  768K Microsoft basic data
/dev/nvme0n1p7  168364328 168429095     64768 31.6M Microsoft basic data
/dev/nvme0n1p8  168429096 168592935    163840   80M Microsoft basic data
/dev/nvme0n1p9  168592936 168593959      1024  512K Microsoft basic data
/dev/nvme0n1p10 168593960 169208359    614400  300M Microsoft basic data
/dev/nvme0n1p11 169208360 169339431    131072   64M EFI System
/dev/nvme0n1p12 169339432 169503271    163840   80M Microsoft basic data
/dev/nvme0n1p13 169503272 169504295      1024  512K Microsoft basic data
/dev/nvme0n1p14 169504296 169635367    131072   64M Microsoft basic data
/dev/nvme0n1p15 169635368 250069646  80434279 38.4G Microsoft basic data

You might find this of use:
https://forums.developer.nvidia.com/t/custom-initrd-for-nx/232508/15

Jetsons do not have a BIOS. Adding a BIOS would increase components, increase power consumption, and increase price. It might be worth it if the Jetson did not need to be efficient on power use and physical size. Otherwise you wouldn’t need all of those partitions (you’d still need what a desktop PC has for a solid state drive).

Thank you very much for the link.

Other ARM devices boot with uboot and a device tree. The device tree informs the kernel about the hardware.

Also, these partitions add up to less than 1 GB, with a root system of 80 GB on a 120 GB drive it appears that space is left unused.

I need to study the flash procedure and see if more space can be claimed. The current configuration is done by Seed Studio.

The boot stages do usually access the device tree on Jetsons. Sometimes the boot stages will also modify parts of the tree before passing it to the Linux kernel. Take a look at “/boot/extlinux/extlinux.conf”. Normally you will see the “APPEND ...stuff...” key/value pair to pass arguments to the Linux kernel. One part usually passed is the “${cbootargs}”. This is derived from the device tree. Generally speaking though, the device tree is available in the environment (this doesn’t mean the kernel has to use it, but it is there). The only parts which the boot stages might modify are those parts which the boot stages are responsible for setting up. I would expect most (or all) of the device tree to be unmodified.

Each of those partitions has a purpose. If you were to delete them after boot is complete, then likely the system wouldn’t care. Until you reboot.

Some content is available both in the rootfs (perhaps in “/boot” somewhere) and also in partitions. Normal priority would be to take content from the filesystem. If something failed, then you might see the system revert to the binary content in partitions. If the security fuses are burned (and thus you are no longer using the NULL key for signing), then only those partitions will be consulted (content in rootfs/ will be ignored if it is used in boot). Maybe the partition you are looking at is not required except under “exceptional conditions”.

If there is an a/b partition scheme for backup, then you can end up with two of some partition.

I wish I could answer what each partition is for, but mostly you’d have to check the XML file layout for clues. You could ask about specific partitions if one has meaning, but you won’t be able to remove all of those partitions from the eMMC models.