agentleFS
Seeed-ProjectsSeeed-Projects/Seeed-Jetson-DevelopTool/skills/codex/ko-module-build/AGENTS.md

Seeed-Jetson-DevelopTool / ko-module-build

AGENTS.md57 starsChanged 4 months agoMITView on GitHub

Compile and load a custom .ko kernel driver module on Seeed Jetson devices (reComputer/reServer). Downloads BSP source, extracts driver code, builds with Makefile, and loads via modprobe. Example uses pl2303 on JetPack 6.2.

  • Deletes or force-pushes
  • Installs packages

The file

We split this AGENTS.md into the rules it gives an agent

6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When a required .ko driver module is missing from reComputer/reServer, compile it directly on the Jetson device.

    line 8
  2. Distinctive:

    Run one phase at a time. After each phase:

    line 19
  3. Very specific:

    If output contains [STOP] → stop immediately, consult the failure decision tree

    line 20
  4. Very specific:

    If output ends with [OK] → tell the user "Phase N complete" and proceed

    line 21
  5. Very specific:

    Ask the user which driver module they need (e.g.

    line 36
  6. Very specific:

    Create a Makefile in the workspace:

    line 92

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

Build a .ko Driver Module for Seeed Jetson

When a required .ko driver module is missing from reComputer/reServer, compile it directly on the Jetson device. This guide uses the pl2303 USB-to-serial driver on JetPack 6.2 (L4T 36.4.3) as an example.

Hardware: Seeed Jetson device (reComputer/reServer) Software: JetPack 6.x (L4T 36.x), internet connection


Execution model

Run one phase at a time. After each phase:

  • If output contains [STOP] → stop immediately, consult the failure decision tree
  • If output ends with [OK] → tell the user "Phase N complete" and proceed

Replace <driver_name> with the actual driver (e.g. pl2303) throughout.


Phase 1 — identify L4T version and target driver (~30 s)

cat /etc/nv_tegra_release

Determine the L4T version (e.g. 36.4.3 = JetPack 6.2). Find the JetPack ↔ L4T mapping at: https://developer.nvidia.com/embedded/jetpack-archive

Ask the user which driver module they need (e.g. pl2303, ch341, etc.).

[OK] when L4T version and target driver are confirmed.


Phase 2 — download and extract BSP source (~10 min)

Download public_sources.tbz2 for the matching L4T version from NVIDIA's L4T release page.

Extract all nested archives:

tar -xjf public_sources.tbz2
cd Linux_for_Tegra/source

find . -type f \( -name "*.tbz2" -o -name "*.tar.bz2" -o -name "*.tar.gz" -o -name "*.tgz" -o -name "*.tar.xz" \) -exec bash -c '
    dir=$(dirname "$1")
    filename=$(basename "$1")
    cd "$dir"
    if [[ "$filename" == *.tbz2 || "$filename" == *.tar.bz2 ]]; then
        tar -xjf "$filename"
    elif [[ "$filename" == *.tar.gz || "$filename" == *.tgz ]]; then
        tar -xzf "$filename"
    elif [[ "$filename" == *.tar.xz ]]; then
        tar -xJf "$filename"
    fi
    cd - > /dev/null
' _ {} \;

[OK] when extraction completes without errors.


Phase 3 — locate driver source file (~1 min)

sudo find . -type f -name "*<driver_name>*"
# Example: sudo find . -type f -name "*pl2303*"

Note the path — it indicates both the source file and the target install path.

[OK] when driver source file (e.g. pl2303.c) is found. [STOP] if not found — driver may not be in this BSP version.


Phase 4 — create build workspace (~1 min)

mkdir -p ~/ko_build && cd ~/ko_build
cp <path_to_driver_source>/<driver_name>.c .

Create a Makefile in the workspace:

obj-m += <driver_name>.o
all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Replace <driver_name> with the actual name (e.g. pl2303).

[OK] when workspace contains both the .c source and Makefile.


Phase 5 — create kernel build symlink (~30 s)

sudo rm -rf /lib/modules/$(uname -r)/build
sudo ln -s /usr/src/linux-headers-$(uname -r)-ubuntu22.04_aarch64/3rdparty/canonical/linux-jammy/kernel-source \
  /lib/modules/$(uname -r)/build

[OK] when symlink is created without errors. [STOP] if the headers path doesn't exist — install linux-headers-$(uname -r).


Phase 6 — compile the module (~1–5 min)

cd ~/ko_build
make

[OK] when .ko file is generated in the current directory. [STOP] on compile errors — see failure decision tree.


Phase 7 — install and load the module (~30 s)

Copy to the correct kernel module path. The target path prefix is always /lib/modules/$(uname -r)/kernel/ — the suffix matches the source tree structure.

# Example for pl2303 (USB serial driver):
sudo cp <driver_name>.ko /lib/modules/$(uname -r)/kernel/drivers/usb/serial/

Load the module:

sudo depmod -a
sudo modprobe <driver_name>

Verify:

modinfo <driver_name>

[OK] when modinfo shows the module details.


Failure decision tree

SymptomAction
Driver source not found in BSPVerify L4T version matches. Try searching with broader keywords.
Symlink target path doesn't existInstall kernel headers: sudo apt-get install -y linux-headers-$(uname -r)
make fails with missing headersVerify symlink in Phase 5. Check that kernel-source directory has Makefile.
make fails with undefined symbolsDriver may depend on other modules. Check #include directives in source.
modprobe failsCheck dmesg for errors. Ensure .ko is in the correct path. Run sudo depmod -a again.
Module loads but device not workingCheck dmesg for hardware errors. Verify device is connected and recognized by lsusb or lspci.

Reference files

  • references/source.body.md — Original Seeed wiki with screenshots and step-by-step walkthrough

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.