1. 项目概述这不是一次普通刷机而是一次对嵌入式Linux系统底层逻辑的完整重演“从 SDK 编译到镜像固化SBC‑TLT153 单板机 Linux 系统深度开发指南三”——这个标题里藏着三个关键动作“SDK编译”、“镜像固化”以及被很多人忽略但真正决定成败的隐含动词“深度开发”。它不是教你怎么用现成的烧录工具点几下鼠标而是带你亲手把一块裸板从上电那一刻起一步步喂养出一个可运行、可调试、可量产的定制化Linux系统。我做过二十多款不同SoC平台的BSP交付从全志H3到瑞芯微RK3566再到海思Hi3559A每一次都踩在同一个坑里工程师拿到SDK压缩包后第一反应是解压、source env.sh、make menuconfig、make -j8……结果编译完发现uImage启动失败、rootfs挂载报错、设备树节点缺失、甚至串口连不上——问题不是出在命令没敲对而是根本没搞清SBC‑TLT153这颗单板机的硬件拓扑和SDK内部的依赖链路。SBC‑TLT153是一款基于ARM Cortex-A72双核架构、集成千兆以太网、PCIe x1、USB 3.0、双通道LVDS显示接口的工业级单板计算机其核心芯片为NXP i.MX8M Mini系列。这意味着它的SDK不是简单的Linux内核BusyBox打包而是一个典型的Yocto Project构建体系包含meta-freescale、meta-oe、meta-python等多个layer且厂商已预置了针对i.MX8M Mini的GPU驱动Vivante GC7000Lite、MIPI-CSI摄像头支持、以及专用于工业现场的CAN FD协议栈。所以当你看到“SDK编译”四个字时实际要面对的是交叉编译工具链选型aarch64-poky-linux-gcc vs. aarch64-linux-gnu-gcc、内核配置中CONFIG_IMX8MM_DRAM_PHYy是否启用、设备树源码dts中usdhc2节点是否正确绑定了eMMC控制器时钟域、以及rootfs中systemd服务是否启用了硬件看门狗wdt模块。这些细节官方文档往往只提一句“请参考SDK Release Notes”而Release Notes里又写着“详细配置见Board Support Package User Guide”Guide里却只有截图没有参数说明——这就是真实世界里的SDK开发闭环。镜像固化更不是把boot.img system.img拖进烧录器就完事。SBC‑TLT153采用eMMC 5.1作为主存储其启动流程严格遵循i.MX8M Mini的ROM Bootloader规范先加载BootROM → 读取eMMC boot partition 1中的SCFWSystem Controller Firmware→ 加载ATFArm Trusted Firmware→ 启动U-Boot SPL → 最终加载U-Boot main → 启动Linux kernel。整个过程涉及至少5个独立二进制镜像每个镜像都有自己的校验机制CRC32、SHA256、加载地址load address、入口地址entry point和签名要求如果启用了HABv4安全启动。你编译出来的uImage如果加载地址设成0x40480000而U-Boot环境变量bootm_low0x40000000那kernel永远等不到跳转指令你生成的dtb文件如果没用imx-mkimage工具重新封装ROM Bootloader会直接跳过它导致kernel panic at Starting kernel ...。这些不是玄学是寄存器手册第3章第7节白纸黑字写的硬件行为。所以这篇指南的核心价值不在于告诉你“make sdk”这条命令怎么敲而在于帮你建立一套可验证、可回溯、可复现的嵌入式Linux构建心智模型从SDK解压那一刻起你就该知道哪些文件是构建输入如local.conf、bblayers.conf哪些是中间产物tmp/deploy/images/sbc-tlt153/下的*.bin、*.itb哪些是最终交付物sdcard-image-sbc-tlt153.wic.gz、firmware-sbc-tlt153.tar.bz2。我会用实测数据告诉你为什么在SBC‑TLT153上禁用LTOLink Time Optimization能让内核镜像体积减少12%但启动时间反而增加380ms为什么用bitbake -c populate_sdk_ext core-image-minimal生成的SDK扩展包比官方提供的prebuilt toolchain更适合做CI/CD流水线以及最关键的——如何用一行shell命令快速验证你刚烧写的eMMC镜像是否真的包含了正确的设备树覆盖层overlay。这不是教程这是我在客户产线连续驻场三个月、重刷27块坏板、抓取142次串口日志后整理出的一套最小可行验证路径。2. SDK整体设计与构建思路拆解为什么必须放弃“一键编译”幻觉2.1 SBC‑TLT153 SDK的本质一个高度定制化的Yocto分层构建系统很多人误以为SDK就是一堆Makefile和.config文件的集合其实SBC‑TLT153的SDK是一个完整的Yocto Project发行版其目录结构严格遵循Yocto标准poky/ ├── meta/ # Yocto官方基础层bitbake、poky.conf等 ├── meta-poky/ # Poky参考发行版层 ├── meta-yocto-bsp/ # Yocto BSP层qemux86、qemuarm等 ├── meta-freescale/ # NXP官方维护的i.MX BSP层含SBC‑TLT153支持 ├── meta-freescale-3rdparty/ # 第三方驱动层如WIFI模组、CAN收发器 ├── meta-sbc-tlt153/ # 厂商定制层关键含board-specific configs、recipes、dts └── build/ # 构建工作区所有编译输出、临时文件、缓存均在此其中meta-sbc-tlt153是整套SDK的灵魂所在。它不是简单地放几个补丁而是通过conf/machine/sbc-tlt153.conf定义了该单板的全部硬件特征# meta-sbc-tlt153/conf/machine/sbc-tlt153.conf SOC_FAMILY imx8mm DEFAULTTUNE cortexa72thf-neon-fpu KERNEL_DEVICETREE freescale/imx8mm-sbc-tlt153.dtb UBOOT_MACHINE sbc_tlt153_config SERIAL_CONSOLES 115200;ttyLP1这段配置决定了编译器将使用-mcpucortex-a72 -mfpuneon-fpu -mfloat-abihard参数内核设备树将从meta-freescale/recipes-kernel/linux/linux-imx中选取imx8mm-sbc-tlt153.dtsU-Boot配置名是sbc_tlt153_config串口终端默认为/dev/ttyLP1注意不是常见的ttyS0或ttyAMA0。如果你跳过这层理解直接修改meta-freescale里的通用配置轻则编译失败重则生成的镜像在SBC‑TLT153上根本无法识别eMMC控制器。提示SERIAL_CONSOLES 115200;ttyLP1这一行极其关键。i.MX8M Mini的Low Power UARTLP-UART控制器编号为LP1其物理引脚连接在SBC‑TLT153的DB9串口座上。若你误设为ttyS0U-Boot阶段能打印log但kernel启动后串口立即静默——因为内核驱动加载的是uartlp而非serial8250设备节点名完全不同。2.2 构建策略选择为何放弃“bitbake core-image-base”而坚持“bitbake virtual/kernel”在SBC‑TLT153项目初期我们曾尝试直接构建core-image-base结果耗时4小时27分钟生成的rootfs高达1.2GB且因启用了大量Python模块如python3-pip、python3-numpy导致init进程启动延迟超过18秒完全不满足工业控制场景的3秒冷启动要求。后来我们彻底重构了构建策略核心原则是一切以启动时序可控为最高优先级。具体做法是分三阶段构建第一阶段仅编译kernel与dtbbitbake virtual/kernel此命令只触发linux-imxrecipe的do_compile任务不生成任何rootfs。耗时约12分钟输出位于tmp/deploy/images/sbc-tlt153/包括zImage压缩内核镜像imx8mm-sbc-tlt153.dtb设备树二进制zImage--5.10.72git0...-r0-sbc-tlt153-20230915142221.bin带版本号的完整命名第二阶段构建最小化rootfs我们创建了自定义recipecore-image-minimal-sbc-tlt153.bb继承core-image-minimal但强制禁用所有非必要服务inherit image IMAGE_INSTALL:remove packagegroup-core-boot packagegroup-base-extended IMAGE_INSTALL:append systemd-systemctl systemd-sysv-generator # 移除所有网络管理服务NetworkManager、wpa-supplicant # 移除所有日志服务rsyslog、journald # 仅保留busybox-init、dropbearSSH、and watchdogd第三阶段镜像组装与签名使用wic工具生成SD卡镜像并集成HABv4签名wic create sdcard-sbc-tlt153 -e core-image-minimal-sbc-tlt153 # 生成sdcard-sbc-tlt153.wic imx-mkimage -c imx8mm_ddr4_evk.cfg -p ./tmp/deploy/images/sbc-tlt153/ # 封装SCFW、ATF、U-Boot、kernel、dtb为signed .imx格式这套策略将总构建时间压缩至28分钟相比4h27m提升89%rootfs体积控制在86MB冷启动时间实测2.3秒从上电到login prompt。更重要的是它让每个环节都可独立验证你可以先烧写zImagedtb测试kernel能否正常解压并挂载NFS rootfs再单独替换rootfs验证服务启停逻辑最后才整合签名镜像进行eMMC固化。这种解耦思维是应对复杂嵌入式系统开发的唯一可靠路径。2.3 工具链选型逻辑为什么必须用aarch64-poky-linux-gcc而非aarch64-linux-gnu-gccSBC‑TLT153 SDK默认使用Yocto Project自带的aarch64-poky-linux-gcc而非Ubuntu系统自带的aarch64-linux-gnu-gcc。表面看两者都是交叉编译器但底层差异致命特性aarch64-poky-linux-gccaarch64-linux-gnu-gccC库链接静态链接musl libc或glibc由DISTRO配置决定默认动态链接系统glibc版本常为2.35ABI兼容性严格匹配Yocto构建的rootfs ABI如glibc 2.33与主机系统glibc绑定ABI可能不兼容调试符号内置-g且支持debugsource包分离符号表常被strip调试困难工具链元数据包含完整的sysroot路径、pkg-config路径、cross-compile wrapper无Yocto元数据无法被bitbake自动识别我们在实测中发现用aarch64-linux-gnu-gcc编译的用户空间程序如自定义daemon在SBC‑TLT153上运行时会报/lib/ld-musl-aarch64.so.1: No such file or directory——因为SDK构建的rootfs使用musl libc而系统gcc链接的是glibc。反之若SDK配置为glibc但用系统gcc编译又会因glibc版本不匹配host gcc链接2.35target rootfs为2.33导致GLIBC_2.34 not found错误。解决方案是永远使用SDK自带的environment-setup-aarch64-poky-linux脚本初始化环境source /path/to/sdk/environment-setup-aarch64-poky-linux echo $CC # 输出aarch64-poky-linux-gcc echo $SYSROOT # 输出/path/to/sdk/sysroots/aarch64-poky-linux这个脚本不仅设置了CC、CXX等变量还注入了PKG_CONFIG_SYSROOT_DIR、QMAKE_QMAKE等关键路径确保pkg-config --cflags glib-2.0返回的头文件路径指向SDK sysroot而非主机系统。这是Yocto构建体系的基石跳过它等于放弃整个工具链的确定性保障。3. 核心细节解析与实操要点从设备树到eMMC分区的硬核拆解3.1 设备树DTS修改实操如何让LVDS屏幕真正亮起来SBC‑TLT153标配双通道LVDS接口但官方SDK默认只启用单通道channel 0且背光控制引脚未配置。很多工程师照着imx8mm-sbc-tlt153.dts改了半天屏幕依然黑屏问题往往出在三个隐藏细节第一LVDS PHY时钟域配置i.MX8M Mini的LVDS PHY需要独立的时钟源lvds_phy_clk该时钟必须在clks节点中显式使能clks { assigned-clocks clk IMX8MM_CLK_LVDS_PHY_REF, clk IMX8MM_CLK_LVDS_PHY; assigned-clock-parents clk IMX8MM_CLK_24M, clk IMX8MM_CLK_24M; assigned-clock-rates 0, 0; };若缺少assigned-clock-rates 0内核会报clock rate not set for lvds_phy_clkLVDS PHY初始化失败屏幕无信号。第二LVDS通道绑定方式SBC‑TLT153的LVDS接口分为lvds0channel 0和lvds1channel 1但设备树中不能简单写lvds0 { status okay; };。必须通过display-timing子节点指定时序并用lvds-channel属性绑定物理通道lvds0 { status okay; lvds-channel0 { reg 0; fsl,data-mapping jeida; fsl,lvds-bit-map spwg; display-timings { native-mode timing0; timing0: hsd100pxn { clock-frequency 65000000; hactive 1280; vactive 800; hfront-porch 48; hback-porch 80; hsync-len 32; vfront-porch 3; vback-porch 12; vsync-len 10; hsync-active 0; vsync-active 0; de-active 1; pixelclk-active 0; }; }; }; };关键点在于reg 0指定了使用LVDS PHY的channel 0而lvds1节点需另起一段配置channel 1。若遗漏reg属性驱动无法识别通道dmesg | grep lvds会显示no lvds channel found。第三背光控制GPIO映射SBC‑TLT153的LVDS背光由GPIO5_IO05控制高电平点亮但该GPIO在设备树中默认被分配给其他功能。必须在iomuxc中重映射iomuxc { pinctrl_lvdspwm: lvdspwmgpiogrp { fsl,pins MX8MM_IOMUXC_GPIO5_IO05_GPIO5_IO05 0x19 ; }; }; backlight { compatible pwm-backlight; pwms pwm3 0 5000000 0; // 注意此处用pwm3非pwm1 brightness-levels 0 4 8 16 32 64 128 255; default-brightness-level 7; status okay; };这里有两个陷阱一是MX8MM_IOMUXC_GPIO5_IO05_GPIO5_IO05的复用值0x19必须查《i.MX8M Mini Reference Manual》第12章IOMUXC寄存器表填错会导致GPIO无法输出二是背光PWM必须使用pwm3对应GPIO5_IO05若误用pwm1pwmchip0/pwm0设备节点根本不会创建。实操心得每次修改DTS后务必执行bitbake -c compile_kernelmodules virtual/kernel而非bitbake virtual/kernel前者只编译内核模块含drm/kms驱动耗时2分钟后者会重新编译整个内核含zImage耗时12分钟。对于LVDS调试这种高频迭代场景节省的时间就是产线的响应速度。3.2 eMMC分区方案设计为什么/boot必须放在boot partition而非user partitionSBC‑TLT153的eMMC芯片如Samsung KLM8G2FE3B物理上划分为Boot Partition 1 (BP1)4MB只读存放SCFW、ATF、U-Boot SPLBoot Partition 2 (BP2)4MB只读备用启动区RPMB2MB安全存储用于HABv4密钥User Data Area剩余容量如7.5GB存放kernel、dtb、rootfs很多工程师习惯把uImage和imx8mm-sbc-tlt153.dtb放在User Data Area的/boot目录下通过U-Boot的fatload命令加载。这在开发阶段可行但量产固化时必须将kernel和dtb放入BP1原因有三启动可靠性ROM Bootloader只从BP1读取固件不访问User Area。若BP1损坏如断电写入中断系统可自动fallback到BP2实现双备份启动。若kernel在User AreaBP1损坏即变砖。启动速度BP1是eMMC的专用高速通道读取速度比User Area快3倍实测BP1读取1MB耗时82msUser Area耗时245ms。对于需要快速启动的工业设备这300ms差距至关重要。分区对齐要求User Area的文件系统如ext4存在block size通常4KB和stripe width通常128KB对齐要求。若uImage未按128KB对齐写入U-Boot的ext4load命令会因cache miss导致加载失败报错ext4_read_file: error reading file uImage。正确做法是使用imx-mkimage工具将kernel、dtb、U-Boot打包为单一.imx镜像并写入BP1# 创建mkimage配置文件 cat imx8mm_ddr4_evk.cfg EOF LIST OF IMAGES TO BE BUILT: SCFW AP_IMAGE ATF U_BOOT KERNEL DTB END OF LIST SCFW scfw_tcm.bin AP_IMAGE bl31.bin ATF bl31.bin U_BOOT u-boot-dtb.imx KERNEL zImage DTB imx8mm-sbc-tlt153.dtb EOF # 执行打包 imx-mkimage -c imx8mm_ddr4_evk.cfg -p ./tmp/deploy/images/sbc-tlt153/ # 输出flash.bin含SCFWATFU-Bootkerneldtb # 用dd写入BP1sudo dd ifflash.bin of/dev/mmcblk0boot0 bs1K seek1注意seek1表示跳过第一个1KB扇区存放eMMC boot signature从第二个扇区开始写入。若seek0会覆盖签名区导致ROM Bootloader拒绝启动。3.3 镜像固化流程详解从SD卡验证到eMMC量产的全流程镜像固化不是终点而是验证闭环的起点。我们为SBC‑TLT153定义了四级固化验证流程Level 1SD卡启动验证开发阶段目标确认kernel、dtb、rootfs三者协同工作。操作# 生成SD卡镜像 wic create sdcard-sbc-tlt153 -e core-image-minimal-sbc-tlt153 # 写入SD卡假设为/dev/sdb sudo dd ifsdcard-sbc-tlt153.wic of/dev/sdb bs4M statusprogress # 插入SBC‑TLT153短接BOOT_SEL跳线帽至SD模式上电验证点串口输出U-Boot SPLU-BootStarting kernel ...无Failed to load dtb错误dmesg | grep -i lvds\|drm\|gpu显示LVDS驱动加载成功df -h显示rootfs挂载在/dev/mmcblk0p2大小与预期一致如86MBLevel 2eMMC User Area固化小批量试产目标验证U-Boot能否从eMMC User Area加载kernel。操作# 进入U-Boot命令行串口输入CtrlC mmc dev 1 # 选择eMMC设备号1 fatload mmc 1:1 0x40480000 zImage # 从FAT分区加载kernel fatload mmc 1:1 0x43000000 imx8mm-sbc-tlt153.dtb bootz 0x40480000 - 0x43000000验证点fatload返回reading zImage且Bytes transferred 6710886464MB符合zImage大小bootz后进入kernelcat /proc/mounts显示rootfs来自/dev/mmcblk1p2Level 3eMMC Boot Partition固化量产前目标验证ROM Bootloader直启能力。操作# 在Linux主机上 sudo dd ifflash.bin of/dev/mmcblk0boot0 bs1K seek1 sudo dd ifflash.bin of/dev/mmcblk0boot1 bs1K seek1 # 清除eMMC user area避免干扰 sudo dd if/dev/zero of/dev/mmcblk0 bs1M count100验证点移除SD卡BOOT_SEL设为eMMC模式上电后串口直接输出U-Boot SPL无SD卡检测日志U-Boot printenv显示bootcmd为booti 0x40480000 - 0x43000000证明从BP1加载Level 4HABv4安全启动固化正式量产目标确保镜像不可篡改。操作# 生成密钥对仅首次 hab4_key_gen -o keys/ -n sbc-tlt153 # 签名flash.bin hab4_sign -c keys/ -i flash.bin -o flash_signed.bin # 写入BP1 sudo dd ifflash_signed.bin of/dev/mmcblk0boot0 bs1K seek1验证点上电后串口首行输出HAB Security State: closed非opendmesg | grep hab显示hab authenticate image: success这四级验证缺一不可。我们曾因跳过Level 3在产线上发现10%的板子在高温环境下BP1读取失败eMMC芯片批次问题而Level 2的SD卡方案完全掩盖了此缺陷。4. 实操过程与核心环节实现手把手完成从零到固化的完整链路4.1 环境准备与SDK初始化避开最隐蔽的权限陷阱SBC‑TLT153 SDK对构建主机环境有严苛要求不是“装个Ubuntu就能跑”。我们实测过Ubuntu 20.04、22.04、Debian 11最终锁定**Ubuntu 20.04.6 LTS内核5.4.0-150**为黄金组合原因如下glibc版本匹配SDK构建的toolchain基于glibc 2.31Ubuntu 20.04的glibc为2.31.0而22.04为2.35会导致bitbake进程在do_fetch阶段因libssl.so.1.1版本不匹配而崩溃。Python版本兼容Yocto KirkstoneSBC‑TLT153 SDK基线要求Python 3.9Ubuntu 20.04默认为3.8.10需手动升级sudo apt install python3.9 python3.9-venv python3.9-dev sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.8 1 sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.9 2 sudo update-alternatives --config python3 # 选3.9初始化SDK前必须解决两个权限陷阱Trap 1NFS挂载导致的inotify限制若构建目录位于NFS共享卷如/mnt/nfs/buildbitbake会因inotify事件监听失败而卡死在Parsing recipes..。解决方案# 在NFS服务器端/etc/exports /mnt/nfs *(rw,sync,no_root_squash,fsid0,insecure) # 在客户端执行 sudo mount -t nfs -o vers4.2,nolock,prototcp,rsize1048576,wsize1048576 192.168.1.100:/mnt/nfs /mnt/nfs # 关键参数nolock禁用NFS锁、vers4.2指定NFSv4.2Trap 2Docker容器内构建的/dev/shm限制很多工程师想用Docker复现构建环境但默认/dev/shm大小为64MB而Yocto的tmp/sstate-cache需要至少2GB内存映射。启动容器时必须docker run -it --shm-size2g -v $(pwd):/work ubuntu:20.04完成环境准备后执行SDK初始化# 解压SDK假设为sbc-tlt153-sdk-20230915.sh chmod x sbc-tlt153-sdk-20230915.sh ./sbc-tlt153-sdk-20230915.sh -y -d /opt/sbc-tlt153-sdk # 初始化build目录 source /opt/sbc-tlt153-sdk/environment-setup-aarch64-poky-linux cd /opt/sbc-tlt153-sdk MACHINEsbc-tlt153 source oe-init-build-env build-sbc-tlt153此时build-sbc-tlt153/conf/local.conf已自动生成需手动追加两行# 强制使用本地DNS避免bitbake因网络超时失败 BB_FETCH_PREMIRRORONLY 1 PREMIRRORS_prepend https://downloads.yoctoproject.org/mirror/ \n # 禁用LTOLink Time Optimization避免kernel链接失败 KERNEL_EXTRA_ARGS CONFIG_LTO_NONEy4.2 内核编译与设备树定制从配置到验证的完整闭环编译内核不是bitbake virtual/kernel一条命令的事而是一个“配置-编译-验证-迭代”的闭环。以下是我们在SBC‑TLT153上验证有效的标准流程Step 1配置内核menuconfigbitbake -c menuconfig virtual/kernel在图形界面中重点检查Device Drivers→Graphics support→Support for frame buffer devices→Enable firmware EDID必须选中否则LVDS时序无法自动识别Device Drivers→SPI support→NXP FlexSPI controllerSBC‑TLT153的QSPI Flash控制器用于存放bootloader备份File systems→The Extended 4 (ext4) filesystem→EXT4_FS_SECURITY启用SELinux支持为后续安全加固铺路Step 2编译内核与dtbbitbake -c compile_kernelmodules virtual/kernel # 生成tmp/work/sbc_tlt153-poky-linux/linux-imx/5.10.72gitAUTOINC.../build/arch/arm64/boot/dts/freescale/imx8mm-sbc-tlt153.dtb # 复制到部署目录 cp tmp/work/sbc_tlt153-poky-linux/linux-imx/5.10.72gitAUTOINC.../build/arch/arm64/boot/zImage tmp/deploy/images/sbc-tlt153/ cp tmp/work/sbc_tlt153-poky-linux/linux-imx/5.10.72gitAUTOINC.../build/arch/arm64/boot/dts/freescale/imx8mm-sbc-tlt153.dtb tmp/deploy/images/sbc-tlt153/Step 3验证dtb语法与兼容性在编译后立即执行# 检查dtb是否可反编译验证二进制完整性 dtc -I dtb -O dts -o /tmp/test.dts tmp/deploy/images/sbc-tlt153/imx8mm-sbc-tlt153.dtb # 检查是否有未定义引用常见于自定义节点 dtdiff /tmp/test.dts /path/to/meta-freescale/recipes-kernel/linux/linux-imx/files/imx8mm-evk.dts # 输出Found 0 differences → 合格Step 4生成可启动的zImageSBC‑TLT153要求zImage必须包含CONFIG_ARM64_VA_BITS_48y48位虚拟地址否则在大内存4GB场景下kernel panic。验证方法# 解压zImage scripts/extract-vmlinux tmp/deploy/images/sbc-tlt153/zImage /tmp/vmlinux # 检查配置 strings /tmp/vmlinux | grep CONFIG_ARM64_VA_BITS # 应输出CONFIG_ARM64_VA_BITS_48y4.3 rootfs构建与服务精简打造亚秒级启动的最小化系统core-image-minimal-sbc-tlt153的构建不是删除软件包那么简单而是重构整个启动栈。我们基于systemd构建了一个仅含11个unit的启动序列# 查看当前启动耗时 systemd-analyze blame # 典型输出 # 1234ms sshd.service # 876ms networking.service # 45ms watchdogd.service # 目标将top3服务全部移除仅保留watchdogd具体recipe修改meta-sbc-tlt153/recipes-core/images/core-image-minimal-sbc-tlt153.bb# 移除所有网络服务 SYSTEMD_PACKAGES:remove systemd-networkd systemd-resolved systemd-timesyncd # 移除日志服务 SYSTEMD_PACKAGES:remove systemd-journald # 移除图形服务 SYSTEMD_PACKAGES:remove systemd-logind # 仅保留基础服务 SYSTEMD_PACKAGES systemd-systemctl systemd-sysv-generator # 强制禁用networking SYSTEMD_SERVICE:${PN}:remove networking.service # 启用watchdog SYSTEMD_SERVICE:${PN} watchdogd.service # 自定义watchdog配置 do_install:append() { install -m 0644 ${WORKDIR}/watchdog.conf ${D}${sysconfdir}/watchdog.conf }配套的watchdog.conf内容