← Back to list

I’ve started building a custom Yocto-based OS project for NVIDIA Jetson Nano Super so developers…

Repo: https://github.com/dhirajsinhdeshmukh/yocto-orin

dhiraj deshmukh · 2026-04-15 22:40 · 1 claps · 4.0 min read
#software-development #software-engineering #ai #yocto #cybersecurity
Open on Medium ↗
Wiki topics: AI · AI · General 🔒 · Cybersecurity 🔓 · Open Source

First Steps to Build a Custom OS Distro on NVIDIA Jetson Nano Super

First Steps to Build a Custom OS Distro on NVIDIA Jetson Nano Super

I’ve started building a custom Yocto-based OS project for NVIDIA Jetson Nano Super so developers can build and control their own embedded Linux distro instead of relying only on vendor images.

Repo: https://github.com/dhirajsinhdeshmukh/yocto-orin

This project is still early, but it already crosses the first real milestone: build a custom image, flash it, boot the board, find its IP, and log in over SSH. It is not production-ready yet, and that is exactly why I wanted to share it now. Real embedded work does not begin with polished demos. It begins with bring-up, debugging, imperfect images, missing logs, hardware friction, and steady iteration.

What works now

The current flow is simple and practical:

Recovery Mode → Build Image → Flash Board → Boot → Find IP → SSH Access

Getting started

  1. Power off the Jetson
  2. Put it into recovery mode by shorting FC_REC to GND
  3. Connect USB-C to the Jetson and USB-A to the host
  4. Power on the board
  5. Verify recovery mode with lsusb
  6. Build a writable bring-up image
  7. Flash the board
  8. Let it boot normally
  9. Find its IP with nmap
  10. Log in with SSH
lsusb | grep -i nvidia
# Expected: ID 0955:7523 NVIDIA Corp. APX
./build.sh --rootfs rw --no-dm-verity
./flash.sh
nmap -sn 192.168.1.0/24
ssh root@<jetson-ip>

Why I started this

Most Jetson projects stop too early. They boot a vendor image, run a demo, maybe load a model, and call it a system. I wanted to start from the opposite end: own the platform itself.

For me, the motivation is simple. If the OS is not under your control, the product is not really under your control. If you cannot shape the root filesystem, the partition structure, the update path, the security model, and the boot behavior, then you are building on top of borrowed assumptions. That is fine for evaluation. It is weak for real products.

That is why I started this project.

The goal is not just to flash Linux onto a Jetson board. The goal is to build a path toward a real custom distro for edge AI systems: something reproducible, understandable, secure, extensible, and designed for actual deployment instead of temporary experimentation.

I also believe more embedded AI work needs to be built in the open. Too many projects hide the messy part: the boot failures, the recovery-mode mistakes, the missing serial logs, the ugly first partition layouts, the wrong assumptions about debugging. But that messy phase is where the real engineering happens. Sharing from the start makes the learning more honest and the project more useful.

One early lesson

I thought RNDIS USB would be enough to debug startup issues. It was not.

RNDIS makes the device appear as a virtual Ethernet adapter to the host, which helps the Jetson get an IP and makes first access easier. That part is useful. But it does not solve early boot debugging, because it gives no boot logs.

RNDIS USB = Good for network access
UART-to-USB = Needed for real boot debugging

That was one of the first hard lessons. When the board fails early, network access is not enough. You need visibility into startup, and that means serial. For faster development and better debugging, I’m now waiting on a UART-to-USB adapter. In embedded Linux, serial still wins.

Philosophy behind the project

My philosophy here is straightforward: first own the basics, then build the advanced stack on top.

That means:

  • first make the image build reliably
  • first make flashing repeatable
  • first make bring-up understandable
  • first make debugging visible
  • then harden the system
  • then optimize it
  • then layer AI and networking features on top

A lot of projects try to skip straight to the exciting part: inference, demos, dashboards, benchmark screenshots. I think that is backwards. If the OS foundation is weak, the rest is fragile. A stable AI edge system is built on boring things done properly: filesystem design, partitioning, recovery flow, read-only rootfs behavior, integrity checking, and observability.

That is the direction of this repo.

What’s next

In the coming week, I’ll keep expanding the project with:

  • production-grade partition structure
  • dm-verity security
  • read-only OS with overlayfs support
  • AI stack integration
  • networking stack improvements

After that, I want to start running vision-based SLM workloads on top of this platform.

Technical direction

The technical direction is becoming much clearer now.

The current stage is a writable bring-up image because speed matters early. You need a fast loop for building, flashing, booting, and testing. But that is only the beginning. The next step is moving toward a cleaner partition design that better reflects how a real deployed device should look.

From there, the system should move toward stronger integrity and reliability:

  • production-grade partition structure for cleaner storage organization
  • dm-verity to protect the root filesystem and verify integrity at boot
  • read-only OS + overlayfs so the base system stays stable while still allowing controlled runtime changes
  • a more complete networking stack for real device connectivity
  • an AI software layer that can support actual edge workloads instead of just bring-up testing

That matters because edge AI systems are not just about running models. They are about running models on systems that boot reliably, stay consistent, recover cleanly, and are easier to secure and maintain over time.

My long-term view is to turn this into a usable Jetson distro base where AI, networking, storage integrity, and deployment concerns are treated as one system, not as disconnected patches added later. Once that base is solid, the exciting part begins: running real vision-based SLM workloads on top of a platform that was built for that purpose from the ground up.

Final thought

This repo is still rough, incomplete, and early. Good. That means it is real. The first step is already there: build, flash, boot, discover, connect. Next comes the deeper work of turning it into a secure, extensible custom Jetson distro for edge AI.

Repo again: https://github.com/dhirajsinhdeshmukh/yocto-orin


메타데이터
post_id
fbda3d0ffe07
slug
ive-started-building-a-custom-yocto-based-os-project-for-nvidia-jetson-nano-super-so-developers-fbda3d0ffe07
url
https://medium.com/@deshmukhdhiraj15/ive-started-building-a-custom-yocto-based-os-project-for-nvidia-jetson-nano-super-so-developers-fbda3d0ffe07
canonical_url
https://medium.com/@deshmukhdhiraj15/ive-started-building-a-custom-yocto-based-os-project-for-nvidia-jetson-nano-super-so-developers-fbda3d0ffe07
author_url
https://medium.com/@deshmukhdhiraj15
status
ok
fetched_at
2026-07-11 06:17:06