DTB二进制流不能直接用fread读完就解析，必须先用fdt_check_header校验magic和version，再通过libfdt安全解析；需注意内存布局、字节序、对齐及压缩等ABI约束。
DTB二进制流不能直接用 fread 读完就解析
Linux内核启动时会把设备树编译成扁平化二进制格式（DTB），它不是普通二进制配置文件，而是有严格内存布局的自描述结构：开头是 magic（0xd00dfeed）、接着是 totalsize、off_dt_struct、off_dt_strings 等固定偏移字段。直接 fread 读取后若不校验 magic 和 version，后续解析极易崩溃或返回乱码。
实际使用中常见错误是跳过头部校验，直接按字符串或节点名硬解析 —— DTB 的 property 值可能未对齐、含嵌入 null 字节、甚至被压缩（如 fdt_header 中 boot_cpuid_phys 后紧跟未对齐的 struct fdt_property）。
- 务必先用
fdt_check_header验证 magic + version（标准 DTB version 是 17，但 U-Boot 传递的可能为 16 或 18） - 不要假设
totalsize就是文件长度 —— 内核可能在 initramfs 中截断或追加 padding - 若从
/proc/devicetree/读取（如/proc/devicetree/model），那是已展开的 sysfs 接口，和原始 DTB 无关；真正要解析 DTB 二进制流，得从 bootloader 传入的物理地址（如bootargs中的dtb=0x...）或 /sys/firmware/fdt（仅支持 UEFI+ACPI 混合平台的少数内核）获取
用 libfdt 而不是手写解析器
libfdt（libfdt.h）是内核源码树自带、被 dtc 和 u-boot 广泛使用的 C 库，C++ 可直接链接 -lfdt 使用。它屏蔽了 endianness 转换、offset 查找、string table 索引映射等细节。手写解析器不仅易出错，还难以兼容 future DTB spec 扩展（如 v19 新增的 fdt_reserve_entry 区域）。
典型流程是：fdt_open_into → fdt_check_header → fdt_first_subnode → fdt_getprop。注意 fdt_getprop 返回的是 raw bytes 指针，不带 null 终止 —— 若 property 是字符串（如 compatible），需手动确认结尾是否为
典型流程是：fdt_open_into → fdt_check_header → fdt_first_subnode → fdt_getprop。注意 fdt_getprop 返回的是 raw bytes 指针，不带 null 终止 —— 若 property 是字符串（如 compatible），需手动确认结尾是否为 \0，且可能存在多个 \0 分隔的字符串（如 "arm,pl330\0arm,primecell"）。
典型流程是：fdt_open_into → fdt_check_header → fdt_first_subnode → fdt_getprop。注意 fdt_getprop 返回的是 raw bytes 指针，不带 null 终止 —— 若 property 是字符串（如 compatible），需手动确认结尾是否为 \0，且可能存在多个 \0 分隔的字符串（如 "arm,pl330\0arm,primecell"）。
"arm,pl330<p>典型流程是：<code>fdt_open_into → fdt_check_header → fdt_first_subnode → fdt_getprop。注意 fdt_getprop 返回的是 raw bytes 指针，不带 null 终止 —— 若 property 是字符串（如 compatible），需手动确认结尾是否为 \0，且可能存在多个 \0 分隔的字符串（如 "arm,pl330\0arm,primecell"）。arm,primecell"）。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
立即学习“C++免费学习笔记（深入）”；
-
fdt_getprop_namelen更安全：可限定 name 长度，避免因节点名损坏导致越界读 - property 值若为 64-bit 地址（如
reg），必须用fdt64_to_cpu转换，不能直接*(uint64_t*)ptr - libfdt 默认不支持压缩 DTB（zDTB），若 bootloader 加载的是
dtb.gz，需先用 zlib 解压到 buffer，再传给fdt_open_into
从用户空间读取 DTB 的三个可行路径
内核不会把原始 DTB 直接暴露为文件，所以没有“标准路径”。能否读取取决于系统启动方式和内核配置：
-
/sys/firmware/fdt：仅当内核启用CONFIG_OF_EARLY_FLATTREE且运行在 UEFI 固件上时存在，大小与原始 DTB 一致，可mmap读取 -
/proc/sys/kernel/random/boot_id等路径毫无关系 —— 别被名字误导 - 最可靠方式是让 bootloader（如 U-Boot）把 DTB 地址和 size 通过 ATAG 或 device tree 自身的
/chosen/linux,initrd-start节点暴露出来，然后 C++ 程序用/dev/mem+mmap读取（需 root 权限 +CONFIG_STRICT_DEVMEM=n） - 若用 initramfs，可在构建时把 DTB 打包进去（如
cp arch/arm64/boot/dts/*.dtb /path/to/initramfs/），启动后从 ramdisk 读取 —— 这是最可控、无需 root 的方案
std::vector 加载后别直接传给 libfdt
libfdt 函数如 fdt_parse_full（非标准 API）或 fdt_open_into 要求 buffer 在整个生命周期内有效且不可移动。用 std::vector 存储 DTB 数据时，若后续调用了 push_back 或 resize，buffer 可能 realloc 导致指针失效 —— 而 libfdt 内部缓存了 offset 和 string table 指针，不会做二次拷贝。
- 安全做法：加载后调用
data = vec.data()，并确保vec生命周期长于所有 libfdt 调用 - 更稳妥：用
malloc分配 buffer，fdt_open_into支持 in-place 重定位，可避免额外拷贝 - 别用
std::string存 DTB —— 它的c_str()不保证包含 embedded null，且部分实现会在末尾隐式加 \0，破坏 DTB 校验和
model 字符串，也得走完整 header 校验、string table 索引、property length 解析三步。漏掉任意一环，程序可能在某款 SoC 上静默返回空值。 
