Hi all,
Sorry, I’m new to this forum and just saw this.
I’m using thid flavor of Orin NX
I’m wondering as to how your discussion related to that board as well. And/Or could you give me a pointer as to where i should start looking?
My goal would be to have a yocto flavor on that board (optionally with mender support for OTA updates).
Thx
I also saw this, does that related to here as well?
Jetson Orin NX and Jetpack 6 Mender & Intergration issues - Board Integrations / Yocto Project - Mender Hub Jetson Orin NX and Jetpack 6 Mender & Intergration issues - #2 by Austriker - Yocto Project - Mender Hub
Hi @Ben93kie,
FWIW the Orin NX integrations should all be very similar, just the carrier device trees would be a bit different. I also have a Seeed Orin NX board around, IIRC the J401. Unfortunately I’m usually lacking the time for the Orins to push more forwards.
Have you actually tried the board and are facing issues, or are you just evaluating options? If you could provide a bit more detail then I’m sure we can help, also maybe @Austriker or @aduskett (who has lately been touching Orins 
)
Greetz,
Josef
Hi @TheYoctoJester (nice name btw!),
we’re actually deploying these boards on boats currently. But, currently, it’s a bit bloated with Ubuntu (as it’s shipped that way).
Originally, the main motivation was around making it more robust/stable towards random power loss. That brought me down the rabbit hole of OverlayFS, live OS setups, tmpfs-backed logging, and remounting / read-only..
Now I’m realizing that without proper A/B partitioning or OTA infrastructure, it’ll probably hit a wall at some point, especially if we want to update in the field and still be confident things boot back up cleanly after a hard shutdown. Currently, updates only affect the application layer.
What would you recommend as next steps in that case?
Thanks in any way!
Hi @Ben93kie,
Generally speaking, I would try to build the existing demo configuration in meta-mender-community, specifically https://github.com/TheYoctoJester/meta-mender-community/blob/scarthgap/kas/tegra/jetpack6/jetson-orin-16gb-nx-p3786.yml for basing on Jetpack 6. To get started, I would leave out application specific requirements such as Nvidia runtime or similar for now, just make sure the device boots and can do A/B updates. After that, I would evaluate different strategies for updating, like “full OS plus application, every time”, or “OS as base rarely, application often”, and include considerations like data persistency respectively containerization.
If you’d like to bounce ideas off somebody, let me know 
Greetz,
Josef
Hi @TheYoctoJester and all,
Update on my J4012 + JetPack 6 + Mender tests. With some AI help, I’ve built the image but hit a boot issue that I could use some guidance on.
Hardware: Seeed reComputer J4012 (Jetson Orin NX 16GB), NVMe FORESEE XP1000F128G. UEFI firmware v36.4.0.
Build setup: Ubuntu 22.04 host, kas 4.7. Used the existing community configs:
Layers: poky e711b2f, meta-openembedded e8fd97d, meta-tegra 8f9748b (JP 6.2.1 / R36.4.4), meta-tegra-community 241d107, meta-mender scarthgap
Config: machine = p3768-0000-p3767-0000; USE_REDUNDANT_FLASH_LAYOUT_DEFAULT=“1”, MENDER_STORAGE_DEVICE=“/dev/nvme0n1”, MENDER_DATA_PART_NUMBER=“17”
Using the meta-mender-tegra custom NVMe layout with dedicated permanet_user_storage id 17; mender-growfs-data disabled
Build result: kas build completed successfully. All artifacts present including .tegraflash.tar.gz, .mender, dataimg, kernel/DTBs.
Flash: Extracted tegraflash bundle and ran sudo ./doflash.sh. Log ended with “Flashing completed” and coldboot.
Current issue: Device boots into reboot loops. UEFI shows:
“L4TLauncher: Attempting Recovery Boot; Failed to boot image: Invalid Parameter; Failed to boot Recovery Partition”
Boot Manager shows “UEFI FORESEE XP1000F128G …” (NVMe detected)
Setup → L4T Configuration shows OS chain A/B as Unbootable; trying to set to Normal fails with “Submit Fail For Form: Grace Configuration”
UEFI Shell map -r shows only BLKx aliases; no fs0: filesystem mappings. Manually trying fs0: through fs7: all fail, so I cannot reach \EFI\BOOT\BOOTAA64.EFI
Do you know what I’m doing wrong? Any insights appreciated!
Thanks,
Ben
Just one additional note:
I saw that my device is sorted in Balena. Does that help in any way?
Hi @Ben93kie,
I am not sure how pertinent this is to the issue you’re seeing, but I have successfully integrated Mender with an Orin NX 16 GB in a custom carrier board and have found that I do not get a boot with the kas configuration on meta-mender-tegra. I confirmed that the below all works with Jetpack 6 and scarthgap.
The major change I had to make was setting EMMC_SIZE = 0. I also set MENDER_STORAGE_TOTAL_SIZE_MB, MENDER_DATA_PART_SIZE_MB, and TEGRA_EXTERNAL_DEVICE_SECTORS, though I’m not sure to what degree those could be contributing to your boot failure, if you have not set them.
Also, I enable mender-growfs-data and disable mender-uboot.
Thanks @graceagrace
I’ve incorporated some flags you set as well:
Switched to NVMe-centric layout: EMMC_SIZE=“0”, MENDER_STORAGE_DEVICE=“/dev/nvme0n1”, MENDER_DATA_PART_NUMBER=“17”, MENDER_STORAGE_TOTAL_SIZE_MB=“122880”, TEGRA_EXTERNAL_DEVICE_SECTORS=“268435456”.
Boot: MENDER_FEATURES_DISABLE += " mender-uboot" (UEFI JP6), MENDER_FEATURES_ENABLE += " mender-growfs-data".
QoL/NIC: autoload lan743x r8169 r8168; added openssh, debug-tweaks, iproute2, iputils-ping, ethtool, l4t-usb-device-mode.
Using meta-mender-tegra custom NVMe layout with permanet_user_storage id 17 (0x808).
Little progress:
Flash completes; UEFI shows NVMe. UEFI Shell now has fs0: and I can boot via fs0:\EFI\BOOT\BOOTAA64.EFI.
After Linux starts: black screen (core-image-minimal?), but USB keyboard/mouse no power, no Ethernet link LEDs, no USB-gadget on host, no DHCP lease.
Do you thin it is because of this?:
Should I test first with an NX devkit?
Am I missing some configs? Can I share them? Which ones?
Thanks!
Hi @Ben93kie,
Glad to hear you have made some progress. I agree that it is possible your device tree is incorrect. I personally boot with a modified version of p3768-0000-p3767-0000 without issue, but I am not sure of how your board is laid out. Does Seeed provide any .dtb files?
As for a black screen after Linux boots, this may just be a consequence of booting core-image-minimal, like you said. This image includes only what is absolutely necessary to boot, so I would not be entirely surprised by the lack of features you are seeing. Keep in mind that usbgadget and usbhost are MACHINE_FEATURES… are these enabled in your machine configuration?
To diagnose whether the behavior you’re seeing is due to core-image-minimal being, well, minimal, or if Linux is failing to fully boot, a serial log would be most helpful. Does your carrier board have a UART port you can connect to a host (over PuTTY, for instance) and get the serial logs from the Jetson while it is trying to boot?
Hi @graceagrace @TheYoctoJester
short update (with some AI help, hope it’s not too verbose):
Build System Setup:
Successfully set up KAS-based Yocto build using meta-mender-community/kas/tegra/jetpack6/jetson-orin-16gb-nx-p3786.yml
Integrated recommendations: EMMC_SIZE = “0”, MENDER_STORAGE_TOTAL_SIZE_MB = “122880”, disabled mender-uboot, enabled mender-growfs-data
Built multiple image variants: core-image-minimal, core-image-base, core-image-sato (GUI)
Hardware Integration & Debugging Setup:
Successfully extracted and integrated the J4012 industrial DTB (tegra234-j4012-industrial.dtb) from Seeed’s JetPack 6.1 package (Getting Started with reComputer Industrial | Seeed Studio Wiki)
I had to learn: Serial console access is through the USB-C debug port, not a separate UART connector (then this worked well: screen /dev/ttyUSB0 115200). Importantly, there is another USB-C port for force recovery for flashing.
Confirmed dual Ethernet ports work (including PoE) as it showed up on router (see later), USB ports, keyboard/mouse were powered
Flashing & Boot Challenges:
Multiple successful flashes using both Mender tegraflash bundles and Seeed’s l4t_initrd_flash.sh (!) as outlined on link above
UEFI firmware properly updated to v36.4.0
Successfully created bootable USB installer with Mender A/B partition layout (which I had pivoted to because normal flashing would not boot properly, see below; also this does not boot properly)
Here’s where it gets interesting - the system cannot boot normally from either USB or NVMe:
USB Boot: Even though we created a proper(?) bootable USB stick with EFI partition and GRUB config, selecting the USB option in the UEFI Boot Manager just returns to the boot menu (fails silently).
NVMe Boot: Similarly, selecting the NVMe option in UEFI Boot Manager returns to the menu.
What Actually Works:
We can only get into a recovery shell environment (it says bash-5.1#) by letting the boot process timeout/fail
From this recovery shell, we can manually:
Mount the USB stick (/dev/sda2)
Mount the NVMe partitions (/dev/nvme0n1p2, etc.)
chroot into the installed Yocto system
Verify hardware functionality
Networking Partially Working:
Ethernet interfaces come up and get DHCP addresses
Device appears in router’s DHCP client list without hostname
Can ping external addresses from the Jetson
However, SSH connections from external hosts fail - they either hang indefinitely or get “PTY allocation request failed”. Ping also fails.
SSH works locally (ssh localhost from within chroot), but external access doesn’t work despite the service running and listening on port 22. This was the case for the bigger images that should have SSH support. But maybe because it’s in a weirdly booted state..
UEFI Shell Access:
From UEFI Shell, we can access NVMe filesystems directly (FS2:, FS3:, FS4:)
We successfully booted the kernel directly using: FS2:\boot\Image root=/dev/nvme0n1p2 …
Kernel loads and initializes, USB devices detected, but gets stuck at Waiting for root device /dev/nvme0n1p2…
The NVMe device is accessible from UEFI but not detected by the Linux kernel during boot. Only USB storage (/dev/sda) appears in the kernel, never nvme0n1.
This suggests either:
Missing NVMe kernel module/driver
Device tree issue with NVMe controller configuration
Boot parameter or initrd problem
Has anyone seen this pattern where UEFI can access NVMe but Linux kernel cannot detect it?
Are there specific NVMe driver modules that need to be built into the kernel (not as loadable modules) for Jetson Orin NX?
Any ideas on the SSH/networking issue? The chroot environment might be causing network namespace isolation.
Should I be using a different boot approach entirely?
The manual recovery shell → chroot method works for hardware verification, but I’d need proper native boot for production deployment.
I reckon it comes down to weirdly flashing with seeedstudio’s initrd script. But, all other methods booting have failed so far. USB as well.
Thanks!
I’ve added the config, the screen logs (although big), and the DTB file here if that’s helpful:
I’m pivoting to Balena for now as I’m hitting a dead end. Tried various things (booting from USB, flashing through seeedstudio’s script, Mender script), but none let me auto-boot.
Is there anything we can “extract” from the Balena build to make a Mender build as theirs is Yocto-based as well? Or get inspiration from? How would be the best approach for that? The balena build booted properly and seems to work fine so far.
Thx!
Hi @Ben93kie,
thanks for still following up with us though its a seemingly painful process. And I totally understand the possible pivot.
It took me a bit to follow up because I really wanted to give it a good inspection instead of just saying “sorry”. So if my understanding is correct, then the magic lies in this file: balena-jetson-orin/layers/meta-balena-jetson/recipes-kernel/linux/linux-jammy-nvidia-tegra/tegra234-j401-p3768-0000+p3767-0000-recomputer.dtb at master · balena-os/balena-jetson-orin · GitHub as appended here: balena-jetson-orin/layers/meta-balena-jetson/recipes-kernel/linux/jetson-dtbs.bb at 91389bfdd0221457a9250532adafd4ee733674a2 · balena-os/balena-jetson-orin · GitHub. The install logic is in balena-jetson-orin/layers/meta-balena-jetson/recipes-kernel/linux/jetson-dtbs.bb at 91389bfdd0221457a9250532adafd4ee733674a2 · balena-os/balena-jetson-orin · GitHub, and that also gives away that balena extracted from GitHub - Seeed-Studio/Linux_for_Tegra: Seeed Jetson reComputer && reServer default Image source code.🎁 🎁 🎁 - commit 5b18d7990ca342bbeb70ce5715ea0473d118278f, branch r36.4.3
So in a nutshell, my final suggestion would be to give that a spin. How to inject a DTB properly in meta-tegra, maybe @graceagrace or @dwalkes can give you some assistance.
Really hope we can figure this out, and if not then thanks a lot for all your effort. And of course, you know where to find me.
Greetz,
Josef
It looks like balena has some machines at balena-jetson-orin/layers/meta-balena-jetson/conf/machine at master · balena-os/balena-jetson-orin · GitHub which aren’t in upstream meta-tegra.
Regarding how to use a custom DTB there’s a page at Using device tree overlays · OE4T/meta-tegra Wiki · GitHub and it depends on the target branch and configuration.
It looks like they are generating their own extlinux.conf at balena-jetson-orin/layers/meta-balena-jetson/recipes-kernel/linux/linux-jammy-nvidia-tegra_5.15.bbappend at 91389bfdd0221457a9250532adafd4ee733674a2 · balena-os/balena-jetson-orin · GitHub without using UBOOT_EXTLINUX, not sure why. They are then adding the jetson-dtbs package to the image at balena-jetson-orin/layers/meta-balena-jetson/recipes-kernel/linux/jetson-dtbs.bb at 91389bfdd0221457a9250532adafd4ee733674a2 · balena-os/balena-jetson-orin · GitHub to generate their dtb files and include in the image. I was expecting to see TEGRA_PLUGIN_MANAGER_OVERLAYS set somewhere to include this file so it ends up in the spi flash but I don’t see this so I’m not sure where the link between the custom dtb for the target and the initial tegraflash is happening, but extracting the package and searching for references to the dtb filename would probably help identify where this is happening.