{"id":134689,"date":"2026-10-21T07:17:26","date_gmt":"2026-10-21T07:17:26","guid":{"rendered":"https:\/\/www.seeedstudio.com\/blog\/?p=134689"},"modified":"2026-10-21T07:17:30","modified_gmt":"2026-10-21T07:17:30","slug":"yocto-on-jetson-build-and-flash-on-seeed-carrier-boards","status":"publish","type":"post","link":"https:\/\/www.seeedstudio.com\/blog\/2026\/10\/21\/yocto-on-jetson-build-and-flash-on-seeed-carrier-boards\/","title":{"rendered":"Yocto on Jetson: Build and Flash on Seeed Carrier Boards"},"content":{"rendered":"\n

A completed image build leaves several questions open: does the flash package match the installed module, which carrier interfaces have been validated, and can another engineer reproduce the configuration?<\/p>\n\n\n\n

For Yocto on Jetson, keep the carrier, module SKU, source revision and image recipe together through building, flashing and target validation.<\/strong> This guide uses reComputer Super J401 to show what to record and where to check before proceeding. The complete Seeed Wiki<\/a> maintains the commands and full parameter tables.<\/p>\n\n\n\n

Compare hardware options<\/a><\/p>\n\n\n\n

Troubleshoot your build<\/a><\/p>\n\n\n\n

Community & resources<\/a><\/p>\n\n\n\n

\"Yocto<\/figure>\n\n\n\n

Start with the system you need to maintain<\/h2>\n\n\n\n

The Yocto Project<\/a> provides tools and metadata for creating custom embedded Linux systems. BitBake executes the build tasks; image recipes select system contents. A Jetson module provides the compute, while the carrier connects it to power, storage and peripherals. MACHINE<\/code> selects the hardware configuration.<\/p>\n\n\n\n

NVIDIA’s Yocto guidance<\/a> identifies image customization, CI integration and product maintenance as reasons to use it. If your task is application exploration, start with standard JetPack. Evaluate Yocto when package selection and system configuration need to become maintained build inputs. Budget for BSP integration and target testing alongside the build itself.<\/p>\n\n\n\n

Before adopting that workflow, name the system requirement you need to control: a defined package set, a repeatable application environment, or a carrier-specific configuration maintained with the product. Then decide who owns the image and how changes will be reviewed. A useful first milestone is one known hardware configuration running the required application, with enough recorded evidence for a colleague to repeat the exercise. Expanding the hardware matrix before that baseline is understood makes failures harder to isolate. Keep image development and application acceptance connected throughout the project.<\/p>\n\n\n\n

Record one configuration before building<\/h2>\n\n\n\n

The reviewed Seeed repository snapshot<\/a> uses OE4T wrynose<\/code> and the meta-tegra BSP for Jetson Linux R39.2.0 \/ JetPack 7.2. That is this example’s scope; check the current Wiki for another release.<\/p>\n\n\n\n

Use the following as a configuration record. The carrier, module and recipe are example inputs; fill in the actual source revision, artifact and results from your build.<\/p>\n\n\n\n

MACHINE: recomputer-orin-super-j401\nModule: Orin NX 16GB \/ P3767-0000\nModule SKU: 0000\nImage recipe: seeed-image-jetson-development\nSource commit: <record your exact checkout>\nBuild directory: <dedicated to this carrier and module>\nFlash archive and checksum: <record the generated artifact>\nTarget checks: <record pass \/ fail \/ not tested>\n<\/code><\/pre>\n\n\n\n
In the image-profile definitions<\/a>, seeed-image-jetson-runtime<\/code> is the Seeed runtime profile. The development image adds target-side nvcc<\/code>, headers and build tools. The optional x86_64 cross-development SDK is a separate output; it is unnecessary merely to flash or compile directly on the Jetson.<\/p>\n\n\n\n
Choose the profile according to where development happens. If engineers compile and investigate software on the target, start with the development image and verify the tools they need. For a runtime image, document which application dependencies belong in the image and which your deployment process supplies. Treat a later change of recipe as a configuration change: identify the new output and repeat the relevant target checks. This makes a missing compiler or library an image-selection question before it becomes an installation investigation.<\/p>\n\n\n\n
Keep a separate build directory for each carrier\/module combination. This record becomes the reference when comparing a build log, a flash archive and a target result.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Choose hardware by the evidence available<\/h2>\n\n\n\n
The pinned support matrix<\/a> covers 16 machine configurations. Its physical-validation records have specific limits:<\/p>\n\n\n\n
Configuration<\/th>Recorded evidence<\/th><\/tr><\/thead>
recomputer-orin-super-j401<\/code><\/td>Build, initrd flash, NVMe boot, HDMI and basic USB validated.<\/td><\/tr>
reserver-agx-orin-j501x-gmsl<\/code>, SKU 0004<\/code><\/td>Build, flash and boot validated; GMSL\/peripheral validation pending.<\/td><\/tr>
Other listed machines<\/td>Build validation; physical validation is not claimed.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Treat untested interfaces as project work when estimating integration effort. A camera connector or machine definition alone does not establish that your camera works under the selected image.<\/p>\n\n\n\n
Read each matrix row as evidence for the configuration and interfaces actually named. For example, a project that requires GMSL still needs a camera-validation task even when that carrier has a boot record. Likewise, a different module SKU introduces a new configuration to review. Write those open checks into the project plan before ordering several units or assigning a deployment date. This turns the support matrix into an integration-planning input rather than a general compatibility badge.<\/p>\n\n\n\n
reComputer Super J401 carrier board<\/h3>\n\n\n\n
\"Seeed<\/figure>\n\n\n\n
reComputer Super J401 carrier board<\/em><\/p>\n\n\n\n
Orin NX \/ Nano carrier-board route.<\/strong> This is the example carrier above. Select the installed module explicitly and validate your application’s additional interfaces.<\/p>\n\n\n\n
Check Super J401 specifications and purchase options<\/a>.<\/strong><\/p>\n\n\n\n
reComputer Mini J5011 with GMSL<\/h3>\n\n\n\n
\"Seeed<\/figure>\n\n\n\n
reComputer Mini J5011 with GMSL<\/em><\/p>\n\n\n\n
AGX Orin 32GB complete-system route.<\/strong> The Mini AGX J501X machine is build-validated in the reviewed matrix; physical validation is not claimed there. Plan Yocto hardware and GMSL testing for this configuration.<\/p>\n\n\n\n
Explore Mini J5011 specifications and purchase options<\/a>.<\/strong><\/p>\n\n\n\n
For other formats, browse Seeed’s Jetson catalog<\/a>, then verify the exact carrier\/module pairing in the Wiki table<\/a> and current support matrix<\/a>. Check package contents separately from Yocto support before ordering.<\/p>\n\n\n\n
Four checks from source to target<\/h2>\n\n\n\n
Plan around 32 GB RAM or more<\/strong> using the Yocto host guidance<\/a>, and approximately 400 GB free storage<\/strong>. This path uses a physical x86_64 Linux host and a data-capable recovery USB connection.<\/p>\n\n\n\n
\"Seven-stage<\/figure>\n\n\n\n
Workflow for the JetPack 7.2 \/ L4T R39.2.0 path. source: Seeed Wiki<\/a>.<\/em><\/p>\n\n\n\n
    \n
  1. Workspace: compare inputs before compiling.<\/strong> Clone the repository, record its commit and prepare the dedicated directory. The helper reference<\/a> documents build.sh current<\/code> to inspect the prepared machine and module SKU. Resolve any mismatch before building.<\/li>\n\n\n\n
  2. Build: retain an identifiable artifact.<\/strong> build.sh all<\/code> runs metadata, device-tree, boot-file and image stages. Record the resulting tegraflash archive, its checksum and the configuration above. Keep the reported manifest and SBOM paths with the build log so another engineer can identify the output.<\/li>\n\n\n\n
  3. Flash preparation: match the same image.<\/strong> Pass the same image recipe to build and preparation. The Wiki’s preparation helper checks the archive and selected boot files before presenting the flash command. Confirm the target and storage before executing a process that rewrites them. OE4T’s flashing reference<\/a> explains the platform-specific mechanisms.<\/li>\n\n\n\n
  4. Target: record what actually worked.<\/strong> Follow the carrier’s recovery and first-boot instructions, then test the storage and interfaces your application uses. Record each as passed, failed or untested. A booting desktop alone leaves camera, network and expansion behavior unresolved.<\/li>\n<\/ol>\n\n\n\n
    This review record ties an observed target result to a specific build. Keep it with your release artifacts as you add packages or change hardware.<\/p>\n\n\n\n
    Make the output reviewable before handoff<\/h3>\n\n\n\n
    A directory of similarly named images is difficult to hand over. Use the helper’s reported deployment paths<\/a> to identify the exact outputs, then attach a short review record:<\/p>\n\n\n\n
    Review question<\/th>Evidence to retain<\/th><\/tr><\/thead>
    What produced this image?<\/td>Source commit, carrier, module SKU, recipe and build log<\/td><\/tr>
    Which package was flashed?<\/td>Exact archive filename, checksum and preparation output<\/td><\/tr>
    What passed on the target?<\/td>Boot\/storage observations and individual interface results<\/td><\/tr>
    What remains unresolved?<\/td>Untested functions, first failure, relevant logs and next investigation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    For a camera-based robotics application, an interface result should identify the camera and connection, the capture configuration, and the observation used to judge success. Include the application startup sequence and any relevant networking checks. Define acceptance criteria before testing, and record failures with the same detail as successes. These are suggested review fields, not results claimed for the example hardware.<\/p>\n\n\n\n
    Keep build completion, flash completion and application acceptance as separate outcomes. When a colleague receives the package, they should be able to identify its inputs, repeat the documented procedure and see which conclusions still need verification. That makes the record useful during a later regression investigation as well as the initial bring-up.<\/p>\n\n\n\n
    Run the complete Seeed build-and-flash workflow<\/a><\/strong> with your configuration record beside it.<\/p>\n\n\n\n
    <\/p>\n\n\n\n
    Diagnose the first failed stage<\/h2>\n\n\n\n
    Preserve the first error before changing configuration. These checks narrow an investigation; symptoms do not establish a single cause.<\/p>\n\n\n\n
    Symptom<\/th>Check next<\/th>Save for escalation<\/th><\/tr><\/thead>
    Wrong machine or SKU<\/td>Prepare a new directory for the correct hardware.<\/td>Module number and build.sh current<\/code> output<\/td><\/tr>
    Fetch\/configure\/compile failure<\/td>Open the failed task’s reported log; inspect disk\/RAM if the error indicates resource exhaustion.<\/td>Recipe, task and first error context<\/td><\/tr>
    Missing flash archive<\/td>Compare the image name and deploy path used by build and preparation.<\/td>Selected recipe and artifact filename<\/td><\/tr>
    Waiting for USB storage device flashpkg<\/code><\/td>Follow the helper’s USB sequence; this stage is waiting for temporary USB-storage enumeration, before rootfs writing.<\/td>log.initrd-flash.*<\/code> and host USB observations<\/td><\/tr>
    Flash completes but boot or an interface fails<\/td>Check the first-boot procedure, exact support status and target logs.<\/td>Boot output and the specific failed interface<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    The Yocto debugging guide<\/a> locates task logs under ${WORKDIR}\/temp\/log.do_<task><\/code>. The USB debug notes<\/a> distinguish completed recovery download from initrd enumeration and describe compiled-DTB checks. Use the documented SoC-specific path; avoid guessing a host drive name.<\/p>\n\n\n\n
    For a failed task, preserve its recipe name, task name and the first useful error context before rebuilding. If you change configuration, record what changed and compare the next attempt with that baseline. Avoid changing the image recipe, carrier selection and USB setup together; the next result would be difficult to interpret. When escalation is necessary, attach both the configuration record and the stage-specific log. A screenshot of the final error line alone often omits the information another engineer needs to investigate.<\/p>\n\n\n\n
    For example, if the system boots but nvcc<\/code> is missing, compare the selected recipe with the intended development workflow before rebuilding the BSP. A runtime\/development mismatch and a boot failure belong to different investigations. Similarly, when a flash archive cannot be found, first compare the build and preparation image names. Preserve the existing logs while checking those inputs. These comparisons help you decide whether the next experiment should change the image, the prepared workspace, or the target-side test, without losing the original failure context.<\/p>\n\n\n\n
    <\/p>\n\n\n\n
    Help the next person who picks this up<\/h2>\n\n\n\n
    When you verify a previously untested machine or interface, propose a repository update<\/a> with the configuration record, logs and exact tests performed. A confirmed NVMe boot is useful evidence; leave untested interfaces explicitly untested.<\/p>\n\n\n\n
    For discussion, include the commit, carrier, module SKU, image and first failing stage. Compare setups with other builders and update the thread when you find the cause.<\/p>\n\n\n\n