# OpenSBI copies our device tree into the kernel's .BTF section

2026-09-22. Found while reviewing the `every-blob-is-built-from-source-or-named`
reproduction of the vendor stage 1; proven on the running board.

## The chain, from the files that are actually on the card

U-Boot's `blinux` (`firmware/stage1/tdisplay.env`, identical to the SDK
`default.env`) loads the kernel Image to `0x200000`, our DTB to `0x8400000`,
the initrd to `0x9000000`, and OpenSBI's `fw_jump_add_uboot_head.bin` to
`0x8000000`, then runs `bootm 0x8000000 0x9000000 0x8400000`. The thing
`bootm` boots as "the kernel" is therefore OpenSBI: its legacy uImage header
reads load `0x0`, entry `0x0`, type kernel, name `linux`.

OpenSBI is built for the generic platform with `FW_TEXT_START=0`.
`platform/generic/objects.mk:35` then sets, unconditionally,

    FW_JUMP_FDT_ADDR = FW_TEXT_START + 0x2200000  ->  0x2200000

and `firmware/fw_jump.S:46-52` makes `fw_next_arg1` return that constant
instead of the `a1` U-Boot passed in. `firmware/fw_base.S:391-396`
(`_fdt_reloc_again`) copies the FDT there before jumping to the kernel at
`0x200000`.

`0x2200000` is 32 MiB into a 57 MiB kernel Image. From the running kernel's
System.map (`_start` = Image+0), Image+`0x2000000` is `__stop_notes+0x3875c`,
between `__start_BTF` (Image+`0x1fc78a4`) and `__stop_BTF` (Image+`0x30fef04`):
the `.BTF` section.

## Proof on the board

`/sys/kernel/btf/vmlinux` exposes that section from memory. If the copy
happens, the bytes `0x2000000 - 0x1fc78a4 = 0x3875c` into it must be a
flattened-device-tree header. They are:

    $ dd if=/sys/kernel/btf/vmlinux bs=1 skip=$((0x3875c)) count=16 | od -An -tx1
     d0 0d fe ed 00 01 24 a0 00 00 00 48 00 00 ff 98
                ^^^^^^^^^^^ totalsize 0x124a0 = 74912

74 912 bytes, not the 71 038 of `k230-tdisplay.dtb` on the card, because
`bootm` grows the FDT (chosen/bootargs, alignment) before handing it on.
The BTF blob itself is otherwise intact (magic `9f eb 01 00`, 18 052 704 bytes).

## Why the board boots anyway, and why that is luck

`.BTF` is never read during boot. It is consumed later, for eBPF CO-RE, via
`/sys/kernel/btf/vmlinux` -- and the only visible symptom is the line the
board has been printing every boot:

    Kernel module BTF mismatch detected, BTF debug info may be unavailable for some modules

That is exactly what a vmlinux BTF with 74 KB of device tree in the middle
of it produces. It has been dismissed as noise since the first boot.

The overwrite lands in `.BTF` only because this kernel's `.BTF` happens to
span Image+`0x1fc78a4`..`0x30fef04`. A kernel with smaller text or without
BTF puts `.data` or `.rodata` there instead, and the failure becomes a
crash in an unrelated subsystem with no connection to firmware. The vendor
shipped this layout; nothing in Canaan's SDK acknowledges it.

## The fix belongs in the from-source OpenSBI

Make `fw_next_arg1` pass `a1` through: build with `FW_JUMP_FDT_ADDR`
**undefined** at compile time, so `fw_jump.S` takes its `#else` branch
(`add a0, a1, zero`) and the FDT stays where `bootm` put it, which is
outside every image `bootm` knows about. Verification is a disassembly of
`fw_next_arg1` in the built `fw_jump.elf`, not a boot: the boot proves
nothing here, since it boots either way. A second check is the same `dd`
above returning BTF bytes rather than `d00dfeed` after the change lands.

This is scoped into `every-blob-is-built-from-source-or-named` as a task
because that change owns `nix/opensbi-k230.nix`; it is impossible to fix
against the vendor blob.