# Orin NX integration / Seeed reComputer **URL:** \ **Category:** General Discussions\ **Tags:** yocto, nvidia, orin\ **Created:** [July 19, 2025, 11:57am UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917 "2025-07-19T11:57:01Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Ben93kie](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ben93kie/32/2536_2.png) [@Ben93kie](https://hub.mender.io/u/Ben93kie)\ **Post date:** [July 19, 2025, 11:57am UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/1 "2025-07-19T11:57:01Z")
Hi all, Sorry, I’m new to this forum and just saw this. I’m using thid flavor of Orin NX > **[reComputer Industrial J4012- Fanless Edge AI Device with Jetson Orin™ NX 16GB](https://www.seeedstudio.com/reComputer-Industrial-J4012-p-5684.html?srsltid=AfmBOoooH97J0S-CwHWYzKC2_LZcE49Enio-A-_WQ43B5zlXG-36zOPw)** > > reComputer Industrial J4012 features NVIDIA Jetson Orin™ NX 16GB module for 100 TOPS AI performance and supports hybrid connectivities including 2 RJ-45 Ethernet ports, 1 RS232/422/485 & CAN port, etc. Fanless with versatile mounting options... 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 ---
**Author:** ![Ben93kie](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ben93kie/32/2536_2.png) [@Ben93kie](https://hub.mender.io/u/Ben93kie)\ **Post date:** [July 19, 2025, 12:02pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/2 "2025-07-19T12:02:34Z")
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](https://share.google/I19jewhyXMLdbcqzL) ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [July 20, 2025, 8:15am UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/3 "2025-07-20T08:15:07Z")
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 ---
**Author:** ![Ben93kie](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ben93kie/32/2536_2.png) [@Ben93kie](https://hub.mender.io/u/Ben93kie)\ **Post date:** [July 23, 2025, 11:08pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/4 "2025-07-23T23:08:34Z")
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! ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [July 25, 2025, 9:03am UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/5 "2025-07-25T09:03:28Z")
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](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 ---
**Author:** ![Ben93kie](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ben93kie/32/2536_2.png) [@Ben93kie](https://hub.mender.io/u/Ben93kie)\ **Post date:** [September 12, 2025, 6:27pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/6 "2025-09-12T18:27:53Z")
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 ---
**Author:** ![Ben93kie](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ben93kie/32/2536_2.png) [@Ben93kie](https://hub.mender.io/u/Ben93kie)\ **Post date:** [September 12, 2025, 7:17pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/7 "2025-09-12T19:17:52Z")
Just one additional note: I saw that my device is sorted in Balena. Does that help in any way? > **[BalenaCloud with SeeedStudio reComputerJ4012](https://forums.balena.io/t/balenacloud-with-seeedstudio-recomputerj4012/372701)** > > I’m a new user to BalenaCloud and am having trouble right from the start. I have managed to get a simple and generic Intel x64 MiniITX installed with BalenaOS, but the actual target I need to use is a SeeedStudio reComputerJ4012. I download the OS... > **[Seeed Studio reComputer Industrial J4012](https://forums.balena.io/t/seeed-studio-recomputer-industrial-j4012/372303)** > > Hi, I’m trying to get balenaOS running on the reComputer Industrial J4012 and have managed to successfully flash it using the “Seeed reComputer J4012 16GB” image. I’m able to connect to the device over serial, but it can’t access the internet via... ---
**Author:** ![graceagrace](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/graceagrace/32/2654_2.png) [@graceagrace](https://hub.mender.io/u/graceagrace)\ **Post date:** [September 12, 2025, 9:52pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/8 "2025-09-12T21:52:21Z")
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`. ---
**Author:** ![Ben93kie](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ben93kie/32/2536_2.png) [@Ben93kie](https://hub.mender.io/u/Ben93kie)\ **Post date:** [September 16, 2025, 12:36am UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/9 "2025-09-16T00:36:59Z")
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?: - Still using the generic devkit DTB; J4012 carrier likely needs a Seeed DTB (e.g., tegra234-p3767-industrial-j401.dtb) or specific DTBOs for hub/NIC power. I couldn’t find a JP6 J401 DTB in the mfi package (only devkit DTBs). Should I test first with an NX devkit? Am I missing some configs? Can I share them? Which ones? Thanks! ---
**Author:** ![graceagrace](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/graceagrace/32/2654_2.png) [@graceagrace](https://hub.mender.io/u/graceagrace)\ **Post date:** [September 16, 2025, 3:19pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/10 "2025-09-16T15:19:51Z")
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? ---
**Author:** ![Ben93kie](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ben93kie/32/2536_2.png) [@Ben93kie](https://hub.mender.io/u/Ben93kie)\ **Post date:** [September 21, 2025, 9:29pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/11 "2025-09-21T21:29:03Z")
Hi @graceagrace @TheYoctoJester short update (with some AI help, hope it’s not too verbose): ## **What Works** **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](https://wiki.seeedstudio.com/reComputer_Industrial_Getting_Started/)) - **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) ## **However** 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 Core Issue** 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: 1. Missing NVMe kernel module/driver 2. Device tree issue with NVMe controller configuration 3. Boot parameter or initrd problem ## **Questions for the Community** 1. Has anyone seen this pattern where UEFI can access NVMe but Linux kernel cannot detect it? 2. Are there specific NVMe driver modules that need to be built into the kernel (not as loadable modules) for Jetson Orin NX? 3. Any ideas on the SSH/networking issue? The chroot environment might be causing network namespace isolation. 4. 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! ---
**Author:** ![Ben93kie](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ben93kie/32/2536_2.png) [@Ben93kie](https://hub.mender.io/u/Ben93kie)\ **Post date:** [September 21, 2025, 9:36pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/12 "2025-09-21T21:36:08Z")
I’ve added the config, the screen logs (although big), and the DTB file here if that’s helpful: > **[JetsonMenderFlashing - Google Drive](https://drive.google.com/drive/folders/1cf_c1OTaiW_UwenCEr-U7CLFQYTqQM-v?usp=sharing)** ---
**Author:** ![Ben93kie](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ben93kie/32/2536_2.png) [@Ben93kie](https://hub.mender.io/u/Ben93kie)\ **Post date:** [September 25, 2025, 4:25pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/13 "2025-09-25T16:25:04Z")
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! ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [October 1, 2025, 2:02pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/14 "2025-10-01T14:02:50Z")
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](https://github.com/balena-os/balena-jetson-orin/blob/master/layers/meta-balena-jetson/recipes-kernel/linux/linux-jammy-nvidia-tegra/tegra234-j401-p3768-0000%2Bp3767-0000-recomputer.dtb) as appended here: [balena-jetson-orin/layers/meta-balena-jetson/recipes-kernel/linux/jetson-dtbs.bb at 91389bfdd0221457a9250532adafd4ee733674a2 · balena-os/balena-jetson-orin · GitHub](https://github.com/balena-os/balena-jetson-orin/blob/91389bfdd0221457a9250532adafd4ee733674a2/layers/meta-balena-jetson/recipes-kernel/linux/jetson-dtbs.bb#L20). 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](https://github.com/balena-os/balena-jetson-orin/blob/91389bfdd0221457a9250532adafd4ee733674a2/layers/meta-balena-jetson/recipes-kernel/linux/jetson-dtbs.bb#L71), and that also gives away that balena extracted from [GitHub - Seeed-Studio/Linux\_for\_Tegra: Seeed Jetson reComputer && reServer default Image source code.🎁 🎁 🎁](https://github.com/Seeed-Studio/Linux_for_Tegra.git) - 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 ---
**Author:** ![dwalkes](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dwalkes/32/41_2.png) [@dwalkes](https://hub.mender.io/u/dwalkes)\ **Post date:** [October 1, 2025, 3:26pm UTC](https://hub.mender.io/t/orin-nx-integration-seeed-recomputer/7917/15 "2025-10-01T15:26:23Z")
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](https://github.com/balena-os/balena-jetson-orin/tree/master/layers/meta-balena-jetson/conf/machine) 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](https://github.com/OE4T/meta-tegra/wiki/Using-device-tree-overlays) 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](https://github.com/balena-os/balena-jetson-orin/blob/91389bfdd0221457a9250532adafd4ee733674a2/layers/meta-balena-jetson/recipes-kernel/linux/linux-jammy-nvidia-tegra_5.15.bbappend#L170-L182) 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](https://github.com/balena-os/balena-jetson-orin/blob/91389bfdd0221457a9250532adafd4ee733674a2/layers/meta-balena-jetson/recipes-kernel/linux/jetson-dtbs.bb) 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.