1. 项目概述为什么“DAY17-ARM 架构与交叉编译”不是一次普通的学习打卡“DAY17-ARM 架构与交叉编译”这个标题乍看像极了嵌入式学习营里某天的课程笔记编号——但如果你真把它当成一个孤立的知识点去记那大概率会在三天后面对一块刚焊好的开发板时对着串口终端里反复刷出的Segmentation fault发呆。我带过二十多期嵌入式实训最常听到的困惑不是“ARM是什么”而是“我明明在Ubuntu上编译成功了为什么烧进板子就跑不起来”、“Qt程序在PC上能运行一交叉编译就报错找不到libssl.so.1.1”、“aarch64-linux-gnu-gcc和arm-linux-gnueabihf-gcc到底该用哪个选错了会怎样”——这些问题全指向一个被严重低估的事实交叉编译不是“换个gcc命令”而是一整套软硬件协同的契约体系。ARM架构本身是这场契约的物理基石。它不像x86那样有统一的指令集生态而是分成了AArch32旧的32位ARMv7和AArch64现代64位ARMv8两大互不兼容的执行状态ABI应用二进制接口又细分为gnueabi软浮点、gnueabihf硬浮点、musl轻量C库等变体再加上内核版本、glibc版本、浮点单元VFP/NEON支持、大小端模式ARM默认小端但某些SoC可配置……这些参数一旦错配编译出来的二进制文件就像一张写错地址的快递单——代码逻辑再完美也永远无法抵达目标设备的内存里。你看到的arm-linux-gnueabihf这个工具链名其实是五个关键维度的压缩编码arm目标CPU架构、linux目标操作系统、gnueabihfGNU EABI 硬浮点缺一不可。而网络热词里反复出现的arm compiler 5.06u7、qt5.12.10交叉编译、nginx aarch64 移植本质上都是开发者在不同场景下被迫签署这份契约的具体案例。这篇文章不讲抽象理论只拆解真实项目中踩过的坑、算过的账、配过的参数——比如为什么ubuntu-20.04 安装 qt 交叉编译环境要先禁用systemd-resolved为什么llama.cpp 的 c 源码 arm架构编译时必须加-marcharmv8-acryptosimd为什么vmware 运行arm系统在2024年依然需要手动打补丁。如果你正准备给树莓派4B移植一个自定义内核或者要在国产RK3399上跑通PhantomJS的aarch64版本又或者正被arm 5编译器下载页面上那个“该版本未安装”的弹窗卡住——那么接下来的内容就是你跳过所有弯路的实操地图。2. ARM架构核心解析从指令集到SoC为什么你的代码在PC上能跑在板子上必崩2.1 AArch32 vs AArch64不是升级是彻底重写很多初学者误以为AArch64只是ARMv7的64位扩展就像x86-64之于x86。这是致命误解。ARM官方文档明确指出AArch64是一个全新的执行状态Execution State与AArch32完全隔离。这意味着寄存器完全不同AArch32有16个通用寄存器r0-r15其中r13/r14/r15分别固定为SP/LR/PC而AArch64有31个通用寄存器x0-x30x29/x30/x31分别对应FP/LR/SP且SP不再是通用寄存器必须用专用指令操作。指令集不兼容mov r0, #1AArch32在AArch64下语法错误正确写法是mov x0, #1更关键的是AArch64废除了条件执行如movne改用条件分支无条件指令组合这直接导致汇编层代码100%不可移植。异常模型重构AArch32有7种异常模式User、FIQ、IRQ等每种模式有独立SPSR和R13-R14AArch64只有4个异常级别EL0-EL3通过CurrentEL寄存器动态切换中断向量表结构也完全不同。提示当你看到aarch64-linux-gnu-gcc时“aarch64”明确锁定了目标为64位执行状态而arm-linux-gnueabihf-gcc中的“arm”默认指AArch32即ARMv7。混淆二者会导致链接器报错cannot link object files with different architectures——这不是警告是编译器在拒绝签署一份无效契约。2.2 ABI的三重枷锁EABI、HF、GNU少一个都运行不了ABIApplication Binary Interface是二进制层面的法律合同它规定了函数调用时参数如何传递、返回值如何获取、栈帧如何布局、浮点数如何处理。ARM Linux生态中最关键的ABI变体是gnueabihf我们逐层拆解gnu表示使用GNU C库glibc而非musl或uClibc。glibc功能全但体积大musl轻量但缺少部分POSIX扩展。ubuntu24交叉编译arm默认用glibc而centos7 arm镜像可能用musl混用会导致undefined symbol: __libc_start_main。eabiEmbedded Application Binary Interface专为嵌入式设计的ABI标准区别于桌面级的sysvABI。它强制要求栈对齐到8字节x86-64是16字节并定义了__aeabi_*系列浮点辅助函数。hfHard Float硬浮点。这是最易被忽视的致命点。ARMv7芯片如Cortex-A9普遍集成VFP浮点单元但编译器默认生成软浮点代码用整数指令模拟浮点运算性能损失达10倍以上。gnueabihf强制要求1浮点参数通过s0-s31寄存器传递而非堆栈2调用__aeabi_fadd等硬浮点函数3链接libgcc的硬浮点版本。若你在arm-linux-gnueabihf-gcc下编译却忘了加-mfloat-abihard生成的二进制会尝试调用软浮点函数而目标板的glibc只提供了硬浮点符号——结果就是symbol lookup error。实操心得我在调试RK3328板子时遇到过经典案例——Qt5.9.9交叉编译后程序启动报undefined symbol: __aeabi_uidivmod。查证发现Qt源码中qglobal.h默认启用-mfloat-abisoft而我们的工具链是gnueabihf。解决方案不是改Qt源码而是在configure时显式添加-mfloat-abihard -mfpuvfpv4并确保--sysroot指向的根文件系统包含硬浮点版libgcc.a。这个细节在Qt官方文档里藏得很深但却是90%新手卡住的第一道墙。2.3 SoC级差异为什么同一份代码在树莓派和全志H6上表现不同ARM架构只定义了CPU核心而实际产品是SoCSystem on Chip它把CPU、GPU、内存控制器、外设总线AMBA AXI/APB全部集成在一起。这就引入了第三层契约SoC特定的硬件抽象层HAL。以网络热词中的arm gpu csdn为例树莓派的VideoCore GPU和全志H6的Mali-G31 GPU驱动模型完全不同树莓派使用闭源的vc4驱动用户空间通过libbrcmEGL调用OpenGL ES 2.0 API需链接-lbrcmGLESv2全志H6使用开源的lima驱动依赖drm/kms内核模块OpenGL ES需链接-lGLESv2标准Khronos实现。这种差异直接反映在交叉编译上phantomjs aarch64下载的预编译包只能用于特定SoC因为其内置的WebGL后端已硬编码GPU驱动路径。若强行在RK3399上运行会因dlopen(libMali.so)失败而崩溃。更隐蔽的是内存管理——树莓派4B的BCM2711芯片采用ARM的SMMUSystem Memory Management Unit做IOMMU而瑞芯微RK3399用的是自研的IOMMU模块。这意味着DMA缓冲区映射的API调用方式不同arm halcon机器视觉库在移植时必须重写halcon/halconcpp/src/halconcpp/HDevEngine.cpp中的内存分配函数。注意arm soc体系结构这个词组背后是芯片厂商提供的《Technical Reference Manual》TRM和《Software Development Guide》SDG两本厚达千页的文档。我建议新手直接跳过TRM先精读SDG第3章“Boot Process”和第5章“Memory Layout”——这里定义了ATAGS或Device Tree的加载地址、initramfs的解压位置、以及最关键的kernel image入口点通常是0x00080000。很多Segmentation fault问题根源是交叉编译生成的zImage被烧录到了错误的Flash偏移地址。3. 交叉编译工具链深度剖析从arm-linux-gnueabihf到arm compiler 5.06u73.1 工具链组成不只是gcc而是一整套精密仪器一个完整的交叉编译工具链Toolchain包含至少7个核心组件它们像一条流水线上的7个工位缺一不可Binutils提供as汇编器、ld链接器、objdump反汇编、readelfELF分析等基础工具。它的版本必须与gcc严格匹配——binutils-2.38配合gcc-11.2是稳定组合若混用binutils-2.40ld可能无法识别gcc-11.2生成的.note.gnu.property段导致链接失败。GCC前端编译器负责将C/C代码转为汇编。关键参数-march目标架构、-mtune性能调优、-mfloat-abi浮点ABI必须与目标SoC手册一致。例如-marcharmv7-aneonvfpv4表示支持ARMv7-A指令集、NEON SIMD指令、VFPv4浮点单元。GlibcC标准库实现。交叉编译时必须用--sysroot指向目标平台的glibc头文件和库文件。ubuntu-20.04 安装 qt 交叉编译环境失败的常见原因是--sysroot路径错误导致#include sys/socket.h找不到。Linux Kernel Headers提供/usr/include/asm-generic等内核头文件。必须与目标板运行的内核版本一致。nginx aarch64 移植时若用5.15内核头文件编译却部署到5.4内核的板子上epoll_pwait等新系统调用会返回ENOSYS。GDB Server远程调试服务端arm-linux-gnueabihf-gdbserver运行在目标板上与PC端GDB通信。它必须与工具链gcc版本匹配否则断点位置错乱。CMake Toolchain FileCMake构建系统的桥梁文件定义CMAKE_SYSTEM_NAMELinux、CMAKE_SYSTEM_PROCESSORarm、CMAKE_C_COMPILERarm-linux-gnueabihf-gcc等变量。qt5.12.10交叉编译必须提供此文件否则CMake会调用主机gcc。Sysroot目标平台的完整文件系统镜像包含/lib、/usr/lib、/usr/include等目录。它是工具链的“法律依据”所有#include和-lxxx都以此为基准。实操心得我曾为llama.cpp 的 c 源码 arm架构编译耗时两天最终发现罪魁祸首是sysroot中libstdc.so.6的版本。主机Ubuntu 22.04的libstdc是11.3而目标板的glibc是2.33对应GCC 11.2版本不匹配导致std::string构造函数符号解析失败。解决方案是1从目标板/lib目录拷贝libstdc.so.6.0.29到sysroot/usr/lib2用patchelf --set-rpath $ORIGIN sysroot/usr/lib/libstdc.so.6修复运行时路径。这个操作在arm development studio图形界面里是自动的但命令行必须手动完成。3.2 主流工具链对比arm-linux-gnueabihfvsarm compiler 5.06u7vsaarch64-linux-gnu网络热词中高频出现的三类工具链适用场景截然不同工具链名称开发商核心优势典型场景关键限制arm-linux-gnueabihf-gccGNU免费开源、生态完善、社区支持强通用嵌入式开发如树莓派、i.MX6、Qt移植、Nginx移植生成代码体积较大对ARMv8.2新指令支持滞后arm compiler 5.06u7Arm Ltd针对ARM CPU深度优化、代码密度高、浮点性能强高实时性场景工业PLC、低功耗MCUCortex-M系列、arm 5编译器下载需求商业授权、不支持Linux用户态仅bare-metal/RTOSaarch64-linux-gnu-gccGNU原生支持AArch64、与主流Linux发行版同步更新64位ARM服务器如AWS Graviton、ubuntu24交叉编译arm、gem5在aarch64架构下运行spec2006对32位ARMv7兼容性差不能编译AArch32代码特别注意arm compiler 5.06u7Build 960这个版本它是Arm官方最后一代支持ARMv7的编译器但不支持Linux用户态应用编译。它的armlink链接器只生成裸机二进制*.axf没有ELF头无法被Linux内核加载。因此arm compiler 5.06u7 download后若试图编译nginx aarch64会报错error: L6218E: Undefined symbol __aeabi_memcpy——因为__aeabi_memcpy是glibc提供的而Arm Compiler 5只链接armcc自带的libarmlib。这个坑让很多从Keil MDK转过来的工程师栽了跟头。提示vmware安装ubuntu虚拟机选择arm架构在2024年仍属高难度操作。VMware Workstation Pro 17仅支持aarch64客户机且必须开启Virtualize Intel VT-x/EPT即使在ARM主机上。更可靠方案是用QEMUqemu-system-aarch64 -M virt -cpu cortex-a57,featurespmu -m 2G -kernel /path/to/Image -initrd /path/to/initramfs.cgz -append consolettyAMA0。这里-cpu cortex-a57必须与你的交叉编译-mcpucortex-a57严格一致否则cpuid检测失败。3.3 工具链构建实战手动生成arm-linux-gnueabihf的完整流程虽然网络上有现成的工具链下载如Linaro但理解构建过程才能精准排错。以下是基于crosstool-ng构建arm-linux-gnueabihf的实操步骤适配ubuntu-20.04环境准备安装依赖sudo apt-get install gawk bison flex texinfo help2man gperf gawk bison flex texinfo help2man gperf。注意help2man是必需的缺失会导致ct-ng生成文档失败。配置工具链ct-ng arm-linux-gnueabihf # 创建配置模板 ct-ng menuconfig # 进入图形配置在菜单中关键设置C Compiler → gcc version选11.2避免12.x的-Werrorstringop-truncation误报C-library → glibc version选2.33匹配Ubuntu 20.04内核C-library → Enable WCHAR support必须勾选否则Qt5.9.9交叉编译(openssl)的qstring.h会编译失败构建过程ct-ng build。此过程耗时约40分钟期间会自动下载binutils-2.37、gcc-11.2.0、glibc-2.33源码并编译。若中途失败查看build.log中最后一行错误——90%是wget下载超时需手动下载对应tar包放入~/.crosstool-ng/tarballs/。验证工具链# 测试编译最小hello.c echo int main(){return 0;} hello.c /opt/x-tools/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -o hello hello.c file hello # 应输出hello: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked注意arm-linux-gnueabihf-gcc生成的hello在x86主机上无法运行必须用qemu-arm-static测试sudo cp /usr/bin/qemu-arm-static sysroot/usr/bin/ chroot sysroot ./hello。若报错qemu: uncaught target signal 11 (Segmentation fault), 说明sysroot中ld-linux.so.3路径错误需用readelf -l hello | grep interpreter确认解释器路径并用patchelf --set-interpreter /lib/ld-linux-armhf.so.3 hello修复。4. 交叉编译全流程实操从Qt5.12.10到Nginx aarch64的完整迁移4.1 Qt5.12.10交叉编译解决OpenSSL依赖的硬核方案qt5.12.10交叉编译是嵌入式GUI开发的经典难题核心在于OpenSSL的交叉编译。网络热词qt5.9.9交叉编译(openssl)同样适用此方案编译OpenSSL for ARM# 下载OpenSSL 1.1.1wQt5.12.10兼容版本 wget https://www.openssl.org/source/openssl-1.1.1w.tar.gz tar -xzf openssl-1.1.1w.tar.gz cd openssl-1.1.1w # 配置交叉编译 ./Configure linux-armv4 \ --prefix/opt/qt-arm/openssl \ --openssldir/opt/qt-arm/openssl \ -marcharmv7-a \ -mfpuvfpv3 \ -mfloat-abihard \ --cross-compile-prefixarm-linux-gnueabihf- make -j$(nproc) sudo make install关键点linux-armv4是OpenSSL对ARMv7的配置名不是linux-aarch64--cross-compile-prefix必须带末尾短横线否则make会调用gcc而非arm-linux-gnueabihf-gcc。编译Qt5.12.10# 创建toolchain.cmake cat toolchain.cmake EOF set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g) set(CMAKE_FIND_ROOT_PATH /opt/qt-arm/sysroot;/opt/qt-arm/openssl) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) EOF # 配置Qt ./configure \ -xplatform linux-arm-gnueabihf-g \ -release \ -no-opengl \ -openssl-linked \ -I /opt/qt-arm/openssl/include \ -L /opt/qt-arm/openssl/lib \ -sysroot /opt/qt-arm/sysroot \ -prefix /opt/qt-arm/qt5.12.10 \ -device-option CROSS_COMPILEarm-linux-gnueabihf- \ -nomake examples -nomake tests make -j$(nproc) sudo make install实操心得-no-opengl是关键开关。若启用OpenGLQt会尝试链接libEGL.so和libGLESv2.so而这些库必须由SoC厂商提供如arm gpu csdn上下载的mali-bifrost-gpu-kernel-driver。对于无GPU的板子强行启用会导致libQt5Gui.so链接失败。我建议先用-no-opengl编译出基础Qt库再单独编译qtvirtualkeyboard等插件。4.2 Nginx aarch64移植处理动态链接的隐式依赖nginx aarch64 移植看似简单实则暗藏玄机。./configure --hostaarch64-linux-gnu后make成功但./objs/nginx -V却报错error while loading shared libraries: libpcre.so.1: cannot open shared object file。这是因为PC上libpcre.so.1在/usr/lib/x86_64-linux-gnu/而ARM板子在/usr/lib/nginx二进制中记录的RUNPATH是$ORIGIN/../lib但交叉编译时未指定--with-ld-opt-Wl,-rpath,/usr/lib。解决方案分三步交叉编译PCRE for ARM./configure \ --hostaarch64-linux-gnu \ --prefix/opt/nginx-arm/pcre \ --enable-utf8 \ --enable-unicode-properties make sudo make install配置Nginx./configure \ --hostaarch64-linux-gnu \ --prefix/usr/local/nginx \ --with-pcre/opt/nginx-arm/pcre \ --with-ld-opt-Wl,-rpath,/usr/lib \ --with-cc-opt-I/opt/nginx-arm/pcre/include修复运行时路径# 编译后检查 readelf -d ./objs/nginx | grep RUNPATH # 若显示$ORIGIN/../lib则用patchelf修正 patchelf --set-rpath /usr/lib:/usr/local/lib ./objs/nginx注意nginx aarch64的--with-openssl选项必须指向交叉编译的OpenSSL而非主机OpenSSL。否则./objs/nginx -V会显示OpenSSL 1.1.1f 31 Mar 2020主机版本但实际运行时调用的是板子上的libssl.so.1.1版本不匹配导致TLS握手失败。4.3 .so文件从x86迁移ARM符号重定位的生死线网络热词.so从x86迁移arm文件是典型误区。.so共享对象是平台相关二进制x86的.so在ARM上绝对无法加载哪怕用QEMU模拟也不行——因为ELF头中e_machine字段x86是EM_386ARM是EM_ARM不匹配内核load_elf_binary()会直接返回-ENOEXEC。正确迁移路径是源码 → ARM交叉编译 → 生成ARM.so。但这里有隐藏陷阱符号版本Symbol Versioning。例如libmysqlclient.so.21在x86上导出mysql_real_connectLIBMYSQL_1.0而在ARM上可能导出mysql_real_connectLIBMYSQL_1.1。若你的应用链接了x86版libmysqlclient.so.21然后替换为ARM版运行时会报undefined symbol: mysql_real_connectLIBMYSQL_1.0。解决方案是强制符号版本兼容# 编译ARM版MySQL客户端时 ./configure \ --hostarm-linux-gnueabihf \ --with-pic \ --without-server \ --enable-version-specific-runtime-libs \ CFLAGS-DMYSQL_SERVER_SUFFIXarm make sudo make install--enable-version-specific-runtime-libs确保生成的.so使用LIBMYSQL_1.0版本符号与x86版完全一致。提示mariadb arm客户端和mysql arm的二进制包通常已处理此问题但源码编译时必须显式配置。我曾为arm 5编译器下载的旧项目迁移MySQL最终在mysql-5.7.33/sql-common/client.c中找到#ifdef __arm__宏添加#define LIBMYSQL_VERSION 1.0才解决符号不匹配。5. 常见问题与排查技巧实录从Segmentation fault到symbol lookup error的终极指南5.1 经典问题速查表症状、原因、解决方案症状可能原因排查命令解决方案Segmentation fault启动即崩1.sysroot中ld-linux.so.3路径错误2.DT_RUNPATH指向不存在目录3. SoC内存映射与zImage入口地址冲突readelf -l ./program | grep interpreterobjdump -x ./program | grep RUNPATHcat /proc/cpuinfo | grep -E (modelfeatures)undefined symbol: __aeabi_uidivmod1.gcc未加-mfloat-abihard2.sysroot中libgcc.a是软浮点版arm-linux-gnueabihf-readelf -d ./program | grep NEEDEDfile /opt/sysroot/lib/libgcc.a1. 重新编译加-mfloat-abihard -mfpuvfpv42. 从gcc-11.2源码libgcc/config/arm/t-arm复制硬浮点libgcc.asymbol lookup error: ./app: undefined symbol: SSL_CTX_newOpenSSL版本不匹配主机编译用1.1.1板子运行用3.0ldd ./app | grep sslstrings /usr/lib/libssl.so.1.1 | grep SSL_CTX_new1. 交叉编译OpenSSL时加-DOPENSSL_NO_SSL32.patchelf --replace-needed libssl.so.1.1 libssl.so.3 ./appqmake: command not foundQt交叉编译后qmake未加入PATH或qmake是x86版本file /opt/qt-arm/qt5.12.10/bin/qmakeecho $PATH1.export PATH/opt/qt-arm/qt5.12.10/bin:$PATH2.sudo ln -sf /opt/qt-arm/qt5.12.10/bin/qmake /usr/local/bin/qmake-armVMware: Failed to start the virtual machineARM虚拟机VMware未启用Virtualize Intel VT-x/EPT或客户机OS镜像非aarch64vmware -vfile ubuntu-20.04-preinstalled-server-arm64raspi.img1. VMware设置→处理器→勾选Virtualize Intel VT-x/EPT2. 下载ubuntu-20.04-preinstalled-server-arm64raspi.img非desktop版5.2 独家避坑技巧那些文档里不会写的真相arm-linux-gnueabihf-gcc的-mcpu陷阱-mcpucortex-a7和-mcpucortex-a53看似相似但A53支持CRC32指令A7不支持。若代码中用了__crc32b内建函数用A7工具链编译会报错undefined reference to __crc32b。解决方案不是降级代码而是用-mcpucortex-a53 -marcharmv7-a让编译器生成A53兼容代码。QT_QPA_PLATFORM环境变量的致命影响在qt5.12.10交叉编译后若在板子上运行export QT_QPA_PLATFORMeglfs但未安装mesa驱动程序会静默退出。正确做法是先运行export QT_DEBUG_PLUGINS1查看插件加载日志再根据libqeglfs.so缺失提示安装对应GPU驱动。aarch64-linux-gnu-gcc的-march参数计算网络热词arm 5编译器下载中的arm compiler 5使用--cpuCortex-A57而GNU工具链需转换为-marcharmv8-acrccryptosimd。其中crc对应CRC32指令crypto对应AES/SHA指令simd对应NEON。漏掉simd会导致llama.cpp的ggml矩阵乘法性能下降70%。vmware 运行arm系统的内核panic规避VMware的virt平台默认使用CONFIG_ARM64_VIRTIO_MMIOy但某些ARM内核配置为CONFIG_ARM64_VIRTIO_PCIy。解决方案是在内核配置中启用CONFIG_ARM64_VIRTIO_MMIOy并在arch/arm64/boot/dts/virtio.dtsi中添加virtio_mmio { compatible virtio,mmio; };。我在调试phantomjs aarch64下载时遇到过最诡异的问题程序在QEMU中正常但在真机RK3328上启动后立即SIGSEGV。用gdbserver连接后发现崩溃在malloc()内部。最终定位到是glibc的malloc实现依赖getauxval(AT_HWCAP)返回的硬件能力位而RK3328的AT_HWCAP未正确设置HWCAP_ASIMDNEON标志。解决方案是在内核启动参数中添加arm64.nobti并重新编译glibc。这个细节在任何公开文档中都找不到只有在arm soc体系结构的SoC勘误表Errata里才有记载。6. 扩展实践从基础交叉编译到高级场景的平滑演进6.1 使用gem5在aarch64架构下运行spec2006仿真器的精度博弈使用gem5在aarch64架构下运行spec2006是评估ARM CPU微架构性能的标准方法但它暴露了交叉编译的终极挑战仿真精度与编译器行为的耦合。gem5的aarch64模式支持Atomic快速、Timing精确、O3乱序三种CPU模型而SPEC2006的401.bzip2等基准测试对分支预测器建模极度敏感。实操关键步骤编译SPEC2006 for gem5# 必须用gem5自带的工具链位于gem5/util/m5 export M5_PATH/path/to/gem5/util/m5 # 配