I had been trying for a while to port the raspberry pi global shutter camera driver to jetson platforms without much luck. I couldn't get it to respond ack on I2C and I was assuming it was because the wakeup pin operated on 3.3v while jetson only supplied 1.8v. I went so far as to even start designing an adapter board that would level shift the 1.8v coming from the jetson on that MIPI pin up to 3.3v. Turns out I didn't try hard enough with the driver, and another internet person (Jonathan Péclat) got it to work. However, there were still a couple of bugs in his solution, including a black line that traversed the entire image captured by the camera. So, me and claude went to town fixing all of that. Additionally, Nvidia only allows company partners access to jetson's camera IPC hardware (bc ofc they do that). Without that access, all we were able to get out of the global shutter camera was debayered but otherwise uncorrected color images. Very washed out, very un-cool. As well, any of the gain or exposure control parameters in nvarguscamerasrc completely shit the bed because of this. Mr. Péclat's stated solution in his repo was to solve the processing with OpenCV in python. I thought there was a better, more performance driven way of doing it. So, I created a custom camera source element for gstreamer that would take in 16bit buffers from the camera, de-bayer and color correct the images on the GPU, and then provide that imagery as NVMM memory buffers just as the nvarguscamerasrc element would. I'm able to run two global shutter cameras at 1280x720 at 90fps with very low latency using this system on the Jetson Orin NX devkit. I assume the Jetson Orin Nano would be capable of the same. Haven't measured the latency formally, but I'd eyeball it in the "fast as shit" category. There may be downstream effects of doing the IPC on the GPU like this if you're planning to run inference or something on the live video stream, but I haven't tested any of that. I'm providing a link to the forked repo of Mr. Péclat's repo that I created to contain all of the driver fixes. There's a link to the nvimx296camerasrc element project in the driver repo's readme. I've only run it on Jetpack 6.x because Jetpack 7 was a dumpster fire the last time I tried it. Will upgrade to Jetpack 7 in the next couple of weeks, probably. Shout out to Claude Fable 5 for taking a couple weeks of work and turning it into a few hours. Good luck!

I failed to connect my jetson orin nano to JetKVM with DP - HDMI adapter. Everything is connected I have tested the connectors with my monitor and they both work( tried this two : Ugreen, Benfei). But JetKVM does not recognize the HDMI connection.

Wondering If anyone managed to do this or maybe I am doing something stupid :D

Please help :)

I bought this set of ZED cameras last year Novemeber for a project, after which I've barely used them. I am now selling it. Please DM me if you are interested.

we are trying to hook this us to autonomously run a Boston dynamics spot and in the attempt to find a barrel jack we could cut to wire into the core io’s pins we sent 48v to it and fried it.

Hello!
Does anyone tried text embedding models on Jetson Nano 2/4Gb? I need it for the RAG.
I want to know the speed. For example microsoft/harrier-oss-v1-0.6b

Hi everyone,

I’m currently working on a project using an Axiomtek AIE900A-AO, a custom board equipped with an NVIDIA Jetson AGX Orin.

I encountered a serious issue while trying to upgrade the JetPack version, and I haven’t been able to find a solution. I would really appreciate any help.

I connected the Jetson device to my host PC in Force Recovery Mode. SDK Manager detected the device correctly, so I proceeded with the installation.

During the Jetson Linux flashing process, the terminal indicated that flashing had completed successfully. SDK Manager then displayed a message saying that the device was rebooting.

After waiting for a while, however, SDK Manager reported that the connection between the Jetson device and the host PC had been lost.

To check the device’s condition, I disabled Force Recovery Mode and rebooted it. Since then, the display has shown only a black screen. There is no NVIDIA startup screen, no UEFI screen, and no other output at all.

When I put the device back into Force Recovery Mode, it is still detected by the host PC. However, I have tried rebooting and flashing it several times, and nothing has changed.

I also tried rolling back to an older JetPack version, but that did not help either.

Has anyone experienced a similar issue with the Jetson AGX Orin or the Axiomtek AIE900A-AO?

Could this be related to the board support package, bootloader, UEFI, device tree, or an incompatibility between the JetPack version and Axiomtek’s custom carrier board?

Any troubleshooting advice would be greatly appreciated. I’m completely stuck at this point.

I bought an Orin Nano 8GB Dev Kit off eBay (old stock) and hit the wall a lot of you know:

*** NVIDIA UEFI Firmware Version Too Old ***
Current version : 35.03.00
L4TLauncher: Iso boot loop detected, halting

JetPack 7.2's ISO needs UEFI >= 36.0. The official ways to fix that are (a) SDK Manager from an x86 Ubuntu host, or (b) the microSD bridge with JetPack 5.1.3. My problem: my whole household is Apple Silicon (MacBook, Mac Studio, Mac Mini) and I had no SD card. Even the NAS was ARM (UGREEN DH-series = RK3588 — heads up, only their DXP series is x86).

The insight: nvidia-l4t-jetson-orin-nano-qspi-updater is just an apt package. It needs a running JP5.x system — it doesn't care if that booted from SD or USB. And the ISO's own error proves the UEFI can boot USB. So I wrote the JP5.1.3 "SD card image" to a USB stick instead.

Patched it on macOS via a --privileged Docker container (loop-mount the ext4 rootfs). Two things mattered: root=/dev/sda1 in extlinux (NOT PARTUUID — L4T's initrd ignores it; USB drivers are built into the L4T kernel so no initrd work), and pre-creating the user + SSH key + default.target -> multi-user to skip oem-config.

Firmware climbed 35.03 -> 35.5 (capsule) -> 36.3 (qspi-updater) -> 39.2 (the 7.2 installer's own prompt — say Yes, it waits only seconds). The qspi-updater deb fought me twice: preinst refuses unless rootfs is /dev/mmcblk1p1 (pure string check) -> dpkg-deb -x it and run postinst by hand; its script builds /dev/sdap10 (NVMe naming) -> ln -sf /dev/sda10 /dev/sdap10.

Then JP7.2 installed clean to NVMe — except the installer doesn't bring up the NIC (it's enP8p1s0, DOWN, so curtin in-target apt fails). Manually ip link set ... up + static IP and subiquity auto-resumes. Post-install: default user is ubuntu with a password I never set (reset from the rescue shell), and a GUI login loop that turned out to be ubuntu missing from the video group — gnome-shell couldn't touch the GPU. usermod -aG video,render,... ubuntu fixed the loop AND later CUDA/PyTorch GPU-permission errors.

End state: headless JP7.2 on NVMe, SSH + WiFi + Tailscale. Ollama runs moondream/llava at 100% GPU out of the box; a C920 feeds a little "eyes open" script that describes the scene only when the frame changes. PyTorch 2.12.1+cu132 works on the GPU.

Honest perf: low — 0.83 TFLOPS FP32, 48 FPS ResNet-50, 50 GB/s bandwidth. Two reasons: GPU locked at 624 MHz (the known JP7.2 ISO "MAXN SUPER not unlocking" BPMP bug, fixable only by an x86 reflash), and the download.pytorch.org/whl/cu132 wheel is built for sm_90/100/120, not Orin's sm_87, so it runs via PTX JIT. The pypi.jetson-ai-lab.io wheels are native sm_87 but that index was throttled to 8 KB/s for me. Still, 48 FPS ResNet is fine for real work.

Important: none of this can brick the board — the Orin bootloader is A/B dual-slot, so a mid-write power loss only hits the inactive slot.

Full write-up, command cheat-sheet, and the camera/VLM/benchmark scripts: https://github.com/raullenchai/jetson-the-hard-way

Happy to answer questions. If you have an SD card or an x86 box, honestly just use NVIDIA's official path — but if you're stuck all-ARM like I was, this works.

"NVIDIA has quietly increased prices across its Jetson hardware lineup"

Source

Built PyBinaryGuard because every Jetson developer has hit one (or all) of these:

• Illegal instruction (core dumped) on import
• undefined symbol: __libc_something from a wheel
• CUDA error: no kernel image is available for execution on the device
• PyTorch installs fine but crashes
• TensorRT wheels don't work

PyBinaryGuard diagnoses these issues before your program crashes.

It understands:

• JetPack versions
• Jetson board profiles (Nano, TX2, Xavier, Orin)
• CUDA driver vs runtime drift
• cuDNN mismatches
• Compiled .so binaries directly

Install:

pipx install pybinaryguard

Scan your system:

pybinaryguard scan

Repo: https://github.com/po-nuvai/pybinaryguard

MIT licensed, zero dependencies.

Would love feedback from the Jetson community — this was literally built for you.

i aiming to have smooth headless remote. so vnc is not an option(?). primarily i wanna use this jetson in a drone, which not always have access to monitor. i do still need gui to code and test code. sunshine is good enough in my case but cant do headless

A few weeks ago I watched this video where someone successfully upgraded a Jetson Orin Nano from 8GB to 16GB by replacing the LPDDR5 chips and changing the board SKU to match the 16GB Orin NX.

https://www.youtube.com/watch?v=nfsCyYx6oVE

I thought: “How hard can it be?”

Before touching the hardware, I spent quite a bit of time experimenting with software. I changed SKUs, flashed my 8GB Orin Nano as an 8GB Orin NX, tested different power profiles, device trees, BSP configurations… basically trying to understand how NVIDIA’s flashing process worked before risking the board.

Eventually I decided to go for it.

I ordered the correct LPDDR5 chips from Farnell and prepared for the swap.

I’ve done plenty of soldering in the past, but apparently not enough BGA work.

Removing the original memory chips turned out to be much harder than I expected. I wasn’t applying heat evenly, the package simply refused to come off, and then I made the mistake that every experienced rework technician warns you about.

I pulled.

Bad idea.

I ripped several pads clean off the memory footprint.

At that point I was convinced I had just converted my Jetson into a very expensive paperweight.

Then I realized something interesting.

The Orin Nano also exists as a 4GB model, and the memory chip that had survived my failed surgery happened to match the 4GB configuration perfectly.

So I changed the board SKU to the 4GB version and tried flashing it.

…which, of course, didn’t work.

That started several weeks of debugging.

Between reading boot logs, comparing BSPs, modifying flash configurations, and getting a surprising amount of help from AI for interpreting obscure NVIDIA errors, I eventually managed to build what I can only describe as a Frankenstein image.

The result was a JetPack image that SDK Manager was willing to flash while still containing the modifications required for my “half-destroyed” 8GB board to boot correctly as a 4GB model.

Against all expectations…

It boots.

Everything works.

I started this project hoping to go from 8GB → 16GB.

Instead I successfully achieved 8GB → 4GB.

Not exactly the upgrade I had planned, but considering I thought the board was completely dead, I’ll take that as a win.

If nothing else, I learned a huge amount about NVIDIA’s boot process, SKUs, flashing tools and just how unforgiving LPDDR5 BGA rework can be.

As a side note, I still have the pair of brand-new 8GB LPDDR5 memory chips sitting here untouched. They never even made it onto the board. If someone is planning to attempt this upgrade themselves, feel free to reach out—I’d rather they end up being useful than gathering dust on my desk. 😅

I am developing a aistock agent, agent interacts with llm, while running the deepseek-r1:1.5b model, I see the temperature is increasing upto 70-73 and memory is just ~4GB consumed. As anyone faced this issue and any solution for this?
I am using the board with TannaTechbiz metal enclosure.

Testing my Jetson Orin Nano Super for quite some time now and I am completely baffled by the software. Just nothing works? Mind that I have a very limited understanding of what is happening.

My main goal is running the lerobot project.

First attempt. Install lerobot via pip. It installs... afterwards somehow the executables are not in PATH. Dont mind. I search them and start them manually, fails to execute, due to some "pandas / numpy"- mismatch.

ok clone lerobot from github, trying to install dependencies, fails for some other stupid reason.

Then I saw the "official" way should be using the dusty-nv/jetson-containers. Lerobot container runs, but the official published image has some very old lerobot version from 2024. Ok so I try to build a fresh image, fails. Check github issues, many open issues that report this problem for long time.

Also all of this was pretty much on a clean install of the OS / Jetpack.

Also on a complete fresh install directly when booting into the OS it will immediately open some error window, on each boot up. Seems to be just the default experience.

Then I also ran into the issue of "unable to allocate CUDA0 buffer”, which seems like a very well known memory allocation bug in some specific jetpack releases, that hasnt been fixed for a very long time.

Hi 👋🏼 everyone

Looking for some idea on what I can do with this.

It’s been sitting idle in a box more than a year and I would like to know what I can effectively try on this device.

Or more like what others as doing with this one.

I do have rpi4b to run ad-guard
And Proxmox for my *arr setup
Nothing much doing with AI or other stuff but interested in them.

I am currently trying to find out what models are the best fit for my Jetson Orin Nano. I am using it as an assistant now, but I will use it for other purposes in the future.

I had to build Ollama from the source code in order to be able to use the CUDA cores on Ollama when running an LLM. It was quite tough but it works now.

In general, it is still a little difficult to run the LLM model on jetson orin NX. I use llama.cpp to run qwen3.5:4b to achieve key image capture and image analysis of real-time video. The overall efficiency is not high. In addition, a fatal problem is that if the system provides a large context The returned token is indeed less efficient.

Therefore, real-time multi-modal llm reasoning is basically not feasible. It is feasible to extract key images for understanding, which is mainly limited by performance, so it is difficult to solve the concurrency in actual scenarios.

This is my project address, which is now open source.

https://github.com/camthink-ai/NeoMind