ARM架构与交叉编译全攻略：从指令集选型到镜像部署与故障排查

这几年，我发现一个特别有意思的现象：社区里关于“arm镜像下载”“arm交叉编译”“arm版某某软件”的求助帖越来越多，从嵌入式开发板到云服务器，从工控上位机到国产Linux桌面，几乎每个方向都有人卡在“ARM”这三个字母上。说到底，大家遇到的不是同一个具体问题，而是同一个底层课题——ARM处理器体系架构与软件编程。这篇博文想做的，就是把这件事彻底摊开讲明白：从指令集和内核该怎么选，到工具链怎么搭、交叉编译怎么配，再到镜像拿下来之后系统怎么装、软件栈怎么适配、跑挂了怎么排查。适合的目标读者很明确：刚接触ARM开发板的嵌入式初学者、准备把服务从x86迁到ARM架构的后端或运维同学、以及工控和自动化领域要给ARM平台做上位机软件的朋友。

1. 先搞清ARM体系架构：指令集、微架构与SoC三层怎么选

1.1 指令集与微架构：ARMv8与Cortex-A53到底什么关系

很多新手会把“ARM架构”“Cortex-A53”“RK3568”这几个概念混在一起，其实它们是三个完全不同的层级。最上层是指令集架构，也就是ARMv8-A、ARMv7-A这种，它规定了CPU能执行哪些指令、寄存器怎么排布、异常怎么处理，相当于一份“普通话规范”。中间层是微架构，也就是Cortex-A53、Cortex-A72这些具体的内核设计，它规定了指令被怎么流水线执行、缓存多大、乱序执行到什么程度，相当于“某个人的发音习惯和语速”。最底层才是SoC芯片，比如瑞芯微RK3568、全志H616这种，它在ARMCortex内核之外，还要集成GPU、NPU、PCIe控制器、以太网MAC等一堆外设，相当于一个完整的“社会人”。

为什么要先把这个层级掰扯清楚？因为后面所有的软件动作都是由它决定的。你想选编译器参数，得知道自己用的是ARMv7还是ARMv8；你想下载系统镜像，得区分AArch32还是AArch64；你想挑开发板，得知道Cortex-A系列是跑Linux的命，而Cortex-M系列更适合做裸机或RTOS。ARM的策略是只卖IP授权，不自己造芯片，所以你会看到全志、瑞芯微、晶晨这些厂商拿着同样的Cortex-A53内核做出千奇百怪的SoC，但它们的软件栈几乎可以通用——这就是ARM生态最厉害的地方。

还有一个极其容易混淆的点：ARMv8-A是个64位指令集，但它同时定义了AArch64（64位执行状态）和AArch32（32位执行状态）两套执行状态。这就导致你在下载镜像时会看到两个常见的32位架构名：armhf（硬浮点）和armel（软浮点），它们跑的都是32位ARM指令，但浮点参数传递方式完全不同，编译器也必须配套。而64位统一叫aarch64或arm64，基本不用纠结浮点ABI，因为AArch64天生就带硬浮点。搞清楚这一点，你下载镜像时就不容易点错了。

1.2 三大处理器系列Cortex-A/R/M：它们分别适合做什么

ARM把处理器内核按应用场景分成三条产品线，这条线能直接决定你整个项目从选型到编程的技术路线，我整理了一张对比表：

如果你的目标是“跑Linux + 部署服务”，那就认准Cortex-A系列准没错；如果你做的是电机控制这类硬实时任务，就要选Cortex-R或者高端Cortex-M，因为A系列虽然主频高，但Linux调度带来的不确定性在微秒级控制场景下是致命的；如果只是做个低功耗采集节点，Cortex-M0/M4配个RTOS是最稳妥的方案。A系列里也有讲究：A53是出了名的能效比之王，适合做IoT边缘网关；A72/A76侧重性能，适合跑计算密集任务。这些年还有一个趋势叫“大小核异构”，也就是big.LITTLE，把高性能大核和低功耗小核组合在一颗SoC里，Android手机和ARM服务器都在用，做嵌入式Linux时要注意任务绑核，不然调度器可能把小核和Gic中断搅在一起，延迟不稳定。

1.3 快速判断一台设备是ARM还是x86：三条命令一个设置

这个问题在Windows阵营尤其容易糊涂，因为很多笔记本用的是AMD的x86处理器，但任务管理器里显示的是“AMD Ryzen”，于是有人就以为“AMD架构”是跟“ARM架构”并列的东西。这里要澄清一个老误解：AMD64、x86_64、x64这三个词基本是一个意思，指的是x86指令集的64位扩展，Intel和AMD的CPU都在用。所以判断一台电脑是不是ARM，不是看品牌，而是看指令集。

Windows下最快的方法：右键“此电脑”→“属性”，看“系统类型”那里写的是“基于x64的处理器”还是“基于ARM的处理器”。更准确的做法是打开命令提示符，执行systeminfo，看“系统类型”和“处理器”字段；或者打开注册表编辑器，查看HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\Processor下面的PROCESSOR_ARCHITECTURE键值，ARM64设备会直接显示ARM64。Windows 11还有一个内建命令powershell "Get-ComputerInfo | select OsArchitecture"，输出ARM64或者X64一目了然。

Linux下就简单多了，终端里敲uname -m：x86_64说明是x86的64位，aarch64说明是ARM的64位，armv7l说明是32位ARM小端。另外lscpu也能看到Architecture字段，还顺便能看CPU型号和大小核拓扑。macOS用户更直接，Apple Silicon（M1/M2/M3/M4）就是arm64，Intel芯的Mac就是x86_64，终端执行uname -m同样有效。养成拿到设备先跑uname -m的习惯，能让你在下载工具链和镜像之前就避开一半的坑。

2. 交叉编译与工具链选型：从armcc 5.06到GCC的完整实操

2.1 为什么全网都在找ARM Compiler 5.06 update 7 (build 960)

如果你接触过Keil MDK开发STM32或一些老款嵌入式SoC，一定对ARM Compiler 5.06 update 7不陌生。这套ARM官方编译器（armcc）在很长一段时间里是Keil MDK默认的C/C++编译器，直到ARM Compiler 6（基于LLVM的armclang）出现之前，大量芯片厂商的固件库、旧工程模板和教程都是基于AC5写的。问题就出在这里：AC6虽然新，但编译器对于非标准C语法、内联汇编写法、ARM C语言扩展的兼容性有很大差异，把一个用AC5写的成熟工程切换到AC6，经常要编译过千个错误，改到怀疑人生。

于是大家心照不宣：不是AC6不好，是老项目的稳定性和可重复性比“编译器版本新”重要得多。AC5.06 update 7的build号就是960，这是AC5系列的最后几个维护版本之一，功能稳定、资料最多，所以它的搜索量长期居高不下。我用过几代编译器，总体感受是：新项目用AC6更合适，代码密度和编译速度都有优势，尤其在Cortex-M33/M55这种新内核上必须用AC6；但只要是维护老工程，就乖乖找AC5.06 update 7。两代编译器的主要差异我列在下面：

那么问题来了：已经装了新版Keil，怎么拿到AC5？其实AC5就藏在Keil MDK的安装目录里，路径一般是C:\Keil_v5\ARM\ARMCC，里面有bin\armcc.exe、include和lib全套。如果你用的是新版MDK，可能在安装器里默认没勾选ARMCC，需要在Keil官网的“Legacy Support”归档中找AC5的历史版本。安装完成后，在Keil工程的Options→Target→ARM Compiler中选择“Use latest installed version”或者显式指定“ARM Compiler 5.06 update 7 (build 960)”即可。注意License的问题：Keil的许可对ARM（MDK）和C51（8051）是分开的，License Management里需要分别添加对应机型的license，否则编译器会被限制在16KB代码上限。老话一句话总结：老项目锁死AC5，新项目才考虑AC6，版本越新不一定越好用。

2.2 GNU交叉编译工具链：arm-none-eabi与aarch64-linux-gnu怎么选

除了ARM官方编译器，GNU工具链是嵌入式Linux和裸机开发的主力。搞懂工具链命名规则，你就不会选错了：工具链名字是“架构-厂商-操作系统-ABI”四段式。arm-none-eabi表示目标是ARM架构、没有具体厂商、没有操作系统（裸机）、使用EABI接口——它适用于Cortex-M单片机这类跑裸机或RTOS的场景；arm-linux-gnueabihf表示目标是ARM架构、Linux系统、GNU C库、hf硬浮点——它适用于32位ARM Linux（比如树莓派早期的Raspbian）上的应用编译；aarch64-linux-gnu就是64位ARM Linux的标准选择。

这里有一个被问烂了的技术点：“ARM None的工具链默认使用newlibc吗？”答案是肯定的。arm-none-eabi-gcc默认集成的是newlib——一个面向嵌入式系统设计的轻量级C标准库，它不依赖Linux内核提供POSIX接口，适合裸机和RTOS。如果你要极致压缩Flash占用，还可以通过--specs=nano.specs切换到newlib-nano，printf这类格式化输出会精简许多，代价是浮点打印等高级格式支持变弱。而arm-linux-gnueabihf和aarch64-linux-gnu工具链默认用的是glibc，功能完整但体积大、对libc版本敏感。所以，你在开发板上部署二进制时，必须保证编译工具链的glibc版本不高于目标系统的glibc版本，否则就会碰到version GLIBC_2.34 not found这类经典报错。

工具链的获取方式我建议三条腿走路：一是直接用发行版软件源，Debian/Ubuntu执行apt install gcc-aarch64-linux-gnu，CentOS/麒麟执行yum install gcc-aarch64-linux-gnu，这是最省事的方式；二是离线安装，下载对应架构的deb或rpm包后本地安装，适合没有外网的生产环境，注意要把依赖包一起下载全；三是拷贝一台已装好工具链的机器上的/usr/bin/aarch64-*和/usr/aarch64-linux-gnu目录，配合环境变量PATH直接使用。我个人的习惯是优先用发行版自带工具链，因为它和目标系统的libc版本最容易对齐。

2.3 CMake交叉编译一个真实工程并部署到开发板

下面演示一个完整的ARM交叉编译流程，目标平台是aarch64 Linux开发板，开发机是x86_64的Ubuntu。先准备一个最简单的工程：main.c里打印一行“Hello ARM, from aarch64!”，然后写工具链文件toolchain-aarch64.cmake：

set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++) set(CMAKE_FIND_ROOT_PATH /usr/aarch64-linux-gnu) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

CMAKE_FIND_ROOT_PATH指向目标系统的根文件系统前缀，这很关键：交叉编译时，CMake查找依赖库和头文件必须限定在目标系统的根目录里，而不是开发机的/usr/include。MODE_PROGRAM NEVER表示查找可执行程序时仍用开发机的工具，MODE_LIBRARY和MODE_INCLUDE则强制限定到目标根目录。然后执行：

cmake -B build -DCMAKE_TOOLCHAIN_FILE=toolchain-aarch64.cmake cmake --build build file build/hello

file命令的输出会明确告诉你：ELF 64-bit LSB executable, ARM aarch64，这就说明交叉编译成功了。我踩过的坑有三次：第一次编译出的二进制在开发板上直接Illegal instruction，原因是-march指定的架构级别比目标CPU高，例如用-march=armv8.2-a编译，但板子CPU只有armv8.0；解决方案是去掉手工-march参数，让交叉编译器按目标CPU的默认值生成。第二次是32位ARM的硬浮点/软浮点不匹配，链接阶段报undefined reference to __aeabi_d2ulz这类符号缺失，本质是浮点ABI不一致，补齐-mfloat-abi=hard且工具链和目标系统都是armhf才能解决。第三次是程序在开发板上./hello: not found，用ldd hello一看才发现动态库路径不对，需要把依赖的.so库同步到开发板。

部署到开发板的推荐方式有三种：网络文件系统挂载（开发板NFS挂载开发机目录，改完代码直接运行，适合调试）、scp直接拷贝（scp build/hello root@开发板IP:/root/，适合小文件）、或者打包根文件系统烧录（适合量产）。调试阶段建议先串口登录开发板，跑uname -a确认内核架构，然后用strace追踪程序行为，实在不行再加-g编译用GDB远程调试。交叉编译本身不难，难的是把工具链、浮点ABI、动态库这“三件套”全对齐，所以我强烈建议新项目从一开始就用带C库的工具链，而不是裸机工具链编Linux程序，不然会多出一堆坑。

3. 系统镜像与运行环境搭建：ARM设备跑Linux和容器的全套方案

3.1 镜像格式与虚拟机：img/qcow2/rootfs应该怎么选

关于“arm镜像下载”，很多人问的第一个问题是镜像格式到底有什么区别。img是原始磁盘镜像格式，一个文件对应一整块磁盘的内容，适合直接写入物理介质，比如SD卡、eMMC或U盘。qcow2是QEMU虚拟化平台的动态磁盘格式，它按需分配空间、支持快照，适合在虚拟机里跑系统，云平台里的ARM虚拟机镜像也大量用它。还有rootfs.tar.gz这种根文件系统打包格式，它不是完整磁盘镜像，只是基础文件系统的压缩包，通常要先挂载或解压到分区里再配合引导程序使用。下载镜像之前先想想你的目标环境：物理开发板就用img，QEMU虚拟机里就用qcow2，自己手工做Linux系统就用rootfs。

物理板子烧录命令也很固定，以Linux主机为例：

zcat debian-arm64.img.gz | sudo dd of=/dev/sdX bs=4M status=progress sync

写完后用parted -l检查分区表是否正常，再把SD卡插到开发板启动。如果你是Android平台上用limbo这类QEMU模拟器玩Debian ARM，README里说得很清楚：下载精简的Debian ARM镜像（img或qcow2都行），在模拟器配置里选择ARM架构的CPU模型，然后启动即可。这种玩法本质上是在手机上用软件模拟出一个ARM虚拟机，性能会打折，但用来跑轻量服务或做个行走的实验环境绰绰有余。

再回答一个到处被问的高频问题：“VMware Workstation能不能安装ARM架构的虚拟机？x86的Win10虚拟机里能不能装ARM版麒麟系统？”答案很干脆：VMware Workstation的CPU虚拟化依赖VT-x/AMD-V，只能虚拟x86架构的客户机，不支持ARM guest。想虚拟ARM系统，要么用QEMU（qemu-system-aarch64+ 指定Machvirt机型），要么用macOS上的UTM，或者干脆去云平台上开一个ARM实例——后者的性能和体验最接近真机，因为用的是真实ARM服务器，而不是模拟。

3.2 ARM Linux常见软件栈适配：JDK、Docker、数据库、QT与离线包

系统装好之后，真正的战场才开始。我这里按“后端服务常见软件栈”的顺序讲一遍ARM适配情况。

首先是JDK。下载JDK 11的ARM版时，一定要选aarch64架构，比如Temurin的Linux/aarch64包。装好后java -version会显示类似OpenJDK 64-Bit Server VM的字样。如果你不小心下了x86_64的JDK在ARM Linux上执行，会直接得到cannot execute binary file: Exec format error，这就是架构不匹配的经典报错。跑jar包就没什么特殊了，nohup java -jar app.jar --server.port=8080 &一样用，但注意确认你的JVM参数，有些调优参数在ARM JDK上的默认实现不同，比如-XX:+UseZGC在ARM64上可用，-XX:MaxRAMPercentage依赖容器内存配额，要配合cgroup设置。

其次是Docker与容器镜像。现在主流镜像仓库里大部分镜像都支持多架构（multi-arch），在ARM机器上执行docker pull nginx，Docker会通过manifest列表自动选择linux/arm64版本。老镜像如果只有amd64版本，你可以在x86构建机上用docker buildx build --platform linux/arm64重新构建一个ARM版，再把镜像推到仓库拉取到ARM机器上；强行在ARM机器上docker pull --platform linux/amd64虽然能拉下来，但docker run会报exec format error。中间件方面，MySQL、PostgreSQL、Redis、Mosquitto（MQTT）都有官方或社区维护的arm64镜像，直接用即可。Nacos从2.x开始官方提供arm64支持，2.5.0的docker镜像里能看到linux/arm64标记；老版本没有aarch64官方镜像，只能自己编译或用社区镜像。大原则就一句话：先看镜像的架构清单，再看软件版本，架构不匹配就别硬拉。

然后是QT环境。在国产ARM Linux（如麒麟系）下做上位机开发，QT的适配重点有二：一是ODBC数据库连接，需要装unixODBC和对应数据库的驱动，比如MySQL的libmyodbc，注意驱动必须也是aarch64的；QT代码里设置QSqlDatabase::addDatabase("QODBC")，DSN配置指向/etc/odbc.ini。二是中文字体，开发板上QT界面全是方块是千古难题，根因就是系统里没有中文字体，装上fonts-wqy-zenhei（文泉驿正黑）或fonts-wqy-microhei（文泉驿微米黑），然后执行fc-cache -fv刷新字体缓存即可。离线环境下载字体和依赖包时，记得用同架构的deb或rpm包，普通apt下载到~/deb再拷贝进内网。

最后提一下像dify这类AI应用平台是否支持ARM：结论是部分支持。官方文档会标注支持架构，但一些内置组件（比如部分向量数据库或推理依赖）可能只有x86二进制，需要自己在ARM平台单独编译或替换兼容组件。做这类事之前，我建议先跑一个uname -m确认架构，然后翻官方镜像清单，别问社群“能不能装”，直接看有没有linux/arm64标记最靠谱。

3.3 Windows on ARM与生态软件的arm版本真相

ARM平台跑Windows一直是热点，尤其是win11的ARM版本。Windows on ARM（WoA）本质是一个完整的Windows系统跑在ARM处理器上，它内置了x86和x64的指令翻译层，大量传统exe程序能直接运行，但运行效率和兼容性因软件而异：纯计算型应用表现尚可，涉及底层驱动、虚拟化、高强度IO的程序就容易出事。所以在ARM笔记本上，优先安装原生支持ARM64的软件，比如新版Edge浏览器、Office、Xshell都有对应的ARM64版本；Xshell官方也确实提供了aarch64的Linux版本，Windows on ARM上则可以直接装x64版靠模拟层运行。有一个冷知识是：小米平板2是Intel x86架构，刷win11其实是x86版，不是ARM版，别把它跟骁龙平板混为一谈。

还有一类“厂商生态工具”，比如某些电脑品牌的管理助手、手机互联程序，会单独发布ARM版本。这类工具在下载时一定要注意区分“x86模拟版”和“原生ARM版”，安装包名称里通常写着arm64或aarch64。在国产ARM桌面系统上做开发时，这是高频踩坑点：很多时候你从官网默认下载的是x86安装包，双击没反应或直接报Exec format error，去下载中心找“ARM架构适配版”就能解决。Windows上查看当前系统是不是ARM，也可以直接按前面说的注册表PROCESSOR_ARCHITECTURE看，显示ARM64就是WoA设备。

4. 常见场景问题排查：从开发板、边缘网关到工控上位机

4.1 嵌入式开发板：程序跑不起来的经典三连排查

客户现场反馈“程序跑不起来”，我一般会按这个顺序排查：先file确认二进制架构，再ldd检查动态库依赖，最后uname -m对比运行系统架构。这是嵌入式程序失败的最常见三连。有一次我编译了一个aarch64二进制，开发板也是aarch64，但file显示的是ARM aarch64，ldd报缺libstdc++.so.6，一看才发现工具链用的libstdc++版本比板子的系统库新，解决办法是静态链接C++标准库，或者把开发板系统升到匹配版本。还有一次程序在板子上报Segmentation fault，排查到最后是-march=armv8.2-a导致的指令集问题，换成板子支持的默认架构就正常了。

QT程序在开发板上的问题也很典型：界面全黑、界面字体方块、触摸无响应。全黑说明显示后端没配对，嵌入式Linux下常见的QT显示平台是linuxfb、eglfs或wayland，启动前要设置export QT_QPA_PLATFORM=linuxfb，还要保证/dev/fb0存在和权限正确；字体方块按前文说的装文泉驿字体；触摸无响应要看tslib或evdev插件的加载，很多情况下是设备节点没映射对。开发板上Debug我只说一句：能串口打印就别先上仿真器，printf和日志是最高效的手段，真到了必须单步跟踪的时候，再排查JTAG/SWD连接和GDB remote。

4.2 边缘网关与ARM+FPGA平台：实时性与电源管理要点

“arm/fpga边缘网关”“通信测试终端”这类需求这几年爆发式增长。为什么这种组合这么香？因为边缘网关要同时处理协议解析、数据采集、加密通信等多路任务，纯ARM核虽然灵活但实时性不够，纯FPGA开发成本又太高。常见做法是：Cortex-A系列处理器跑Linux，负责网络协议栈、应用逻辑和远程管理；FPGA负责硬实时IO、高速信号采集、自定义总线协议和硬件级过滤。两者之间用AXI总线或PCIe连接，Linux侧通过UIO（用户空间IO）或中断处理来与FPGA交互，数据的批量搬运走DMA，避免CPU拷来拷去。

实时性方面，如果你有毫秒级甚至微秒级的时序要求，建议给Linux内核打RT-Preempt补丁或使用带实时调度的发行版，同时把关键中断和线程绑在大核上，避免被小核拖后腿。电源管理是嵌入式产品量产绕不开的坎：ARM服务器的ACPI（包括suspend to RAM、电源状态通告等）在许多国产ARM服务器上已经支持得很好，但嵌入式设备更多依赖设备树（Device Tree）和内核电源管理框架。挂起到内存（suspend to RAM）的经典触发命令是echo mem > /sys/power/state，唤醒源通常来自GPIO、RTC或网络报文。如果你遇到“acpi sleep state suspend disabled”这种提示，排查顺序是：查UEFI/固件里睡眠状态是否被禁用、查内核配置里CONFIG_SUSPEND是否开启、再查具体驱动是否注册了唤醒源。很多工控现场直接禁用睡眠以保证可靠运行，这是正常设计，不只是软件问题。

4.3 工控上位机：PLC编程软件与LabVIEW多工位测试的设计思路

工控领域的问题更实在。ARM工控机（比如RK3588平台的Windows on ARM设备）能不能跑西门子TIA Portal、AB Studio 5000这类PLC编程软件？我的实测结论是：能装，能用，但别指望体验好。这些大型IDE是x86程序，在WoA的模拟层下可以启动，但编译下载、在线监控这些重IO操作会很慢，项目一大还可能崩溃。如果产线上非要跑这些软件，我建议要么用独立x86工控机跑，要么远程桌面到一台专门的Windows主机，省心得多。

关于“LabVIEW编程实现多个相同测试工位写在同一个软件”这个问题，很多做自动化测试的朋友都问过。我的建议是：不要一个工位一个上位机软件，而是做一个“多工位统一测试平台”，一个实例管N个工位。架构上采用生产者-消费者模式，每个工位对应一个独立的测试序列状态机（空闲→测试中→通过/失败），通过队列或全局变量池传递数据，UI层只做显示和交互，测试层只做逻辑。关键设计点有三条：一是每个工位的仪器资源要独立管理，用VISA会话句柄区分，避免串口/GPIB地址冲突；二是日志必须按工位分文件输出，两班倒的生产线上找数据时你就知道这个有多重要；三是异常处理要能单工位复位，一个工位挂了不能拖垮整个测试平台。这套思路不仅适用LabVIEW，任何上位机语言都通用。

4.4 高频问题速查表：ARM开发最常见的十个疑问

我把平时被问得最多的问题整理成一张速查表，覆盖“下载了不能用”“装了跑不起来”“不知道选哪个”这几类典型情况：

这里面第2、3、4、8条都是我在现场踩过坑后总结出来的，尤其是“Exec format error”这句报错，十个ARM新手九个会遇到，下次看到第一反应就该是：架构不匹配。

5. 一些长期实践后留下的习惯与技巧

坦白讲，我这些年折腾ARM的体会只有一句话：先确认架构，再谈优化。很多人被一个看似复杂的问题卡住，最后定位下来无非是工具链选错、镜像拉错、库版本不匹配、ABI不一致。只要每次动手前花十秒钟执行uname -m、file、ldd三条命令，你就已经比大多数人少踩一半的坑了。最后再分享一个小习惯：在任何开发板的BSP工程里，我习惯建一个env.sh文件，把交叉编译器的路径、目标架构、系统rootfs路径全部写进去，每次开新终端就source env.sh，这样整个团队的环境都保持统一，不会再有人因为编译器路径不一致而编出一个谁都不知道架构的二进制出来。ARM生态看着门类很多，但把体系架构、工具链、系统镜像、运行环境这条链理顺了，剩下的事情就是查表和举一反三。