嵌入式这行的选型往往不是从“哪块芯片跑分高”开始的而是从一张接口清单和一张温宽表格开始的。前段时间接手一个工业现场的项目需求摊开来看不算复杂双千兆网口要做链路冗余两路CAN要接现场总线本地要一块7寸屏做参数配置整机要能在-20℃到70℃的环境里连续跑上几个月不重启最好还能跑个轻量容器方便远程升级。这一堆条件往桌上一摆能选的方案其实就剩下那么几款T536就是其中一个被反复提起的名字。它吸引我的地方不是参数表上那几个数字而是它背后那套相对完整的ARM开源生态——主线内核有支持、U-Boot能自己改、Buildroot和Yocto都能接得上这意味着后面遇到问题我不用干等着别人给补丁。这篇东西就是我围绕这块板子从选型、搭环境、改设备树、点外设到产品化收尾的一整套记录里面既有踩过的坑也有几条省时间的野路子。不管你是刚摸ARM开发板的新手还是已经在做工业网关、边缘计算盒子、充电桩主控的老手应该都能从里面抠出点能直接抄的东西。1. 先把需求翻译成硬件语言T536到底适合干什么1.1 从接口清单倒推芯片能力边界我一直觉得选型这事儿得反着来。先别急着看芯片手册拿张纸把项目里所有要接的东西列出来标上数量和速率再回头去套芯片这样效率高得多。拿这个项目举例清单大概是这样的两路千兆以太网其中一路要做环网冗余、两路CAN-FD500kbps/2Mbps数据段、一路RS485、一路MIPI-DSI接7寸1024×600屏、若干路GPIO做指示灯和按键、一路USB做本地维护口、一路SD卡槽做配置导入。把这些需求往T536身上套会发现它的资源配比刚好卡在一个比较舒服的位置四核Cortex-A55负责应用层和协议栈独立的RISC-V小核可以拿去做实时性要求高的任务两路GMAC原生支持CAN-FD也是原生外设而不是靠SPI转出来的显示接口给了MIPI-DSI和LVDS两条路。这里有个很关键的判断点很多人会忽略外设是原生的还是桥接的。就拿CAN来说市面上不少低成本方案是通过SPI外挂MCP2518FD这类控制器来实现的能用但代价是中断延迟不可控、高负载下容易丢帧、驱动还要额外维护一套。T536把CAN-FD做进了SoC内部走的是原生控制器加收发器的路子配合内核里的SocketCAN框架上层应用直接按网络设备的方式来操作省掉了一层转接的不确定性。这种差异在实验室里可能看不出来到了现场总线负载跑到70%以上的时候就会非常明显。再说网络。双GMAC在工业场景里几乎是刚需一路接现场设备网一路接管理网物理隔离比VLAN隔离可靠得多。T536的两路GMAC都是千兆能力实际能跑多少要看PHY选型和PCB走线但至少从SoC层面不会成为瓶颈。我在做需求映射的时候会把每个接口对应到具体的外设控制器编号上形成一张对照表后面写设备树的时候直接照着填能省掉大量来回翻手册的时间。项目需求T536对应资源实现方式需要额外确认的点双千兆网口2×GMAC原生MAC 外部PHYPHY型号、RGMII延迟、变压器选型两路CAN-FD2×CAN控制器原生 外部收发器收发器供电、终端电阻、共模电感7寸屏MIPI-DSI / LVDS原生显示通路屏参、背光升压、时序匹配本地维护USB 2.0原生OTG/HOSTID脚处理、供电限流配置导入SDIO / SPISD卡槽卡检测脚、上电时序实时任务RISC-V小核异构核核间通信机制、固件加载方式这张表看起来简单但它是我后面所有工作的索引。设备树里每一个节点、内核里每一个config选项都能回溯到这张表上的某一行。养成这个习惯之后你会发现调试效率有明显的提升——外设不工作时你不用满脑子乱猜直接按表逐行核对就行。1.2 开源生态这四个字含金量到底在哪“开源生态好”这句话被说烂了但它到底指什么很多人其实没想清楚。我的理解是分层的最底层是芯片能不能在Linux主线里找到支持中间层是U-Boot和各类构建系统有没有现成的板级配置最上层是社区里有没有人踩过你即将要踩的坑。先看最底层。T536这类ARM64平台能不能进主线内核直接决定了你后面几年维护的成本。进了主线意味着什么意味着内核升级的时候你不用把厂商补丁一个个往上搬意味着安全更新能跟着上游走意味着你遇到的bug别人大概率也遇到过。反过来如果只能靠厂商提供的私有内核树那每次升级都是体力活三五年之后这棵树跟上游分叉得面目全非谁接手谁头疼。所以在选型阶段我做的第一件事通常是去翻一翻这个平台在主线的支持程度看看设备树文件有没有、驱动覆盖到什么程度、最近的提交活跃不活跃。中间层就是构建系统。T536这边常见的有几条路厂商SDK自带的构建流程、Buildroot、Yocto还有社区维护的发行版适配。这几条路没有绝对的好坏关键在于你的团队熟悉哪一套、以及产品对可复现构建的要求有多高。小团队赶进度用厂商SDK改起来最快要做长期维护、要过审计、要给客户交付源码那Yocto或者至少是Buildroot更合适因为整个镜像的构成是可追溯的谁在什么时候加了哪个包一目了然。最上层其实是隐性的但价值巨大。举个例子你在设备树里改了一个时钟配置结果屏幕点不亮这时候如果社区里有人贴过类似的现象和解决思路你可能半小时就搞定了要是完全没人踩过你可能得拿示波器量一整天的MIPI时钟。生态的本质是别人已经替你付过的时间成本这句话我觉得比任何参数表都实在。1.3 异构核这件事别当成营销词看T536除了四个A55大核还带了一个RISC-V小核。刚开始我也觉得这就是个宣传点实际用起来才发现它在工业场景里挺有用。大核跑Linux任务调度、内存管理、网络协议栈这些东西都很成熟但Linux本身不是实时的——你写个中断处理从触发到用户态响应中间隔着调度器、中断下半部、可能有几十微秒到几毫秒的抖动。对于需要微秒级响应的场合这个抖动是不能接受的。小核跑裸机或者RTOS中断响应能做到确定性的几微秒。把电机控制环路、编码器采样、急停逻辑这类任务挪到小核上大核专心做业务逻辑和通信两边通过共享内存加中断的方式交换数据这个架构在实际项目里非常好用。代价是你要多维护一套固件、要设计一套可靠的核间通信协议、调试手段也要多准备一套。我一般会在项目早期就把这条边界划清楚哪些任务必须确定性、哪些任务可以接受Linux的调度抖动想明白了再动手比后期重构省事得多。这里还有一个容易忽略的细节小核的固件怎么加载。常见做法是打包进boot分区由U-Boot或者大核在启动阶段把固件搬到指定内存地址再把小核从复位状态放出来。这套流程一旦跑通就很省心但第一次配的时候很容易卡在内存地址冲突上——大核的保留内存区域和小核的代码段重叠了表现就是大核启动到一半莫名挂死串口只吐半行日志就没了。这类问题后面在排查章节我会详细说。2. 开发环境搭建从一台干净的机器到第一行串口日志2.1 主机侧环境与工具链的取舍主机环境这块我的建议很直接用Ubuntu LTS别折腾花活。不是别的发行版不行而是绝大多数SDK、交叉工具链、构建脚本都是在这个环境下验证过的你换个环境省下的那点心理满足感往往会被各种莫名其妙的依赖问题消耗掉。我自己的机器上长期留一个22.04的物理机或者虚拟机专门做嵌入式开发不装乱七八糟的东西减少变量。磁盘空间要提前规划。一个完整的SDK加上编译产物50GB起步如果同时保留多个构建目录和rootfs100GB也不嫌多。我第一次搞的时候只给了40GB编译到一半报“设备空间不足”清理了半天缓存才继续下去非常影响心情。建议单独挂一块盘或者分一个大分区给构建目录别跟系统盘挤在一起。依赖包的安装是第一步也是最容易被跳过的一步。很多人直接clone代码就开始编译结果报一堆“找不到头文件”“找不到工具”的错误。我的做法是先把常用依赖一次性装齐sudo apt update sudo apt install -y build-essential git curl wget \ bison flex texinfo libncurses5-dev libssl-dev \ python3 python3-pip python3-dev \ device-tree-compiler bc rsync cpio \ libelf-dev libyaml-dev swig \ u-boot-tools mtools dosfstools \ gcc-aarch64-linux-gnu g-aarch64-linux-gnu \ minicom picocom screen这里有几个包值得单独说一下。device-tree-compiler提供dtc没有它设备树编译直接失败而且版本太老会报一些奇怪的语法错误libssl-dev是内核签名和部分工具链需要的bc看起来无关紧要但内核编译的脚本里用到了它缺了会在编译后期报错非常浪费时间。至于交叉工具链用系统自带的gcc-aarch64-linux-gnu起步是最省事的跑通了再考虑换成厂商提供的工具链或者自己用crosstool-ng构建。工具链的选择上我的经验是先跟着SDK走跑通了再说优化。厂商SDK里通常会指定某个版本的工具链甚至直接打包在SDK里。一开始就换成自己熟悉的版本很容易遇到ABI不匹配、libc版本冲突这类问题而且因为你是“唯一一个这么干的人”出了问题也没人问。等整个流程跑通了、你对手册和代码都熟悉了再评估要不要换。2.2 SDK目录结构先看懂再动手拿到SDK之后别急着执行编译脚本。花半小时把目录结构摸清楚后面能省下好几个小时。典型的SDK结构大致是这样sdk/ ├── build/ # 构建脚本与配置 ├── device/ # 板级配置、分区表、环境变量 ├── kernel/ # 内核源码 ├── u-boot/ # 引导加载程序 ├── brandy/ # 早期固件与DDR初始化相关 ├── rootfs/ # 根文件系统骨架与预置文件 ├── external/ # 第三方包与应用 ├── out/ # 编译产物通常按板型分目录 └── tools/ # 打包、烧录、签名等工具device/这个目录最值得先看。里面通常有板级配置文件定义了用哪个设备树、内存大小、存储介质、分区布局。我接手一个新板子的时候第一件事就是把这里的配置和自己手上的硬件对一遍DDR容量对不对、eMMC还是NAND、串口用哪一个、默认启动介质是什么。这些信息错一个后面可能就是几个小时的黑屏排查。分区表也需要重点看。典型的布局大概长这样分区大小内容说明boot0/boot1各 1MB 左右引导固件由SoC ROM加载一般不随意改uboot2MBU-Boot 环境变量留点余量便于加功能boot64MB内核 设备树 小核固件内核带模块的话要放大rootfs A512MB根文件系统A支持双分区升级时用rootfs B512MB根文件系统B冗余备份data剩余应用数据独立挂载升级不动它分区大小的计算其实有讲究。boot分区的64MB不是拍脑袋来的一个典型的内核镜像Image格式大概20-30MB设备树几百KB小核固件几MB再加上几个备份和升级过程中的临时文件64MB是留了接近一倍余量的结果。如果你开了内核调试信息或者加了initramfs那得再往上加。rootfs的分区则取决于你要装多少东西我一般会先在开发板上把应用装齐用du -sh量一下实际占用再乘以2作为分区大小留出日志和临时文件的空间。2.3 编译、打包与第一次烧录配置确认完之后就可以编译了。大多数SDK的用法都差不多先选板型再选要构建的模块cd sdk source build/envsetup.sh lunch t536_industrial_board make kernel -j$(nproc) make rootfs -j$(nproc) make pack -j$(nproc)-j$(nproc)这个参数不是随便写的它等于CPU核心数。理论上并发数可以开到核心数的1.5倍左右但对内存的消耗也会上去8GB内存的机器开太多并发容易触发OOM反而更慢。我的经验是物理机上用核心数虚拟机上用核心数的一半比较稳妥。打包完成后会生成一个可以直接烧录的镜像文件。烧录方式取决于板子的启动介质常见的有几种用厂商提供的PC端工具通过USB走FEL模式烧录、通过SD卡启动后再写到eMMC、或者用网络TFTP加载。第一种最省事但依赖工具第二种最通用第三种在反复调试阶段效率最高。我个人的习惯是先做一张SD启动卡把系统跑起来确认没问题之后再从SD卡系统里把镜像写到eMMC。这样做的好处是砖了不心疼——eMMC写坏了还得想办法救SD卡拔出来重新做一个就行。制作启动卡的命令大致如下# 确认SD卡设备名千万别搞错写错盘会丢数据 lsblk sudo dd ifout/t536_industrial/images/sdcard.img of/dev/sdX bs4M statusprogress convfsync sync提示dd这条命令没有撤销键。执行前一定用lsblk确认设备名把U盘和SD卡区分清楚。我见过不止一次把系统盘写掉的案例代价是重装一下午。第一次上电串口是你的唯一信息来源。接线的时候注意三点TX接RX、RX接TX、GND必须共地。波特率一般是1152008N1无流控。我习惯用picocom退出方便picocom -b 115200 -d 8 -p n -y n /dev/ttyUSB0如果上电后一片空白先别怀疑板子坏了按这个顺序查串口线有没有接反、USB转串口模块的电压电平对不对有些模块是3.3V有些是5V、波特率有没有搞错、板子是不是根本没启动量一下各路电源和复位脚。这四步能解决九成以上的“串口没输出”问题。2.4 网络调试通道比串口好用得多串口能救命但日常开发光靠串口效率太低。系统起来之后第一件事就是把网络通道打通后面传文件、远程登录、跑测试都靠它。板子默认的IP配置一般在/etc/network/interfaces或者systemd-networkd的配置文件里。调试阶段我一般直接给个静态IP避免DHCP服务器不在的时候抓瞎# 临时配置重启失效 ip addr add 192.168.10.50/24 dev eth0 ip link set eth0 up ip route add default via 192.168.10.1 # 验证 ping -c 3 192.168.10.1主机这边对应配一个同网段的地址然后用scp传文件比串口传快几个数量级。如果板子上有sshd直接ssh登录配合tmux用起来跟本地终端没什么区别。传大文件的时候scp其实不是最快的它加密开销比较大。局域网内我一般用nc或者直接起个临时HTTP服务# 主机侧在文件所在目录执行 python3 -m http.server 8000 # 板子侧 wget http://192.168.10.100:8000/firmware.bin这个方法简单粗暴测固件、传镜像都好使。注意只在可信的局域网里这么干公网环境别这么玩。3. 开机流程拆解搞清楚每一步在干什么3.1 从按下电源到login提示符理解启动链条的价值在于出问题的时候你能快速定位到是哪一级挂的。T536这类ARM64 SoC的启动流程大致分四到五级。第一级是SoC内部的BootROM固化在芯片里改不了。上电后它根据几个引脚的电平决定从哪个介质加载下一级代码比如eMMC、SD卡、SPI NAND或者USB。这一级如果失败串口通常什么都不会输出因为串口还没初始化。判断方法就是看有没有任何输出——完全没有问题就在这一级或者更靠前的电源、时钟、复位。第二级是boot0这类一级引导固件负责DDR初始化和加载U-Boot。DDR初始化参数不对的话表现是串口吐出几行乱码然后停住或者干脆什么都不出。这块的调试手段比较有限通常靠厂商提供的工具做DDR压力测试确认参数没问题再往下走。第三级是U-Boot负责加载内核、设备树、可选的initramfs然后把控制权交给内核。U-Boot阶段能做的事情很多改启动参数、进命令行、通过TFTP加载镜像、做环境变量管理。这个阶段串口输出最丰富也是最容易插入调试手段的地方。第四级是内核从解压自身、初始化内存管理、探测设备、挂载根文件系统到启动第一个用户态进程。内核的log会打到串口上dmesg里能看到全部内容。这一步卡住通常表现为内核日志打到某个设备就停了这时候要看最后几行日志指向哪个驱动。第五级是用户态init进程拉起各种服务最后给你一个登录界面。这一级出问题通常是配置文件错误、服务依赖缺失、权限不对相对好查因为你有完整的shell可以用如果串口登录还能进的话。我把这套流程整理成一张排查表实际用起来很顺手现象最可能的阶段首要排查动作串口完全无输出BootROM / 电源 / 时钟量各路电源、查启动介质选择脚输出几行乱码后停住DDR初始化核对DDR参数、做压力测试停在U-Boot提示符不动启动参数 / 镜像加载检查bootargs、确认镜像存在内核日志中途停止驱动探测 / 根文件系统看最后几行日志定位驱动内核起来了但进不了shell用户态init检查init配置、挂载参数3.2 设备树改对这几处大部分外设就活了设备树是ARM Linux开发绕不过去的东西。它的本质是把“板子上有什么、怎么连的”从内核代码里剥离出来变成一个可以独立修改的数据文件。同一颗SoC可以对应无数种板子内核代码不用动只改设备树就行。T536的设备树文件通常在kernel/arch/arm64/boot/dts/下面分为SoC级的.dtsi和板级的.dts。SoC级的文件描述芯片内部有什么控制器、寄存器地址在哪、默认时钟和中断怎么连板级的文件描述这块具体的板子上哪些控制器被引出来了、接了什么外设、用哪个引脚。我改设备树的时候有个固定套路按顺序检查四项引脚复用、时钟、电源、中断。这四项任何一项不对外设就工作不了而且报错信息往往很含糊。引脚复用是最容易出问题的。同一个物理引脚可能身兼数职既能做UART又能做PWM还能做GPIO具体做哪个由复用寄存器决定。设备树里通过pinctrl节点来描述写法大致是这样pio { uart2_pins: uart2-pins { pins PG6, PG7; function uart2; drive-strength 10; bias-pull-up; }; }; uart2 { pinctrl-names default; pinctrl-0 uart2_pins; status okay; };这里status okay很关键SoC级的dtsi里绝大多数外设默认是disabled你要用哪个就得在板级文件里显式打开。我见过不少人改了半天驱动最后发现是设备树里压根没使能节点根本没被创建。时钟配置也经常出问题。有些外设需要外部晶振提供时钟源设备树里要指定clocks和clock-names配错了表现为外设能识别但速率不对或者干脆初始化超时。电源部分则涉及regulator节点尤其是屏幕、摄像头这类需要多路供电的外设供电顺序错了可能直接不工作甚至损坏器件。中断配置相对简单但要注意触发方式上升沿、下降沿、高电平、低电平和是否需要消抖。按键类输入如果没配消抖会看到大量重复中断。3.3 内核裁剪别一上来就删新手容易犯的一个错误是看到内核配置项成千上万就想着大刀阔斧地裁剪追求一个极小的镜像。我不建议在项目初期这么干原因很简单——你还不确定哪些功能是必须的删错了排查成本远高于省下来的那点空间。合理的顺序是先用默认配置或者厂商提供的defconfig把系统跑通确保所有外设都工作然后打开内核的运行时配置查看功能看看实际加载了哪些模块再基于实际使用情况做裁剪。内核配置里有一个很有用的选项能让你在运行时看到当前内核编译了哪些配置# 内核配置里打开 CONFIG_IKCONFIGy CONFIG_IKCONFIG_PROCy # 板子上查看 zcat /proc/config.gz | grep -i can裁剪的时候优先动这几类明显用不到的驱动比如你的板子没有PCIe设备那PCIe相关的可以关、调试符号和追踪框架量产版本关掉能省不少空间、用不到的文件系统只留ext4和vfat其他关掉。但要留神有些选项关了会有连锁反应比如关掉某个框架依赖它的驱动就编不过。所以每次裁剪完都要完整编译一遍并且上板验证别只看编译通过就完事。模块化也是一个选择。把不常用的驱动编成模块.ko需要的时候再加载既能减小内核体积又保留了灵活性。代价是根文件系统里要多放这些模块文件启动时可能要多花点时间加载。4. 外设实战一个一个点亮才踏实4.1 GPIO与中断最基础也最容易翻车GPIO看起来是最简单的外设实际上坑不少。先说要用的几个概念输入输出方向、电平高低、上下拉、驱动强度、中断触发方式。这些在设备树和用户态接口里都要配对。用户态操作GPIO现在推荐走字符设备接口gpiod老的sysfs接口虽然还能用但已经标记为过时# 查看有哪些GPIO控制器 gpiodetect # 查看某个控制器的引脚 gpioinfo gpiochip1 # 导出并设置为输出拉高 gpioset gpiochip1 121 # 读取输入 gpioget gpiochip1 15如果是写C程序用libgpiod更规范#include gpiod.h #include stdio.h int main(void) { struct gpiod_chip *chip; struct gpiod_line *line; int val; chip gpiod_chip_open_by_name(gpiochip1); if (!chip) { perror(open chip); return 1; } line gpiod_chip_get_line(chip, 12); if (!line) { perror(get line); gpiod_chip_close(chip); return 1; } if (gpiod_line_request_output(line, led, 0) 0) { perror(request output); gpiod_chip_close(chip); return 1; } for (int i 0; i 5; i) { gpiod_line_set_value(line, 1); usleep(200000); gpiod_line_set_value(line, 0); usleep(200000); } gpiod_line_release(line); gpiod_chip_close(chip); return 0; }编译的时候记得链接库gcc gpio_test.c -lgpiod -o gpio_test。中断这块我踩过最深的坑是按键抖动。机械按键按下和松开的瞬间会产生一串毛刺如果中断触发方式配成双边沿一次按键可能触发十几次中断。解决办法有两种硬件上并一个0.1uF电容做RC滤波软件上在驱动里做时间窗口过滤比如20ms内只认第一次。我一般两个都做硬件滤波降低中断频率软件过滤兜底。还有一个细节GPIO的中断号在不同的内核版本里可能变化写死中断号是很危险的做法。正确的做法是通过设备树里的interrupt-parent和interrupts属性让内核自动分配用户态则通过gpioinfo看实际值。4.2 双网口与CAN-FD工业场景的命脉网络配置这块两个网口分别命名是很重要的。默认情况下的命名规则可能会变eth0/eth1谁先谁后不确定导致你的脚本时好时坏。解决办法是用udev规则或者systemd的link文件按MAC地址或者PCI路径固定命名# /etc/systemd/network/10-eth-field.link [Match] Pathplatform-xxxx0000.ethernet [Link] Nameethfield这样命名之后配置文件里就可以放心地按名字来写不用管枚举顺序。CAN-FD的配置比传统CAN稍微复杂一点主要是数据段和仲裁段可以用不同的速率。配置命令大概是这样ip link set can0 down ip link set can0 type can \ bitrate 500000 \ dbitrate 2000000 \ fd on \ sample-point 0.875 \ dsample-point 0.8 \ restart-ms 100 ip link set can0 up这里面的参数需要算一下。采样点的计算公式是$$ 采样点 \frac{1 t_{seg1}}{1 t_{seg1} t_{seg2}} $$其中tseg1包含传播段和相位缓冲段1tseg2是相位缓冲段2。以500kbps、时钟80MHz为例一个位时间是160个时钟周期。取同步段1个tq、传播段相位缓冲1共139个tq、相位缓冲2共20个tq采样点就是(1139)/160 87.5%。数据段2Mbps时位时间只有40个时钟周期一般把采样点设到75%-80%留出足够的相位缓冲余量。实际调试时我建议先用candump把原始帧打出来确认收发链路通了再去做协议解析# 终端1监听 candump -ta can0 # 终端2发一帧测试 cansend can0 123#DEADBEEF如果发不出去或者收不到按这个顺序查收发器供电有没有、终端电阻对不对总线两端各120欧中间不要加、比特率两边是否一致、总线有没有对地短路。终端电阻这个事我遇到过好几次有人把120欧焊在了每个节点上总线挂了七八个节点等效阻抗变成十几欧信号直接垮掉。4.3 显示通路屏点亮那一刻才算真的开始显示这块是新人最容易卡住的地方。MIPI-DSI的调试涉及面板参数、时序、时钟、电源序列、背光任何一个不对屏幕都不亮而且现象往往都一样——黑屏。调试顺序我一般这么走先确认背光能亮这说明供电和背光升压没问题再看屏的复位信号时序对不对有些屏要求复位拉低至少10ms再拉高然后等120ms才能发初始化命令最后才去看数据通道。设备树里屏幕节点大致是这样dsi { status okay; panel0 { compatible vendor,panel-7inch-1024x600; reg 0; reset-gpios pio 8 12 GPIO_ACTIVE_LOW; backlight backlight; power-supply reg_lcd; display-timings { native-mode timing0; timing0: timing0 { clock-frequency 51200000; hactive 1024; vactive 600; hfront-porch 160; hback-porch 160; hsync-len 10; vfront-porch 12; vback-porch 23; vsync-len 1; hsync-active 0; vsync-active 0; de-active 1; pixelclk-active 0; }; }; }; };clock-frequency这个值要算一下像素时钟 水平总周期 × 垂直总周期 × 刷新率。上面这组参数水平总周期是102416016010 1354垂直总周期是60012231 636按60Hz算就是1354 × 636 × 60 ≈ 51.7MHz取51.2MHz是常见值。算出来偏差太大会导致画面偏移或者完全无显示。屏幕不亮的时候我有个笨但有效的办法先把数据通道和背光分开验证。拔掉背光用手电筒照屏幕如果能看到隐约的图像说明数据通了背光没通如果完全看不到说明数据没通。这一招能省掉一半的排查时间。4.4 异构核通信把实时任务安顿好前面提到小核的用途这里说说怎么用。核间通信的机制各家不太一样常见的有共享内存加中断、mailbox控制器、或者基于RPMessage的框架。不管用哪种核心思路都是大核和小核各自划一块内存作为通信缓冲区通过中断通知对方数据准备好了。内存保留这件事要在设备树里提前声明而且要在U-Boot阶段就把这块内存从Linux的可用内存里挖掉reserved-memory { #address-cells 2; #size-cells 2; ranges; rproc_buf: rproc-buffer4a000000 { reg 0x0 0x4a000000 0x0 0x00200000; no-map; }; }; rproc { memory-region rproc_buf; status okay; };no-map这个属性很重要它告诉内核这块内存不要建立页表映射避免内核的Cache回写把数据搞乱。0x4a000000这个地址不是随便填的得对着内存布局表确认它落在DRAM范围内、并且不和内核镜像、设备树、initramfs的加载地址重叠。我前面说的“大核启动到一半挂死”就是栽在这里——把小核的代码段划到了内核解压的地址上内核把自己解压过去的时候覆盖了小核代码然后两边一起完蛋。通信协议的设计上我一般用一个环形缓冲区加一个简单的头结构struct ipc_msg { uint32_t magic; /* 校验用防止读到脏数据 */ uint16_t type; /* 消息类型 */ uint16_t len; /* 数据长度 */ uint8_t payload[64]; uint32_t crc; /* 数据校验 */ };发送方写好数据后把magic置为约定值再触发中断接收方在中断里读magic对上了才处理。这个额外的校验步骤看起来多余但在调试阶段能帮你区分“数据没到”和“数据到了但解析错了”两种情况。5. 产品化收尾能跑和能交付是两回事5.1 根文件系统的选择开发阶段用什么rootfs都行产品阶段就得认真考虑了。常见的几条路Buildroot、Yocto、Debian/Ubuntu的ARM版本、以及自己从头搭。Buildroot的好处是简单直接make menuconfig选包编出来的镜像小依赖关系清晰。缺点是包管理能力弱加一个新软件可能要写一个新的package规则。适合软件包固定、追求镜像精简的产品。Yocto更重但更规范recipe机制让整个构建过程可追溯适合团队协作和长期维护。学习曲线陡一些构建一次环境要几个小时但一旦跑起来后面加包改配置都有章可循。Debian这类发行版胜在生态丰富apt装软件很方便适合需要频繁更新应用、对镜像大小不敏感的场景。代价是镜像大几百MB起步、启动慢、可定制的粒度粗。我自己的取舍标准是产品生命周期超过三年、有多个客户版本需要维护选Yocto做原型验证或者内部工具Buildroot需要跑大量第三方开源软件、对系统一致性要求不高用发行版。不管选哪条路有几件事是必须做的。把只读分区做出来根文件系统挂成只读运行时的数据写到独立的数据分区这样意外断电不会把系统搞坏。把日志管理做起来要么限制日志文件大小并定期滚动要么把日志写到独立分区。把时间同步配好工业设备对时间戳的要求通常很高没有可靠的时间源日志和故障记录的价值会大打折扣。5.2 启动时间优化从能用到好用客户对启动时间的要求往往比你想的苛刻。现场设备断电重启操作工等十秒和等三十秒的体验完全不同。优化的前提是先量化把每个阶段的耗时画出来。内核提供了initcall_debug参数可以打印每个初始化函数的耗时# 在bootargs里加上 initcall_debug printk.time1开机后看dmesg找出耗时最长的几项通常是存储控制器初始化、网络PHY协商、文件系统挂载。我做过的一个项目里光网络PHY自动协商就花了2秒多后来改成固定速率全双工之后省下来了。用户态这边用systemd的话可以这样看systemd-analyze systemd-analyze blame systemd-analyze critical-chainblame按耗时排序一眼就能看出哪个服务拖了后腿。常见的问题服务是各种等待网络的单元配置成Afternetwork-online.target之后会一直等到网络完全就绪。如果某个服务其实不需要网络把它改成network.target能省不少时间。我整理过一份优化前后的对比供参考阶段优化前优化后主要手段U-Boot2.1s0.8s去掉延时、精简环境变量加载内核3.4s1.9s裁剪驱动、并行探测、关闭调试输出网络就绪2.6s0.4s固定速率全双工、静态IP用户态服务4.2s1.5s精简服务、并行启动、延迟非关键服务合计12.3s4.6s—这张表里的数字不是标准答案每个项目都不一样但它说明了一个道理启动时间的优化空间通常比你想象的大而且大部分收益来自“去掉不必要的东西”而不是什么高深技巧。5.3 长期运行的可靠性设计工业设备现场没人给你重启的机会可靠性得在设计阶段就考虑进去。看门狗是底线。硬件看门狗要开着但喂狗的策略要设计好不能简单地在主循环里无脑喂。我的做法是让每个关键线程定期上报心跳主监控线程检查所有心跳都正常之后才喂狗。这样任何一个关键线程卡死整机就会在超时后自动重启而不是带着故障继续跑。硬件看门狗在Linux下的接口是/dev/watchdog配置超时时间# 查看当前超时 cat /sys/class/watchdog/watchdog0/timeout # 设置为60秒 echo 60 /sys/class/watchdog/watchdog0/timeout # 打开看门狗一旦打开不喂就会重启 echo 1 /dev/watchdog0注意最后一条命令打开之后就进入了“不喂就重启”的状态调试的时候要小心别在命令行里敲完就去干别的了。建议用systemd的RuntimeWatchdogSec配置来管理更规范一些# /etc/systemd/system.conf RuntimeWatchdogSec60 RebootWatchdogSec120双分区升级是另一个必备设计。升级过程最怕的就是断电单分区写到一半断电设备就变砖了。双分区的做法是系统跑在A分区升级时把新镜像写到B分区写完之后做校验校验通过才修改启动参数切到B分区。切过去之后如果新系统起不来看门狗超时重启时可以回退到A分区这需要U-Boot配合做启动次数计数。温度监控也不能少。工业设备的机箱内部温度可能比环境温度高十几度夏天户外机柜里轻松上到七十度。读取温度的接口# 典型路径具体看芯片 cat /sys/class/thermal/thermal_zone0/temp返回值一般是毫摄氏度除以1000就是摄氏度。我一般会在应用里设定两级阈值超过75度降频或者关掉非关键任务超过85度告警并记录日志。这些数据在售后分析的时候非常有用。6. 常见问题排查实录6.1 启动类问题速查启动类问题的排查我在第3节已经把框架搭好了这里补几个具体的案例和排查动作。现象串口完全没有输出电源指示灯正常。先量CPU的几路核心电压是不是在范围内再量复位脚是不是被拉住了。有些板子的复位电路里有个延时电容容量选大了会导致复位释放很慢。还有一种可能是启动介质选择引脚被拉错了比如配置成了从SPI启动但板子上根本没焊SPI Flash这种情况下BootROM会一直重试串口什么都不输出。用示波器看启动介质选择引脚的电平是最快的定位方法。现象U-Boot能起来但加载内核时报“Bad Magic Number”。这个错误的意思是镜像格式不对或者读取的位置不对。检查两件事镜像文件是不是真的在U-Boot要读的那个地址上、镜像有没有被正确打包有些SDK的镜像需要在前面加一个头部。还有一个低级但常见的错误改了内核但忘了重新打包烧进去的还是旧镜像。现象内核日志打到“Freeing unused kernel memory”就停住了。这说明内核已经起来了卡在找根文件系统或者执行init。检查bootargs里的root参数对不对、根文件系统的分区是不是真的存在、文件系统类型有没有写错。如果用的是initramfs检查initramfs有没有正确打包进镜像。现象进到initramfs的shell了但切不到真正的根文件系统。多半是root指定的设备名不对。/dev/mmcblk0p5和/dev/mmcblk1p5的区别在于用的是哪个控制器改硬件设计或者改设备树之后这个编号可能会变。用blkid看一下实际的分区UUID改用rootUUIDxxx会可靠得多。6.2 外设类问题速查外设不工作的时候我有一套固定的排查顺序设备树有没有使能 → 引脚复用对不对 → 时钟有没有 → 电源有没有 → 驱动有没有加载 → 上层接口对不对。按这个顺序走大部分问题能在十分钟内定位。症状可能原因排查命令或动作设备树节点不存在status未设为okay看/proc/device-tree下有没有对应节点节点在但驱动没加载内核配置没开lsmod、dmesg驱动加载了但初始化失败时钟或电源缺失dmesg里的错误码cat /sys/kernel/debug/clk/clk_summary初始化成功但无数据引脚复用不对查pinctrl配置、量引脚波形数据有但内容错误时序或电气问题示波器看信号完整性、检查上拉电阻举一个具体的例子。有一次CAN收发一直不通ip link能看到can0接口状态也是UP但就是收发不了任何帧。按上面的顺序查设备树节点在驱动加载了时钟也有。然后用万用表量CAN_H和CAN_L之间的电阻应该是60欧两个120欧并联结果量出来是无穷大——说明终端电阻没焊。补上电阻之后立马通了。这个案例说明电气层面的检查有时候比软件排查更直接别一上来就怀疑驱动。再举一个。屏幕背光亮了但画面全白看起来像是有信号但数据不对。查下来是MIPI-DSI的lane数量和实际硬件不匹配——设备树里配的是4 lane实际板子上只走了2 lane。改过来之后就正常了。这类问题在硬件改版之后特别容易出现软件配置没跟着更新。6.3 性能与功耗类问题CPU占用率异常高但找不到热点。先看是不是有进程在忙等死循环用top排序看一下。如果是内核态占用高用perf做个采样perf top -g如果是中断风暴/proc/interrupts里能看到某个中断的数量飞速增长。常见原因是某个GPIO中断没消抖或者某个外设的中断标志位没清导致中断一直被触发。系统运行一段时间之后变慢。先看内存free -h看可用内存和cache的占比如果可用内存持续下降可能有内存泄漏。再看存储eMMC的写入速度会随着使用时间下降特别是写放大严重的时候。用iostat看一下IO情况。还有一个容易忽略的原因日志文件写满了分区导致系统各种操作失败但又不报明显错误。功耗偏高。嵌入式设备的功耗主要来自几块CPU频率、DDR频率、外设供电、以太网PHY。调试阶段可以先看CPU频率是不是一直跑在最高档cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq如果项目对功耗有要求可以考虑在空闲时降频或者关掉不用的外设电源域。但要注意频繁的频率切换本身也有开销而且可能影响实时性得权衡。7. 几条踩过坑之后才明白的事写到这里技术细节说得差不多了最后分享几条我觉得比具体命令更有价值的东西。第一条先让它跑起来再让它跑得好。我见过太多人包括早期的我自己在项目一开始就追求完美的架构、最小的镜像、最优的性能结果两周过去了系统还没跑起来。正确的节奏是先跑通最小可用版本确认每个接口都能工作然后再一轮轮优化。优化的前提是有基准没有基准的优化都是瞎猜。第二条串口日志要留够但别刷屏。调试阶段把所有日志都打开是很爽但量产版本一定要把调试日志关掉或者降到最低级别。我遇到过因为日志级别没改量产设备运行三个月把eMMC写满导致批量故障的案例。日志是给你看的不是给Flash看的。第三条每个改动都要能回退。用git管理你的设备树、内核配置、构建脚本每次改动都提交。板上验证通过的版本打个tag。这样出问题的时候你能用git bisect快速定位而不是靠记忆猜“上周改的那个地方是不是有问题”。这一条看起来是常识但真正坚持做的人不多。第四条硬件问题用硬件工具查。软件排查有极限当你确认设备树、驱动、配置都没问题但外设就是不工作时拿起万用表和示波器。量电源、量时钟、量信号完整性。我排查过的问题里至少有三分之一最终是硬件原因——虚焊、漏焊、元件值不对、走线干扰。软件工程师学会看示波器能省下大量来回扯皮的时间。第五条把调试手段做进产品里。产品交付之后出了问题你不可能每次都跑到现场接串口。所以在设计阶段就要预留远程诊断能力日志上传、状态快照、关键寄存器的读取接口。这些东西在产品正常的时候看起来没用出问题的时候就是救命的。我一般会留一个诊断脚本能一键收集系统状态、最近的日志、关键外设的寄存器值打包成一个文件传回来。这个小工具帮我省下的差旅费远超开发它的时间成本。第六条文档是给自己写的。别指望半年后的自己还记得为什么在这个设备树节点里加了个奇怪的延时。改一处配置就顺手写一句为什么不要求格式能看懂就行。我现在翻两年前的项目笔记很多关键决策的原因都写在里面要是当时没记那些坑可能得再踩一遍。这套东西走下来从拿到板子到产品交付中间会经历无数次“咦怎么不工作”和“哦原来是这样”。这不是能力问题嵌入式开发本来就是在软件和硬件的交界处摸爬滚打任何一层的疏漏都会在另一层表现出来。把排查框架搭好、把工具用熟、把每一次踩坑的原因记下来下次遇到同类问题你的反应速度会快一个数量级。T536这套平台给我的感觉是它的开放性让这个过程可控——你能看到底层发生了什么能自己改能在社区里找到别人踩过的痕迹。这比一个封闭的、只能靠厂商支持的方案长期来看要省心得多。