Why Yocto?

The flash procedure needs Qualcomm-built firmware binaries (XBL, AOP, CDSP firmware, WPSS, firehose programmer, GPT tables). These blobs are publicly available — no build required.

Faster: make fetch-blobs downloads them directly in minutes. make yocto is the multi-hour alternative when a full BSP image is needed.

make yocto — full BSP (hours)

• Clones meta-qcom from GitHub
• Builds via kas using rb3gen2-core-kit.yml
• Produces core-image-base-rb3gen2-core-kit.rootfs.qcomflash/
• Flash targets auto-copy from this deploy dir

Use make fetch-blobs instead to skip the build entirely.

BL2/BL31/BL32 live in on-chip IMEM (0x1C00_0000); BL33 & FIP in DDR (0x9F80_0000+). Console UART @ 0x994000 (ttyMSM0).

The only three images built from source (everything else is a prebuilt Qualcomm blob):

• tz_a / tz_b ← tz.mbn — signed ELF/MBN (BL2)
• uefi_a / uefi_b ← uefi.elf — ELF-wrapped FIP (BL31+BL32+BL33)
• efi ← efi.bin — FAT32 image (UKI: kernel + DTB + initramfs)

• _a / _b — two slot copies of tz & uefi; same image in both
• efi is single (no A/B)
• flash-loader → tz + uefi (+ blobs)
• flash-efi → efi only

QTISECLIB (Qualcomm Technologies Inc. Security Library) is a prebuilt, closed-source static library (libqtisec.a) that Qualcomm's upstream TF-A platform port (plat/qti) links into BL31 — the EL3 secure monitor.

The open plat/qti C code is a thin shim that calls into qtiseclib through a fixed interface. The SoC-specific power-management, CPU and security sequences Qualcomm does not open-source live inside the blob.

• Not checked in — verify-qtiseclib fetches it on demand (a prereq of make tfa)
• SoC variant sc7280 — covers QCM6490 / RB3 Gen2 (Kryo 670)
• MD5-pinned & verified before it is used
• Passed to TF-A as QTISECLIB_PATH=, statically linked into BL31 → FIP

TF-A calls a small, fixed set of entry points; qtiseclib implements them:

• qtiseclib_bl31_platform_setup() — SoC EL3 bring-up at BL31 entry
• PSCI backend — CPU on/off/suspend, system off/reset, power-state validation
• CPU reset / warm-boot entry — secondary-core and resume paths
• Secure-interrupt dispatch — EL3 ISR for QTI secure IRQs
• Secure-memory assignment — access-control / carveout programming

• TF-A supplies the generic runtime — SMC dispatch, GIC framework, PSCI top-half, opteed SPD
• qtiseclib supplies the SoC bottom-half — the actual hardware sequences
• qtiseclib calls back into TF-A for console/log, mmap and locks (shared EL3 runtime)
• The monitor then dispatches to OP-TEE (BL32, opteed) and U-Boot (BL33)

• Select the PSCI backend by QTISECLIB_PATH — build with the native backend when the blob is absent
• Drop the platform banner requiring QTISECLIB — the dependency becomes optional
• Once the driver set is complete, plat/qcom links no libqtisec.a
• SoC-monitor functions only: PSCI/power, clocks, GIC, interconnect, sec_core, timers, watchdog, access control

• PAS / PIL — authenticate & bring up remoteproc firmware, now an OP-TEE PTA (qcom_pas, the path kodiak uses)
• Qualcomm platform enablement (Wildcat / Nord / Bruin)
• qcom crypto driver · software-key ICE PTA
• Video / Camera PAS (IRIS codec, Camera ICP)
• RPMB over UFS

• sec_core driver — secondary-core boot / PSCI bring-up #45576 · #45577
• qtimer driver — stub → real architected timer #45578 · #50251
• watchdog driver — stub → real driver #45581 · #50252
• interrupt dispatcher — extended for QTI secure IRQs #45580
• access control driver — native XPU / secure-memory (kodiak + qcs9075) #45583 · #51964 · #51963
• XPU bypass + mem_assign hardening; secure-region & PIMEM policy #46895 · #49087 · #50323 · #50565
• QTI maintainers & qtiseclib-coupling docs #45610 · #51968

• qcom_pas PTA — PAS/PIL firmware auth: ADSP, CDSP, Venus→IRIS; descriptor/ops refactor; early-TA
• clk: qcom — PAS clock driver + Lucid-EVO PLL helper
• PRNG driver · ramblur / pIMEM · GENI UART console
• RPMB over UFS — UFS probe, key provisioning by CID, RPMB reinit #7881
• Qualcomm MAINTAINERS & platform banner

OP-TEE is an open-source Trusted Execution Environment that runs in the Arm TrustZone Secure World (EL1-S). It hosts Trusted Applications (TAs) and handles Secure Monitor Calls (SMCs) from the Normal World.

Configuration

• Platform: qcom-kodiak
• Output: optee_os/out/arm/core/tee-raw.bin
• Passed to TF-A as: BL32

TF-A packs OP-TEE into the FIP image alongside U-Boot. At runtime, TF-A loads OP-TEE into Secure EL1 before handing off to U-Boot in Normal World EL2.

The Linux kernel communicates with OP-TEE via the tee-supplicant daemon and the CONFIG_OPTEE driver, both enabled in the kernel defconfig.

The TEE Client API library. User-space applications call it to open sessions with Trusted Applications and invoke commands across the Normal/Secure World boundary.

• TEEC_InitializeContext / TEEC_FinalizeContext
• TEEC_OpenSession — open a channel to a TA
• TEEC_InvokeCommand — call a TA entry point
• TEEC_CloseSession

Buildroot Package

• Package: optee_client_ext
• Init script: /etc/init.d/S30optee (auto-start)
• User tee — runs supplicant, owns /dev/teepriv0
• Group teeclnt — client apps; includes user test

Runs in Normal World as a privileged daemon. Acts as the bridge between the OP-TEE Secure World and REE filesystem / hardware resources.

• TA loading — reads /lib/optee_armtz/*.ta and passes TA binaries to the Secure World on demand
• Secure storage — mediates RPMB and REE-filesystem secure storage RPCs from OP-TEE OS
• Socket / time RPCs — handles other Secure World RPC calls that need REE access (entropy, sockets, time)

Without tee-supplicant running, TA loading and secure storage fail silently — always verify it is active before running xtest.

Build

• Defconfig: qcm6490_defconfig
• Output: u-boot/u-boot.bin
• Cross-compiler: aarch64-none-linux-gnu-
• Packed into FIP by TF-A as BL33

Why U-Boot?

U-Boot is configured in UEFI mode so the system presents a standard UEFI firmware interface, and the EFI partition is read using standard UEFI boot discovery.

• Reads the EFI system partition (FAT32 efi.bin)
• Falls back to EFI/BOOT/bootaa64.efi as the UEFI fallback path
• Discovers and launches EFI/Linux/uki.efi (the Unified Kernel Image)
• Hands kernel execution over at EL2 once the UKI is loaded

Build Config

• Defconfig: defconfig (overridable)
• Auto-enabled: CONFIG_TEE, CONFIG_OPTEE
• Auto-enabled: CONFIG_EFI_BOOT, CONFIG_EFI_ZBOOT
• Auto-enabled: CONFIG_DEVTMPFS, CONFIG_QCOM_WDT
• PAS/DSP built-in: QCOM_PAS_TEE, QCOM_Q6V5_PAS, QCOM_FASTRPC, RPMSG/GLINK
• Video: VIDEO_QCOM_VENUS=y, VIDEO_QCOM_IRIS=n
• CONFIG_MODULES=n — every driver built-in (RAM initramfs, no module autoload)
• Output: arch/arm64/boot/Image

Console

console=ttyMSM0,115200
qcom_scm.download_mode=1
earlycon

0001-...-el2-set-DSP-firmware-name.patch — EL2 device tree overlay: builds qcs6490-rb3gen2-el2.dtb, the variant needed when running at EL2 without the Gunyah hypervisor.

• Enables the Qualcomm watchdog
• Disables the GPU Zap shader (not needed at EL2)
• Remaps IOMMU streams for ADSP, CDSP, WPSS remoteprocs
• Overrides ADSP/CDSP firmware-name to qcom/qcm6490/ so the PAS driver finds the images
• Enables the Venus video codec (status + SMMU streams + video-firmware node)

0002-venus-support-pas-framework-over-op-tee.patch — loads and authenticates the Venus firmware through the PAS path over OP-TEE instead of QTEE/SCM.

• Selects OP-TEE via the /firmware/optee DT node (use_tz)
• Firmware brought up with qcom_mdt_load + qcom_pas_auth_and_reset
• Remote-state via qcom_pas_set_remote_state() (SCM fallback dropped)

• Gunyah (Type-1 hyp) owns EL2
• Linux (HLOS) runs as a guest VM at EL1
• Isolates VMs — stage-2 MMU, GIC virtualization
• Resource Manager creates VMs, brokers memory/IRQ
• PIL: hyp reassigns memory (HLOS→HYP→subsystem), delegates auth to QTEE

• Linux owns EL2 directly (Arm VHE)
• The hypervisor is KVM — open source, replacing Gunyah
• XBL config gives EL2 to the non-secure world (kvm variant, not gunyah)
• Guests still possible — hosted by KVM
• Firmware auth via OP-TEE PAS (qcom_pas), not hyp→QTEE
• During PIL, OP-TEE passes resource tables to Linux to set up the memory mappings Gunyah used to — possible now that Linux owns EL2
• Needs the -el2 DTB (patch 0001): watchdog, GPU-zap off, DSP/WPSS SMMU remap

What it covers

• Core TEE OS functionality (panics, memory, threads)
• GlobalPlatform TEE Internal Core API
• GlobalPlatform TEE Client API
• Cryptographic operations — AES, RSA, ECC, hash, ECDH
• Secure Storage — RPMB and REE-filesystem backends
• Regression suite and benchmarks

Buildroot Package

• Package: optee_test_ext
• Depends on: optee_client_ext, openssl
• TAs installed to: /lib/optee_armtz/
• Init: S30test-arm-ffa-user for ARM FF-A user tests
• Source: OP-TEE/optee_test.git (via manifest)

Connect via serial (ttyMSM0 115200) or SSH. Verify tee-supplicant is running before starting.

# Full test suite
xtest

# Regression tests only
xtest -t regression

# Single test case by number
xtest 1001

# List all test identifiers
xtest -l

# Help
xtest -h

Test results show OK / FAILED per case. A clean run ends with "RESULT: regression tests PASSED".

• qcs6490-rb3gen2 — base board DTB
• Source: upstream qcom DTS (OF_UPSTREAM)
• Appended to u-boot.bin (OF_SEPARATE)
• Multi-DTB FIT — one U-Boot image, many boards
• Board picked at runtime via SMEM (QCOM_FIT_MULTIDTB)

• qcs6490-rb3gen2-el2 — EL2 variant (kernel patch 0001)
• Built from the kernel tree
• Embedded in the UKI — .dtb section
• Delivered in the ESP (efi.bin)
• UKI stub installs it → kernel (EFI EFI_DTB)

Target Format

Buildroot produces a compressed CPIO archive (rootfs.cpio.gz), embedded directly into the UKI as an initramfs and loaded entirely into RAM at boot.

Built-in drivers (no modules)

The kernel is built with CONFIG_MODULES=n: the RAM initramfs has no module-autoload mechanism, so every driver on the boot / OP-TEE / DSP path is compiled in (=y). There is no kernel module overlay — only firmware and the DSP runtime are staged into kodiak/overlay/.

• Busybox (core utilities, watchdog support)
• OpenSSH server + key utilities
• OpenSSL CLI
• DHCPCD (networking)
• Ethtool, xinetd
• GStreamer 1.x + v4l-utils — V4L2 video decode pipeline

Login banner: "OP-TEE embedded distrib for kodiak"

One interactive runner at /usr/bin/qcom-tests; PASS/FAIL per step:

• ADSP FastRPC · CDSP FastRPC — OP-TEE PAS bring-up
• VIDEO — venus encode → decode round-trip
• CPU stress — soak (STRESS_SECS, stress-ng)

qcom-tests
Choice> 1 3    # space/comma list; blank = all

• xtest — OP-TEE regression suite (xtest [N])
• fastrpc_test -d 3 / -d 0 — CDSP / ADSP via OP-TEE PAS
• v4l2-ctl --list-devices — venus codec nodes
• gst-launch-1.0 — H.264 v4l2h264enc → v4l2h264dec

A passing FastRPC / video run means OP-TEE executed the PAS authenticate/reset correctly.