Skip to content

Instantly share code, notes, and snippets.

@doevelopper

doevelopper/0000.md

Created September 13, 2026 13:31
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save doevelopper/a995b88230d923aa135f4889cb9620e9 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save doevelopper/a995b88230d923aa135f4889cb9620e9 to your computer and use it in GitHub Desktop.
Download ZIP
AI prompt for yocto lectures. Learn by doing
Raw
0000.md
  • 0001-yocto-lectures.md
  • 0002-yocto-lectures-K3.md [1] reviewed
  • 0003-yocto-lectures-Qw.md [1] reviewed
Raw
0001-yocto-lectures.md

Role: You are an Expert Embedded Linux Architect and Lead Yocto Project Instructor with deep, hands-on expertise in: Yocto/OpenEmbedded build systems, KAS (kas / kas-container), hardware security (secure boot chains, TPM2, PKCS#11, code signing), ARM Trusted Firmware-A, OP-TEE, U-Boot, TI K3 architecture, and Over-The-Air (OTA) update systems (RAUC, Mender, SWUpdate). You teach by building: every concept must land in a lab that produces a verifiable artifact.

Context: I am an embedded software engineer (comfortable with Linux CLI, Git, and C; new to Yocto and secure boot). I am designing a security-hardened embedded Linux OS and need a complete, hands-on, 16-week learning plan (assume 8–10 hours/week) to master this stack end-to-end.

Target Platform Priority (resolve all scope questions against this):

  1. PRIMARY — TQMa64xxL SOM on STKa64xxL Eval Kit (TI AM64x: Dual Cortex-A53 / Quad Cortex-R5F): The capstone project MUST run on this board. All security modules (secure boot, TPM2, signed OTA) are implemented here first.
  2. SECONDARY — Raspberry Pi 5 (ARM Cortex-A76): Used for comparison labs (different boot flow, different TF-A integration, different TPM wiring).
  3. REFERENCE — Raspberry Pi 3B+ (ARM Cortex-A53): Used only for Yocto basics and performance/legacy comparison. Be explicit and honest: the RPi 3B+ has NO usable secure boot (no eFuse/OTP root-of-trust chain) — do NOT promise TF-A/OP-TEE-based protection on it.
  4. CONCEPT-ONLY — NVIDIA Jetson Orin: No meaningful QEMU emulation of Tegra or its secure boot exists. Cover Orin ONLY as a written comparative analysis (Jetson secure boot, Tegra fuse/PMC-based chain vs. TI K3 flow). Do not invent QEMU labs for it.

Hardware & Security Peripherals Inventory:

  • 2× Raspberry Pi 3B+ (ARM Cortex-A53)
  • 1× Raspberry Pi 5 (ARM Cortex-A76)
  • 1× STKa64xxL Eval Kit with TQMa64xxL SOM (TI AM64x)
  • 1× NXP SE050 secure element / TPM (wired to the TQMa64xxL)
  • 1× Infineon SLB9670 SPI TPM (on the Raspberry Pi 5 header)
  • QEMU + swtpm for TPM2 emulation labs where physical TPM access is not needed
  • Host PC: Ubuntu LTS 26.04 or 24.04 at least, Docker or Podman for kas-container

Version Pinning (mandatory): Anchor the entire plan to ONE Yocto LTS release (recommend the current LTS, e.g., Scarthgap 5.0 LTS, or state a newer LTS if appropriate). For every layer used (meta-ti/meta-ti-bsp/meta-ti-extras, meta-raspberrypi, meta-optee, meta-tpm2, meta-rauc, meta-swupdate, meta-mender, meta-security, meta-openembedded, poky), state the branch name compatible with that release. If you are uncertain a recipe, machine name, layer branch, or DISTRO/CONF setting exists for the pinned release, flag it explicitly as [VERIFY] instead of inventing it. Never fabricate recipe names, image names, or boot artifacts.

Project Motto / Core Objective: "Security-hardened embedded Linux OS for Raspberry Pi (3B+/4/5) & NVIDIA Jetson Orin Built on Yocto · Secured by TPM2 · Protected by OP-TEE & ARM TF-A · Updated via RAUC, Mender, or SWUpdate"

Task: Create the full, structured, 16-week learning plan, incorporating the KAS build tool (kas AND kas-container) for reproducible YAML-based project management, and targeting the TI AM64x architecture for the TQMa64xxL as the primary platform.

Requirements:

  1. Modular Structure: Break into logical Modules mapped to the 16 weeks. Include explicit prerequisite checklists at the start of each module (what must already work before beginning).

  2. Module 0 — Host Environment Setup: Ubuntu LTS host preparation, Docker/Podman installation and rootless configuration, user/group permissions (dialout, docker), kas native install vs. kas-container, repo/Docker caching strategy, serial console access (picocom/minicom), TFTP/NFS boot server setup for the eval kit.

  3. Hardware Mapping: Every lab must explicitly state the hardware used. Use QEMU (+ swtpm where TPM is involved) for destructive/repeatable experiments; use the TQMa64xxL for all security-critical labs; RPi 5 for comparison labs; RPi 3B+ only where its limitations are stated.

  4. KAS Integration (cross-cutting): Do NOT confine KAS to one module. Module 0 introduces KAS, and EVERY subsequent module's lab must provide or extend a KAS YAML project file (kas.yml / kas-container invocation). Include a dedicated KAS module covering: kas vs. pure bitbake workflow, kas YAML schema (repos, layers, machine, distro, target), kas-container for CI (GitHub Actions / GitLab CI skeleton), and multi-config/target builds.

  5. TI AM64x / K3 Secure Boot (deep dive): Use meta-ti (meta-ti-bsp, meta-ti-extras). Cover the full K3 boot flow: R5 SPL → SYSFW (ti-sci) → TF-A BL31 → OP-TEE → U-Boot proper → Linux. Cover TI Secure Development Package, key generation, signing images (tiboot3, SYSFW, TF-A, OP-TEE, U-Boot), writing the SRK hash to eFuses, and enforcing: demonstrate that an unsigned image is REFUSED by the board. Cover R5F coprocessor firmware explicitly (IN SCOPE): remoteproc, RPMsg, loading firmware on the Cortex-R5F from Linux, and building an R5F firmware recipe in Yocto.

  6. Security & Keys Module: PKI fundamentals for embedded: generate the full key hierarchy (root CA, U-Boot fitImage keys, OP-TEE keys, RAUC keyring), secure key storage (PKCS#11 via TPM2/SE050), and integrating signing into the KAS/bitbake build so unsigned artifacts cannot be produced accidentally. This module must precede OTA labs (signed updates depend on it).

  7. TPM2 Module: TPM2 architecture (PCRs, sealing, attestation), tpm2-tools, tpm2-tss engine, PKCS#11 provider. Labs: measured boot integration with TF-A/U-Boot (record PCRs), sealing a disk-encryption key to PCR state on the TQMa64xxL via SE050, and the equivalent on RPi 5 with the SLB9670, plus a QEMU + swtpm variant for repeatable scripting. Note OP-TEE↔fTPM options and where a discrete TPM is preferable.

  8. OTA Module — compare three, implement two, standardize on one: a) Comparison module: decision matrix for RAUC / Mender / SWUpdate covering licensing, atomicity/rollback, update artifacts (bundles/images), code signing & verification, backend requirements, D-Bus/integration API, Yocto layer maturity for the pinned release. b) Hands-on labs: implement A/B updates with RAUC (full integration: signed bundles, keyring, bootloader integration with U-Boot, hawkBit or rauc-hawkbit server optional) AND with Mender or SWUpdate (pick the stronger second candidate and justify the choice). All labs on the TQMa64xxL with KAS. c) Standardize on RAUC for the capstone unless you justify otherwise.

  9. Per-Lab Format (mandatory for EVERY lab):

    • Lab title, estimated time, hardware used, prerequisites
    • Numbered steps with exact commands
    • Expected output at each critical step
    • Definition of Done: a verification checklist with concrete checks (e.g., "boot log shows X", "command Y returns Z", "unsigned image is rejected with error E")
    • 2–3 troubleshooting scenarios with root-cause hints (not just symptoms)
    • The KAS YAML file (or diff) used for the lab

  10. Assessment: End each module with 5–10 checkpoint questions (mix of conceptual and hands-on-verifiable).

  11. Capstone Project (Weeks 14–16): On the TQMa64xxL, deliver:

    • Yocto image built entirely via KAS (kas-container CI pipeline included)
    • TI K3 secure boot enforced end-to-end (eFuse-blown, unsigned images rejected)
    • OP-TEE running with at least one custom TA
    • TPM2 (SE050) measured boot + sealed-disk-encryption demonstration
    • R5F coprocessor firmware loaded via remoteproc with an RPMsg channel to Linux
    • Signed RAUC A/B OTA with automatic rollback on failed boot
    • Capstone acceptance test (must be explicit): a numbered test script a reviewer can execute, including negative tests (unsigned image rejected, tampered bundle rejected, forced-failed update rolls back).

  12. Honesty constraints: State per-board secure-boot limitations plainly (especially RPi 3B+). Distinguish clearly between what upstream Yocto/meta-ti supports and what requires TI NDA'd tooling or vendor extras. Mark any uncertain detail [VERIFY].

Deliverables per module: Learning Objectives (measurable verbs), Key Tools/Layers (with pinned branches), Hardware Used, Practical Lab Assignment(s) in the format above, Prerequisite Checklist, Checkpoint Questions.

Output: Clear, professional, highly technical Markdown. Include a master 16-week schedule table at the top and a dependency graph (which modules feed which).

Raw
0002-yocto-lectures-K3.md

Role: You are an Expert Embedded Linux Architect and Lead Yocto Project Instructor with deep, hands-on expertise in: Yocto/OpenEmbedded build systems, KAS (kas / kas-container), hardware security (secure boot chains, TPM2, PKCS#11, code signing), ARM Trusted Firmware-A, OP-TEE, U-Boot, TI K3 architecture, and Over-The-Air (OTA) update systems (RAUC, Mender, SWUpdate). You teach by building: every concept must land in a lab that produces a verifiable artifact.

Context: I am an embedded software engineer (comfortable with Linux CLI, Git, and C; new to Yocto and secure boot). I am designing a security-hardened embedded Linux OS and need a complete, hands-on, 16-week learning plan (assume 8–10 hours/week) to master this stack end-to-end.

Target Platform Priority (resolve all scope questions against this):

  1. PRIMARY — TQMa64xxL SOM on STKa64xxL Eval Kit (TI AM64x: Dual Cortex-A53 / Quad Cortex-R5F): The capstone project MUST run on this board. All security modules (secure boot, TPM2, signed OTA) are implemented here first.
  2. SECONDARY — Raspberry Pi 5 (ARM Cortex-A76): Used for comparison labs (different boot flow, different TF-A integration, different TPM wiring).
  3. REFERENCE — Raspberry Pi 3B+ (ARM Cortex-A53): Used only for Yocto basics and performance/legacy comparison. Be explicit and honest: the RPi 3B+ has NO usable secure boot (no eFuse/OTP root-of-trust chain) — do NOT promise TF-A/OP-TEE-based protection on it.
  4. CONCEPT-ONLY — NVIDIA Jetson Orin: No meaningful QEMU emulation of Tegra or its secure boot exists. Cover Orin ONLY as a written comparative analysis (Jetson secure boot, Tegra fuse/PMC-based chain vs. TI K3 flow). Do not invent QEMU labs for it.

Hardware & Security Peripherals Inventory:

  • 2× Raspberry Pi 3B+ (ARM Cortex-A53)
  • 1× Raspberry Pi 5 (ARM Cortex-A76)
  • 1× STKa64xxL Eval Kit with TQMa64xxL SOM (TI AM64x)
  • 1× NXP SE050 secure element / TPM (wired via I2C to the TQMa64xxL)
  • 1× Infineon SLB9670 SPI TPM (wired via SPI on the Raspberry Pi 5 header)
  • QEMU + swtpm for TPM2 emulation labs where physical TPM access is not needed
  • Host PC: Ubuntu 22.04 or 24.04 LTS, Docker or Podman for kas-container

Version Pinning (mandatory): Anchor the entire plan to Scarthgap (Yocto 5.0 LTS). For every layer used (meta-ti, meta-ti-bsp, meta-ti-extras, meta-raspberrypi, meta-arm, meta-optee, meta-tpm2, meta-rauc, meta-swupdate, meta-mender, meta-security, meta-openembedded, poky), state the exact branch name compatible with Scarthgap. If you are uncertain a recipe, machine name, layer branch, or DISTRO/CONF setting exists for Scarthgap, flag it explicitly as [VERIFY] instead of inventing it. Never fabricate recipe names, image names, or boot artifacts.

Project Motto / Core Objective: "Security-hardened embedded Linux OS for Raspberry Pi & TI AM64x Built on Yocto · Secured by TPM2 · Protected by OP-TEE & ARM TF-A · Updated via RAUC"

Task: Create the full, structured, 16-week learning plan, incorporating the KAS build tool (kas AND kas-container) for reproducible YAML-based project management, and targeting the TI AM64x architecture for the TQMa64xxL as the primary platform.

Requirements:

  1. Modular Structure: Break into logical Modules mapped to the 16 weeks. Include explicit prerequisite checklists at the start of each module.

  2. Module 0 — Host Environment Setup: Ubuntu LTS host preparation, Docker/Podman installation and rootless configuration, user/group permissions (dialout, docker), kas native install vs. kas-container, repo/Docker caching strategy, serial console access (picocom/minicom), TFTP/NFS boot server setup for the eval kit.

  3. Hardware Mapping: Every lab must explicitly state the hardware used. Use QEMU (+ swtpm where TPM is involved) for destructive/repeatable experiments; use the TQMa64xxL for all security-critical labs; RPi 5 for comparison labs; RPi 3B+ only where its limitations are stated.

  4. KAS Integration (cross-cutting): Do NOT confine KAS to one module. Module 0 introduces KAS, and EVERY subsequent module's lab must provide or extend a KAS YAML project file. Include a dedicated KAS module covering: kas vs. pure bitbake workflow, kas YAML schema, kas-container for CI, and multi-config/target builds.

  5. TI AM64x / K3 Secure Boot (deep dive & safety): Use meta-ti. Cover the full K3 boot flow: R5 SPL → SYSFW (ti-sci) → TF-A BL31 → OP-TEE → U-Boot proper → Linux. Cover TI Secure Development Package, key generation, and signing images. CRITICAL SAFETY: Teach the SMPK/BMPK or custMpk development flow first to test secure boot WITHOUT blowing eFuses. Only teach OTP eFuse blowing in the Capstone, with explicit warnings about bricking the board. Demonstrate that an unsigned image is REFUSED. Cover R5F coprocessor firmware (IN SCOPE): remoteproc, RPMsg, and building R5F firmware using the bare-metal toolchain (gcc-arm-none-eabi).

  6. Security & Keys Module: PKI fundamentals: generate the full key hierarchy, secure key storage (PKCS#11 via TPM2/SE050), and integrating signing into the KAS/bitbake build. This module must precede OTA labs.

  7. TPM2 Module: TPM2 architecture (PCRs, sealing, attestation), tpm2-tools, tpm2-tss engine, PKCS#11 provider. Labs: measured boot integration with TF-A/U-Boot, sealing a disk-encryption key to PCR state on the TQMa64xxL via I2C SE050, and equivalent on RPi 5 via SPI SLB9670, plus QEMU + swtpm variant.

  8. OTA Module — compare three, implement two, standardize on one: a) Comparison matrix for RAUC / Mender / SWUpdate. b) Hands-on labs: implement A/B updates with RAUC AND with Mender or SWUpdate. All labs on the TQMa64xxL with KAS. c) Standardize on RAUC for the capstone unless you justify otherwise.

  9. Per-Lab Format (mandatory for EVERY lab):

    • Lab title, estimated time, hardware used, prerequisites
    • Numbered steps with exact commands
    • Expected output at each critical step
    • Definition of Done: verification checklist with concrete checks
    • 2–3 troubleshooting scenarios with root-cause hints
    • The KAS YAML file (or diff) used for the lab

  10. Assessment: End each module with 5–10 checkpoint questions.

  11. Capstone Project (Weeks 14–16): On the TQMa64xxL, deliver:

    • Yocto image built entirely via KAS (kas-container CI pipeline included)
    • TI K3 secure boot enforced end-to-end (using custMpk or OTP eFuses if sacrificial board is used)
    • OP-TEE running with at least one custom TA
    • TPM2 (SE050) measured boot + sealed-disk-encryption demonstration
    • R5F coprocessor firmware loaded via remoteproc with an RPMsg channel
    • Signed RAUC A/B OTA with automatic rollback on failed boot
    • Capstone acceptance test: a numbered test script including negative tests.

  12. Honesty constraints: State per-board secure-boot limitations plainly. Distinguish clearly between upstream Yocto/meta-ti support and TI NDA'd tooling. Mark uncertain details [VERIFY].

Execution Instructions (How you must respond): Because of the extreme detail required for the Per-Lab Format, DO NOT attempt to output the entire 16-week plan in a single response.

  1. First, output the Master 16-Week Schedule Table, the Dependency Graph, and the complete, detailed content for Module 0 and Module 1.
  2. At the end of your response, ask me: "Shall I proceed with Modules 2 and 3?"
  3. Wait for my prompt to continue generating the subsequent modules in chunks.

Output: Clear, professional, highly technical Markdown.

Raw
0002-yocto-lectures-Qw.md

Role: You are an Expert Embedded Linux Architect and Lead Yocto Project Instructor with deep, hands-on expertise in:

  • Yocto/OpenEmbedded build systems
  • KAS and kas-container
  • hardware security: secure boot chains, TPM2, PKCS#11, code signing, key management
  • ARM Trusted Firmware-A where supported
  • OP-TEE where supported
  • U-Boot
  • TI K3 architecture, especially AM64x
  • OTA update systems: RAUC, Mender, SWUpdate
  • embedded Linux hardening, recovery flows, and lab-based verification

You teach by building. Every concept should land in a practical lab that produces a verifiable artifact, command output, boot behavior, test result, or build artifact.

Context: I am an embedded software engineer. I am comfortable with Linux CLI, Git, and C. I am new to Yocto and secure boot. I want a complete, hands-on, 16-week learning plan to design and validate a security-hardened embedded Linux OS.

Assume:

  • 8–10 hours of active learner time per week.
  • Long Yocto compile times may run in the background.
  • Active debugging/lab time must not exceed 8–10 hours/week unless explicitly marked as stretch work.
  • I prefer reproducible workflows using KAS and kas-container.
  • I value honesty, safety, and verifiable results over optimistic claims.

Critical Truthfulness, Safety, and Feasibility Overrides: These rules override all other requirements if there is a conflict.

  1. Do not fabricate details. If you are uncertain about a recipe, machine name, layer branch, boot artifact, Yocto variable, kernel feature, device-tree, TI tool, TPM feature, SE050 feature, OP-TEE feature, OTA integration detail, or hardware capability, mark it as [VERIFY] and explain how to verify it.

  2. Do not assume the NXP SE050 is a TPM2 device. The SE050 is a secure element. It may support secure key storage or vendor PKCS#11 flows, but it must not be treated as a TPM2 device with PCRs, measured boot, event log, attestation, or PCR-based sealing unless explicit vendor documentation proves that.

  3. TPM2 labs require a real TPM2 implementation. Use one of:

    • a discrete TPM2 device attached to the target,
    • a supported OP-TEE fTPM where appropriate,
    • QEMU + swtpm for repeatable emulation/scripting labs.

    If the primary target lacks verified TPM2 support, perform TPM2 labs on QEMU/swtpm or another supported target and clearly state the limitation.

  4. eFuse/OTP operations must be safety-gated. Any lab involving SRK hash programming, eFuse writing, OTP fuses, or secure boot enforcement must include:

    • explicit irreversible-operation warning,
    • board designation for destructive labs,
    • device-type confirmation, for example GP, HS-FS, HS-SE where applicable,
    • key/hash verification checklist,
    • recovery plan where possible,
    • go/no-go checkpoints,
    • and a non-destructive dry-run or emulation path where possible.

    If safe fuse programming cannot be verified, provide a written procedure and mark execution as instructor-supervised or [VERIFY].

  5. Prefer feasible truthfulness over scope completion. If a requested feature cannot be achieved with the pinned release, hardware, upstream layers, or public BSP, state the conflict and provide the closest feasible alternative.

  6. Do not ask clarifying questions unless fatal. If a fatal ambiguity prevents progress, ask at most three concise questions. Otherwise, record assumptions in an Assumptions & Verification Register and proceed.

Target Platform Priority: Resolve all scope questions against this priority order.

  1. PRIMARY — TQMa64xxL SOM on STKa64xxL Eval Kit, TI AM64x

    • Dual Cortex-A53
    • Quad Cortex-R5F
    • Capstone security labs should target this board where supported.
    • All security-critical implementation labs should prefer this board if feasible.
    • Exact BSP support must be verified; do not invent machine names.

  2. SECONDARY — Raspberry Pi 5, ARM Cortex-A76

    • Used for comparison labs.
    • Useful for TPM2 labs with SLB9670 SPI TPM.
    • Do not assume TF-A, measured boot, or secure boot support unless verified for the pinned Yocto LTS and Raspberry Pi BSP.

  3. REFERENCE — Raspberry Pi 3B+, ARM Cortex-A53

    • Used only for Yocto basics, lightweight labs, and comparison where useful.
    • Do not present it as having a practical, production-grade, upstream-supported verified boot chain for this course.
    • If any OTP/secure boot feature exists, state limitations clearly and mark unsupported parts [VERIFY].

  4. CONCEPT-ONLY — NVIDIA Jetson Orin

    • No hands-on labs.
    • No invented QEMU labs for Tegra secure boot.
    • Cover only as a written comparative analysis against TI K3 secure boot, fuse/root-of-trust concepts, boot flow, and OTA considerations.

Hardware & Security Peripherals Inventory:

  • 2× Raspberry Pi 3B+ (ARM Cortex-A53)
  • 1× Raspberry Pi 5 (ARM Cortex-A76)
  • 1× STKa64xxL Eval Kit with TQMa64xxL SOM (TI AM64x)
  • 1× NXP SE050 secure element wired to the TQMa64xxL
    • Use only for secure key storage / PKCS#11 / vendor-supported crypto flows.
    • Do NOT assume TPM2 PCRs, measured boot, event log, or sealing.
  • 1× Infineon SLB9670 SPI TPM on the Raspberry Pi 5 header
  • QEMU + swtpm for TPM2 emulation labs where physical TPM access is not needed
  • Host PC:
    • Ubuntu LTS; specify exact recommended version.
    • State whether bare metal, VM, or WSL2 is recommended.
    • Docker or Podman for kas-container.
    • Choose one primary container runtime and justify it.

Version Pinning (mandatory): Anchor the entire plan to ONE Yocto LTS release.

  • Recommend the current LTS if known.
  • If uncertain, use Scarthgap 5.0 LTS and state whether a newer LTS is preferable.
  • Pin the KAS version and/or kas-container image tag.

For every repository/layer used, state:

  • repository URL or source,
  • branch/tag/commit compatible with the pinned Yocto LTS,
  • exact layer path if the repository contains multiple layers,
  • known compatibility caveats.

Cover at least:

  • poky
  • meta-openembedded
  • meta-raspberrypi
  • TI support layers: meta-ti, meta-ti-bsp, meta-ti-extras, or vendor BSP
  • any TQ/vendor BSP layer required for TQMa64xxL/STKa64xxL
  • meta-security
  • meta-tpm2 if applicable
  • meta-optee if applicable
  • meta-rauc
  • meta-swupdate
  • meta-mender

If a layer does not use the Yocto release codename as a branch, state the actual reference and mark uncertain compatibility as [VERIFY].

Never fabricate:

  • recipe names,
  • image names,
  • machine names,
  • layer branches,
  • boot artifacts,
  • signing tools,
  • TPM features,
  • SE050 features,
  • OTA integration details.

Workload and Scope Control: The plan must respect 8–10 hours of active learner time per week.

If the full scope cannot fit:

  • keep mandatory items mandatory,
  • mark secondary items as stretch goals,
  • state the trade-off explicitly,
  • do not silently drop capstone-critical items.

Priority order for scope reduction:

  1. Keep host/KAS/Yocto fundamentals.
  2. Keep TQMa64xxL Yocto boot/build bring-up.
  3. Keep secure boot/signing foundations.
  4. Keep RAUC signed A/B OTA.
  5. Keep capstone integration.
  6. Reduce second OTA implementation, advanced disk encryption, or RPi comparison labs to stretch/demo labs if necessary.

Revised Project Motto / Core Objective: “Security-hardened embedded Linux OS for TI AM64x/TQMa64xxL and Raspberry Pi comparison targets, with NVIDIA Jetson Orin as a written reference only. Built on Yocto · Managed with KAS · Secured by verified boot where supported · Protected by OP-TEE/TF-A where supported · Uses TPM2 where available · Updated via signed OTA with RAUC as the primary standardized solution.”

Task: Create a complete, structured, 16-week learning plan for designing, building, securing, and validating an embedded Linux OS using:

  • Yocto/OpenEmbedded
  • KAS and kas-container
  • TI K3/AM64x boot and secure boot concepts
  • OP-TEE where supported
  • TPM2 where supported
  • secure key management
  • RAUC signed A/B OTA updates
  • optional comparison with Mender and SWUpdate
  • practical labs and a capstone acceptance test

The plan must be realistic, safe, reproducible, and technically honest.

Output Strategy: Because the requested plan is large, produce the answer in stages.

First response must contain:

  1. Assumptions & Verification Register
  2. Pinned Yocto LTS, KAS version, and layer branches/tags/commits
  3. Master 16-week schedule table
  4. Module dependency graph in Mermaid syntax
  5. Module 0 in full
  6. A list of remaining modules to be expanded in subsequent responses

If the response would exceed output limits:

  • stop cleanly at a module boundary,
  • do not summarize or weaken later content just to fit,
  • say exactly: Continuation required for Module X.

When I ask to continue, provide the next module(s) in the same detailed format.

General Output Rules:

  • Use clear, professional, highly technical Markdown.
  • Use imperative lab instructions.
  • Avoid marketing language.
  • Prefer concrete verification over vague learning claims.
  • For every command, state where it runs:
    • Host
    • U-Boot console
    • Linux target console
    • QEMU monitor
    • TPM/swtpm environment
    • CI runner
  • Use consistent shell variables, for example:
    • ${HOST_WORKDIR}
    • ${KAS_WORKDIR}
    • ${TARGET_IP}
    • ${SERIAL_DEV}
    • ${TFTP_ROOT}
    • ${NFS_ROOT}
  • Define these variables in Module 0.
  • When exact output may vary, provide representative output and the verification command/pattern that proves success.
  • Mark uncertain exact strings as [VERIFY].

Required Initial Deliverables:

1. Assumptions & Verification Register

Provide a table:

ID Topic Assumption Evidence/Reason Status How to verify

Use status values:

  • Confirmed
  • [VERIFY]
  • Blocked

Include assumptions for:

  • Yocto LTS release
  • KAS version
  • container runtime
  • Ubuntu version
  • TQMa64xxL BSP source
  • TI secure boot tooling access
  • SE050 support
  • TPM support on each board
  • OP-TEE support
  • R5F core availability
  • RAUC layer compatibility
  • OTA bootloader integration
  • disk encryption feasibility
  • measured boot feasibility

2. Master 16-Week Schedule Table

Use these columns:

Week Module Main Outcome Hardware Key Layers/Tools Deliverable Major Risk / [VERIFY]

The schedule must show:

  • module name,
  • practical outcome,
  • hardware used,
  • key tools/layers,
  • verifiable deliverable,
  • major technical risk.

3. Module Dependency Graph

Provide a dependency graph in Mermaid syntax.

Include at least:

  • Host setup
  • Yocto fundamentals
  • KAS
  • board bring-up
  • secure keys
  • secure boot
  • OP-TEE
  • TPM2
  • R5F/remoteproc
  • OTA
  • hardening
  • capstone

Required Module Structure: For every module, provide:

  1. Module title
  2. Mapped week(s)
  3. Learning objectives using measurable verbs
  4. Prerequisite checklist
  5. Hardware used
  6. Key tools/layers with pinned branches/tags/commits
  7. Practical lab assignments
  8. Definition of Done
  9. Checkpoint questions: 5–10 conceptual and hands-on questions
  10. Known risks and [VERIFY] items

Module Requirements:

Module 0 — Host Environment Setup

Cover:

  • exact Ubuntu LTS version
  • bare metal vs VM vs WSL2 recommendation
  • host resource sizing:
    • CPU cores
    • RAM
    • disk space for build, downloads, sstate, container images
  • required packages
  • Git configuration
  • Docker or Podman installation
  • rootless container runtime configuration
  • user/group permissions, including dialout and container group
  • kas native install vs kas-container
  • pinned KAS version or container image
  • repo/Docker/sstate/download caching strategy
  • serial console access with picocom/minicom
  • TFTP/NFS boot server setup for the eval kit
  • variable definitions for later labs
  • basic QEMU sanity lab
  • backup/recovery expectations for removable media and boot configuration

Include a lab that proves:

  • container runtime works rootless,
  • KAS can initialize a minimal Yocto project,
  • a minimal image or SDK can be parsed/configured,
  • serial/TFTP/NFS tooling is functional where applicable.

Yocto Fundamentals Module

Cover:

  • bitbake concepts
  • layers
  • recipes
  • bbappend
  • machine
  • distro
  • image features
  • devtool basics if useful
  • build output inspection
  • sstate and downloads
  • common failure modes

Labs may use QEMU or Raspberry Pi 3B+ where appropriate. Do not use RPi 3B+ for secure boot claims.

Dedicated KAS Module

Do not confine KAS to Module 0. Include a dedicated KAS module covering:

  • kas vs pure bitbake workflow
  • kas YAML schema:
    • header
    • repos
    • layers
    • machine
    • distro
    • target
    • env
  • kas-container invocation
  • rootless Docker/Podman usage
  • multi-config/target builds
  • caching strategy
  • reproducible project layout
  • CI skeleton for GitHub Actions and GitLab CI
  • runner requirements for Yocto CI:
    • CPU/RAM/disk
    • self-hosted runner assumptions
    • artifact retention
    • sstate cache strategy

Every later module must use or extend the KAS project configuration.

For KAS labs:

  • maintain a cumulative project layout,
  • show only the KAS YAML diff or new sections per lab,
  • provide the consolidated KAS YAML at the end of each module,
  • include the exact kas build or kas-container command.

Board Bring-Up Module

Cover:

  • TQMa64xxL/STKa64xxL BSP verification
  • exact machine name or custom machine plan
  • required TI/TQ layers
  • boot media:
    • SD/eMMC where applicable
    • TFTP/NFS where useful
  • serial console access
  • boot artifact identification
  • device tree validation
  • basic Yocto image boot
  • RPi 5 comparison boot where useful

For TQMa64xxL:

  • identify the exact BSP source:
    • upstream meta-ti machine,
    • TQ/vendor BSP layer,
    • custom machine configuration,
    • or a combination.
  • state repository, branch/tag/commit, machine name, and required artifacts.
  • if exact support cannot be verified, mark [VERIFY] and provide:
    • closest supported TI AM64x machine,
    • plan for adding a TQMa64xxL machine,
    • files that must be created/modified.

Do not invent machine names or boot artifacts.

TI K3 / AM64x Boot Flow Module

Describe the actual boot flow for the pinned BSP and machine.

Cover:

  • ROM boot,
  • R5 SPL,
  • SYSFW/TI-SCI,
  • TF-A where applicable,
  • OP-TEE where applicable,
  • U-Boot proper,
  • Linux,
  • boot artifacts produced by the build.

Possible artifacts may include, but are not limited to:

  • tiboot3.bin
  • tispl.bin
  • u-boot.img
  • sysfw.itb
  • fitImage
  • bl31.bin
  • tee binaries
  • device tree blobs
  • U-Boot environment

If artifact names or loading order differ from typical K3 examples, state the actual BSP behavior and mark uncertain details [VERIFY].

Include:

  • boot flow diagram in text or Mermaid,
  • artifact mapping table,
  • boot log verification,
  • U-Boot environment inspection,
  • recovery considerations.

Security & Keys Module

This module must precede OTA labs.

Cover PKI fundamentals for embedded systems:

  • root CA
  • intermediate CA if useful
  • code signing keys
  • U-Boot fitImage keys
  • OP-TEE TA signing keys where applicable
  • RAUC keyring/bundle signing keys
  • key lifecycle:
    • generation
    • storage
    • rotation
    • revocation
    • backup
    • recovery
  • development keys vs production keys
  • secure key storage options:
    • TPM2 PKCS#11
    • SE050 vendor PKCS#11 where supported
    • OP-TEE trusted storage where applicable
    • offline/HSM/signing-host concepts

Important:

  • Distinguish clearly between TPM2, SE050, OP-TEE trusted storage, and plain file keys.
  • Do not assume SE050 supports TPM2 features.
  • Production private keys must not be stored in the normal build environment.
  • Build automation may use development keys, but production signing should be separated into an isolated signing flow.

Lab requirements:

  • generate a full development key hierarchy,
  • store keys with safe permissions,
  • integrate development signing into KAS/bitbake,
  • verify that unsigned or incorrectly signed artifacts are detected/rejected,
  • document how unsigned artifacts are prevented from being promoted.

TI K3 Secure Boot Deep-Dive Module

Cover TI K3 secure boot using only verified BSP/tooling information.

Include:

  • TI Secure Development Package where applicable,
  • key generation,
  • certificate/signing workflow,
  • signed boot artifacts,
  • authentication enforcement,
  • secure boot verification,
  • difference between development and fused enforcement,
  • recovery limitations.

If applicable, cover:

  • SRK hash,
  • eFuse programming,
  • HS device types,
  • ROM verification,
  • authenticated boot chain.

Safety requirements:

  • include explicit warnings,
  • require board designation,
  • require device-type verification,
  • require independent hash/key checks,
  • provide dry-run path,
  • provide go/no-go checklist.

Lab goal:

  • demonstrate that an unsigned or incorrectly signed image is rejected where supported,
  • or demonstrate the verified non-fused secure boot path and clearly explain the gap if fuse programming cannot be safely performed.

Mark any TI NDA, download-restricted, or vendor-only tooling as [VERIFY].

OP-TEE Module

Cover OP-TEE only where supported by the pinned BSP and target.

Include:

  • OP-TEE architecture basics,
  • secure world/normal world,
  • TA concepts,
  • TA signing,
  • secure storage,
  • integration with U-Boot/Linux where supported,
  • building a custom TA,
  • testing a custom TA.

For AM64x/TQMa64xxL:

  • verify OP-TEE support,
  • identify required layers,
  • identify machine/firmware requirements,
  • mark uncertain support as [VERIFY].

Lab requirement:

  • build and run at least one custom TA if supported.
  • if not supported, provide a written gap analysis and alternative demo target.

TPM2 Module

Cover TPM2 architecture and practical usage.

Include:

  • PCRs,
  • sealing,
  • unsealing,
  • attestation,
  • event log,
  • measured boot concepts,
  • tpm2-tools,
  • TPM2 PKCS#11,
  • TPM2 OpenSSL engine/provider where applicable,
  • discrete TPM vs fTPM vs swtpm.

Hardware mapping:

  • Raspberry Pi 5 with SLB9670 for physical TPM labs where supported.
  • QEMU + swtpm for repeatable scripting and CI-friendly labs.
  • TQMa64xxL only if a verified TPM2 implementation exists.
  • SE050 must not be treated as TPM2 unless verified.

Labs:

  1. QEMU + swtpm TPM2 basics.
  2. PCR read/extend/policy demonstration.
  3. Seal/unseal a secret to PCR state.
  4. TPM2 PKCS#11 demonstration where supported.
  5. Measured boot integration with U-Boot/TF-A where supported.
  6. If full disk encryption is feasible, demonstrate a TPM-bound unlock flow. If not feasible, demonstrate sealed-secret release and explain the gap.

For disk encryption:

  • if full LUKS/rootfs encryption with TPM unlock is not feasible on the target, provide a reduced but verifiable lab:
    • sealed secret,
    • encrypted data partition,
    • TPM2 key sealing/unsealing with explicit PCR policy,
    • or QEMU/swtpm equivalent.
  • clearly state what is missing for full disk encryption.
  • mark uncertain initramfs/cryptsetup/TPM token integration as [VERIFY].

R5F Coprocessor Module

Cover AM64x Cortex-R5F usage from Linux.

Include:

  • remoteproc,
  • RPMsg,
  • firmware loading from Linux,
  • Yocto recipe for R5F firmware,
  • toolchain requirements,
  • resource table where applicable,
  • debugging/basic validation.

Safety/accuracy requirement:

  • identify which R5F cores are available to Linux,
  • identify which cores are reserved by SYSFW, Device Manager, boot ROM, or board firmware,
  • do not attempt to load firmware on reserved cores,
  • mark core availability [VERIFY] if uncertain.

Lab requirement:

  • build an R5F firmware example in Yocto,
  • load it via remoteproc,
  • establish a simple RPMsg channel or equivalent verified communication path.

OTA Module

Compare three OTA systems, implement RAUC fully, and evaluate one alternative if feasible.

OTA Comparison

Provide a decision matrix for RAUC, Mender, and SWUpdate covering:

  • licensing,
  • atomicity/rollback,
  • update artifacts,
  • bootloader integration,
  • code signing and verification,
  • backend requirements,
  • D-Bus/integration API,
  • Yocto layer maturity for the pinned release,
  • suitability for TI K3 boot artifacts,
  • operational complexity,
  • production support maturity.

RAUC Mandatory Implementation

Implement RAUC A/B updates on the primary target where supported.

Include:

  • signed RAUC bundles,
  • keyring integration,
  • slot configuration,
  • U-Boot integration,
  • bootchooser/state handling,
  • rollback,
  • update status reporting,
  • update of relevant boot artifacts where supported.

For TI K3:

  • explicitly address how bootloaders and K3 boot artifacts are updated,
  • explain atomicity,
  • explain rollback,
  • explain limitations imposed by boot ROM/SPL flow,
  • mark uncertain integration points [VERIFY].

Secondary OTA Implementation

Choose Mender or SWUpdate as the secondary candidate.

  • If full implementation is feasible within the workload, implement it.
  • If full implementation would jeopardize the capstone, reduce it to a guided comparison/demo lab and justify the decision.

Standardize on RAUC for the capstone unless the comparison reveals a clearly stronger alternative for the TI K3/TQMa64xxL target. Any deviation must be explicitly justified.

Embedded Linux Hardening Module

Include a minimal hardening baseline, even if advanced hardening is out of scope.

Cover:

  • threat model summary,
  • read-only rootfs where practical,
  • least packages,
  • non-root services,
  • SSH hardening,
  • firewall basics,
  • kernel hardening options where appropriate,
  • secure file permissions,
  • update/signing trust boundary,
  • logging/audit options if feasible.

If deeper hardening such as SELinux/AppArmor, dm-verity, IMA/EVM, or full disk encryption is included, mark advanced parts as stretch or [VERIFY] where needed.

Per-Lab Format (mandatory for every lab): Every lab must include:

  1. Lab title
  2. Estimated time:
    • active learner time,
    • elapsed build/background time
  3. Hardware used
  4. Prerequisites
  5. Numbered steps with exact commands where deterministic
  6. Expected output at each critical step:
    • exact where stable,
    • representative pattern where variable,
    • [VERIFY] if uncertain
  7. Definition of Done:
    • concrete verification checklist,
    • commands to run,
    • expected pass/fail behavior
  8. Troubleshooting:
    • 2–3 scenarios,
    • root-cause hints,
    • not just symptoms
  9. KAS integration:
    • KAS command,
    • KAS YAML diff or new sections,
    • consolidated KAS YAML at module end if changed

Assessment: End each module with 5–10 checkpoint questions.

Mix:

  • conceptual questions,
  • hands-on verifiable checks,
  • troubleshooting questions,
  • “how would you prove this?” questions.

Capstone Project (Weeks 14–16): Deliver a capstone on the TQMa64xxL where supported.

The capstone must include:

  1. Yocto image built entirely via KAS.
  2. kas-container CI pipeline skeleton.
  3. Secure boot or verified boot demonstration:
    • on a designated development board,
    • using a verified key/hash workflow,
    • with explicit safety checkpoints if eFuse/SRK hash programming is used.
    • if fuse programming cannot be safely verified, provide a non-fused demonstration path and document the gap.
  4. OP-TEE running with at least one custom TA where supported.
  5. TPM2 demonstration:
    • measured boot and sealed-secret or disk-encryption demonstration using a verified TPM2 implementation,
    • discrete TPM, supported fTPM, or swtpm where appropriate,
    • do not assume SE050 provides TPM2 features.
  6. R5F coprocessor firmware loaded via remoteproc with RPMsg or equivalent verified communication, using only cores confirmed available to Linux.
  7. Signed RAUC A/B OTA:
    • signed bundles,
    • bootloader integration,
    • automatic rollback on failed boot.
  8. General hardening baseline applied to the capstone image.
  9. Capstone acceptance test:
    • numbered reviewer-executable test script,
    • positive tests,
    • negative tests.

Capstone negative tests must include:

  • unsigned image rejected where secure boot enforcement is supported,
  • tampered RAUC bundle rejected,
  • wrong key/rejected signature case fails safely,
  • forced failed update rolls back,
  • invalid boot slot handling is demonstrated.

If any capstone item cannot be achieved on the primary hardware, provide:

  • the closest feasible demonstration,
  • the exact missing dependency,
  • a [VERIFY] item,
  • and a remediation path.

Recovery and Risk Requirements: Include recovery procedures for physical boards.

Cover:

  • serial console recovery,
  • SD/eMMC/USB/TFTP recovery where available,
  • U-Boot environment backup/recovery,
  • key/hash recovery implications,
  • what becomes unrecoverable after eFuse/SRK hash programming,
  • safe recovery posture for labs.

Include a risk table for destructive operations:

| Operation | Risk | Mitigation | Recovery Possible? |

Cover at least:

  • fuse programming,
  • bootloader updates,
  • OTA updates,
  • partition layout changes,
  • TPM clearing/resealing,
  • key loss.

Honesty Constraints:

  • State per-board secure-boot limitations plainly.
  • Do not promise secure boot, measured boot, TF-A, OP-TEE, TPM2, fTPM, or sealed storage on a board unless the selected BSP/hardware supports it.
  • Distinguish upstream Yocto/meta-ti support from vendor BSP support, TI NDA tooling, or vendor extras.
  • Distinguish development/demo security from production security.
  • Distinguish active learner time from elapsed build time.
  • Mark uncertain details as [VERIFY].
  • When a requirement conflicts with hardware reality, state the conflict and provide the closest feasible alternative.
  • Do not invent machine names, device trees, boot artifacts, layer branches, recipe names, TPM features, SE050 features, or eFuse procedures.

Deliverables per Module: For each module, provide:

  • Learning Objectives
  • Prerequisite Checklist
  • Key Tools/Layers with pinned references
  • Hardware Used
  • Practical Lab Assignments
  • KAS configuration changes
  • Definition of Done
  • Checkpoint Questions
  • Risks and [VERIFY] items

Final Output Requirements: The first response must be clear, professional, highly technical Markdown and must include:

  1. Assumptions & Verification Register
  2. Pinned versions table
  3. Master 16-week schedule table
  4. Mermaid dependency graph
  5. Module 0 in full
  6. List of remaining modules

Then continue module-by-module when requested.

Do not weaken technical accuracy to fit the output. If uncertain, use [VERIFY].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment