龙芯启动这句话是我第一次把串口线接到龙芯2K1000开发板上看到终端里跳出登录提示符时脱口而出的。后来这个习惯一直保留着从2K1000玩到2K3000再到把整套龙芯方案塞进轨道交通AFC系统的闸机里每次系统点亮我都会在心里默念一遍这句话。很多做嵌入式和工业控制的朋友问我龙芯到底能不能用在真正的商业项目里我的回答是能而且我们已经用它跑通了从Docker容器化部署到AFC闸机业务的一整条链路。这篇文章我就把这几年在国产化工控平台上摸爬滚打的经验全部倒出来给准备入坑或者正在挣扎的同行一个参考。我不打算讲太多空泛的概念直接讲实际遇到的事、实际解决的问题、实际踩过的坑。你会看到龙芯平台的完整技术栈、Docker在国产化替代里的关键价值、AFC系统里龙芯2K3000的具体落地方式以及一份可以直接抄的实操命令清单。1. 先弄清楚龙芯平台里的“启动”到底意味着什么启动这两个字在龙芯项目里包含的东西比表面看起来要多得多。它不是按下电源键看到个Logo那么简单而是从bootloader到内核、从根文件系统到容器运行时、从业务进程到远程运维通道一整条链路全部拉通。很多人第一次拿到龙芯板子习惯了x86上装个Ubuntu就完事在龙芯上却发现连系统镜像都要自己选一下子就懵了。这事儿真不怪大家因为龙芯的技术栈确实和x86、ARM都不太一样。1.1 龙芯是“一颗芯片”但更是一整套技术栈先把概念理清楚。龙芯处理器分几个系列3A系列面向桌面和服务器的通用处理器2K系列面向嵌入式、工控、边缘计算场景。我们项目里用得比较多的是2K1000和2K3000。2K1000是双核SoC主频1GHz左右主打低功耗和接口丰富适合传统工控、数据采集、物联网网关2K3000是新一代产品CPU和GPU能力都有明显提升接口更齐全适合需要本地显示、边缘计算、自助服务终端的场景。这里有个关键点必须讲明白龙芯用的是自研的LoongArch指令集不是ARM授权也不是x86授权而是完全自主定义的一整套指令集规范。这意味着所有二进制软件都必须针对LoongArch重新编译。这也是启动难的根本原因——你在x86上apt install的软件在龙芯上不一定有对应的安装源。我举个例子帮大家理解。处理器指令集就像一门语言x86讲英语ARM讲西班牙语LoongArch讲中文。代码就是演讲稿你在英语环境里写好的演讲稿拿到中文环境里哪怕意思完全一样也得重新翻译一遍。所以龙芯生态好不好这个问题本质上就是有多少软件已经翻译成了中文。好消息是这几年LoongArch生态发展很快内核主线支持、主流发行版适配已经能让开发者在龙芯上正常干活了但遇到一些冷门软件依然要自己动手编译这个心理准备要有。1.2 轨道交通AFC系统为什么要关注龙芯AFC是Automatic Fare Collection的缩写也就是自动售检票系统。在城市轨道交通场景里它负责完成乘客从购票、进站检票、乘车到出站扣费的全流程。整个系统由车票介质、车站终端设备、车站计算机、线路中央计算机、清分中心这几个层级构成。我们最熟悉的闸机、自动售票机TVM、人工售票机BOM都属于车站终端设备这一层。AFC设备的工作环境比很多人想象的要苛刻。车站不一定是恒温机房闸机终端散落在站厅、站台可能挨着风口夏天闷热冬天寒冷还有震动和粉尘。设备要7x24小时持续运行停一台闸机就可能影响乘客通行。设备生命周期很长动辄十年以上。这意味着AFC设备对平台的稳定性、工业级宽温范围、接口丰富度都有硬性要求。以前这个赛道基本被x86工控机或者特定嵌入式方案占据。近几年业主方越来越关注核心设备的自主可控。轨道交通行业在尝试把闸机、售票机这些终端的主控平台迁移到国产处理器上。龙芯2K3000的优势在于它在一个不算大的板卡上集成了一颗性能足够的处理器、丰富的I/O接口、显示输出和网络能力功耗和发热也在可接受范围内比较适合做AFC终端的主控。1.3 龙芯2K1000和龙芯2K3000选型时怎么判断我直接用一张表把两个平台的核心区别列出来节省大家查资料的时间。对比项龙芯2K1000龙芯2K3000CPU核心双核多核性能更高主频约1GHz更高多媒体能力更强内存DDR3DDR4/LPDDR4显示能力基础显示图形能力更强适合触摸屏UI主要接口网口、串口、USB、PCIe接口更丰富支持多路显示、更多PCIe功耗低适中定位工控、数据采集、网关边缘计算、自助终端、可视化设备怎么选我的经验是看产品的交互复杂度和数据量。如果项目里主要是串口采集、Modbus轮询、协议网关这类活儿2K1000足够了功耗低硬件成本也更容易控制。如果终端上要跑触摸屏界面、二维码识别、视频推流甚至以后还想加轻量AI功能就直接上2K3000别犹豫。AFC闸机属于典型的既要又要场景屏幕上要渲染票务信息控制器要实时处理通行逻辑和电机响应还要接通读卡器、扫码器、网络通信。选2K3000容错空间大得多。另一个被忽略的选型维度是生态惯性。2K1000出来得早社区资料、BSP、适配案例相对多2K3000性能更好但软件版本可能要自己踩一些坑。所以我建议如果团队里第一次接触龙芯先从2K1000或者龙芯派上手做技术验证跑通容器和业务之后再评估是否迁移到2K3000。贸然用新平台做商业项目风险会偏高。2. 龙芯上的Docker把“移植噩梦”变成“一次打包”龙芯平台最容易让人崩溃的环节就是装环境。一个应用依赖几十个库每个库都得找LoongArch的包版本对不上就是编不过现场换台设备可能又来一遍。这一节专门讲龙芯Docker的用法。Docker不是赶时髦而是实打实地解决国产化平台环境一致性的问题。2.1 容器化在国产化替代里的特殊价值我在x86服务器上玩容器很多年从来没觉得Docker有多救命。直到把应用往龙芯上迁的时候才意识到容器化真正解决的是环境交付的问题。传统做法是开发在x86的笔记本上编译出目标平台的可执行文件运维到现场再装系统、装依赖、调配置任何一个环节出问题整套系统就起不来。现场几十台设备每台手动配光是版本差异就能让人崩溃。用Docker以后开发阶段就把依赖环境锁进镜像测试完的镜像推到内部镜像仓库现场设备只需要一条命令拉取并启动。不管底层是Loongnix哪个小版本、内核有没有打补丁容器里的环境永远一致。我甚至见过团队把整个AFC业务系统打包成四五个容器用一条docker compose up -d全部拉起部署效率提升了一个量级。对龙芯平台来说Docker还有一个额外价值消化架构差异。容器镜像绑定的是平台架构龙芯容器镜像天然是loongarch64的拉取时不会有x86镜像那种装得上但跑不起来的尴尬。只要在开发阶段就把镜像构建成loongarch64现场就绝对不会出现办公室好好的现场跑不了的问题。2.2 在Loongnix上安装Docker干净、完整的命令序列先确认系统架构。龙芯上执行uname -m正常应该输出loongarch64。这一步非常重要后面所有操作都建立在我确实在一台loongarch64机器上这个前提下。uname -m cat /etc/os-releaseLoongnix是龙芯官方适配的Linux发行版在这上面装Docker我建议走系统仓库不要盲目去网上复制安装脚本。很多通用安装脚本默认按x86_64架构下载二进制在龙芯上执行会直接失败而且报错信息容易误导人。sudo dnf install docker -y sudo systemctl enable --now docker docker version装完以后执行docker version确认Client和Server的Architecture都显示loongarch64。这里有个易混点docker version里显示的是运行Docker的主机架构如果显示的是x86_64那你八成装错包了别往下走。再用docker info看一下存储驱动和运行时的基本信息确认一切正常。2.3 拉取第一个龙芯架构镜像容器里跑NginxDocker装好以后第一步就是拉个镜像验证。龙芯官方维护了Loongnix容器镜像仓库地址是cr.loongnix.cn上面有nginx、redis、openjdk、python这些常用基础镜像。拉取时不需要加任何特殊参数Docker会自动根据主机架构选择对应标签。docker pull cr.loongnix.cn/library/nginx:latest docker run -d --name test-nginx -p 8080:80 cr.loongnix.cn/library/nginx:latest curl http://127.0.0.1:8080如果curl能返回Nginx的欢迎页龙芯上的Docker链路就算通了。这一步看着简单却是后面一切容器化工作的地基。我强烈建议团队里每个新人都先走一遍这个流程排除底层环境问题之后再碰业务应用。不要跳过这个验证直接拿业务镜像来试。一旦失败你根本分不清是Docker环境问题还是业务镜像问题。2.4 在x86开发机上为龙芯交叉构建镜像buildx实践实际项目里开发主力机大概率还是x86。这就面临一个很现实的问题如何在笔记本上构建一个loongarch64的镜像答案是docker buildx加QEMU用户态模拟。原理是buildx在创建构建器时可以加载多个平台的模拟器x86机器通过QEMU运行loongarch64的用户态程序从而在x86上完整执行Dockerfile里的RUN指令。命令如下docker buildx create --name loongarch-builder --platform linux/loong64 --use docker buildx inspect --bootstrap docker buildx build --platform linux/loong64 -t your-registry/myapp:loong64 --push .注意两点。第一在Dockerfile里基础镜像要指名loongarch64的仓库地址比如FROM cr.loongnix.cn/library/openjdk:8不要用默认的hub地址。第二buildx模拟构建适合做镜像构建验证和CI流水线但涉及复杂编译或者版本兼容敏感的应用最好还是放到龙芯实体机上构建。模拟环境里能过和真实环境里能跑还是有差距的。我踩过一个坑某C应用在QEMU模拟构建时一切正常推到龙芯真机上一启动就段错误最后发现是某些编译选项在模拟器环境里没有正确启用目标平台特性。从那以后凡是生产镜像我都在龙芯实体机上构建。3. 龙芯2K3000赋能AFC系统从硬件到容器的完整实战这一节是整个项目里最值得细聊的部分。我会按一个真实项目的推进顺序从系统架构、硬件适配、软件容器化三个层面把2K3000在AFC系统里扮演的角色拆开讲透。不同站点和项目的具体细节会有差异但落地路径是可以复制的。3.1 先看懂AFC系统长什么样五层架构与龙芯的切入点AFC系统在轨道交通行业有一套标准的分层架构从下往上大概是这样第一层是车票介质层包括IC卡、二维码、人脸特征等。第二层是车站终端设备层就是乘客直接面对的闸机、自动售票机、人工售票机等。第三层是车站计算机层负责车站内所有终端设备的监控和数据汇聚。第四层是线路中央计算机层把整条线路的数据汇总起来。第五层是清分中心层负责票款清算、客流统计分析。龙芯2K3000在这个架构里的切入点主要集中在第二层和第三层。终端设备层2K3000可以作为闸机和售票机的主控板直接驱动读卡器、扫码器、显示屏、电机控制器车站计算机层2K3000可以作为车站边缘服务器或工业一体机的主控跑数据采集、监控和业务管理软件。这样一来从乘客接触的终端到车站侧的服务节点整条链路都实现了国产化底座。3.2 闸机里的“岗位要求”2K3000需要满足哪些硬条件咱们把镜头拉到一台真实的AFC闸机里。闸机表面上是给乘客通行的设备其实内部是一台集成了多类外设的嵌入式工控设备。主控板要接的东西包括票卡读写器通常是ISO 14443标准的读卡模块通过USB或串口连接二维码扫码器负责扫码过闸通行控制器驱动电机和电磁锁实现扇门的开关红外对射或光幕传感器用于检测乘客位置和通行状态防止夹人乘客显示屏实时显示票务状态和通行引导还有蜂鸣器、急停按钮、维修工控接口等。这些外设对主控板的接口要求是至少3个以上可用串口或USB口、足够的GPIO、稳定的网络接口、支持LVDS或HDMI的显示输出。2K3000在这些方面是够用的。真正要下功夫的是软件层内核要正确识别所有外设设备树要配好每个串口的波特率、数据位要符合读卡器的协议容器的device映射要把外设正确暴露给业务进程。还有散热和工业级可靠性的问题。闸机里不是恒温机房夏季站厅温度可能到四十度设备还要7x24小时运转。我一般建议在结构设计时就把散热做好系统层面也要有温度监控。2K3000功耗比2K1000高一些但整体仍在可接受范围内。实测下来只要机箱风道合理长期稳定运行是可以做到的。这里说句实话我这些数据来自自己项目的实测经验并非官方标称数据各位做整机设计时建议以实际测试为准。3.3 从“裸板”到“业务上线”的九步落地流程我把一套龙芯2K3000 AFC终端主控从零到上线的过程整理下来按项目推进顺序展开。第一步烧写系统镜像。拿到开发板或工控主板后先完成Loongnix或者支持LoongArch的Linux发行版安装。安装在板载eMMC或者SSD都可以关键是确认内核版本较新对LoongArch支持完整。第二步交叉编译业务依赖。在x86开发机上安装LoongArch交叉编译工具链把业务程序用到的第三方库编译成loongarch64版本打包成部署包。每个库都要检查是否支持LoongArch不能编译的库提前找替代方案这是整个项目里最耗时的环节。第三步安装Docker环境。按前面说的方法装好Docker验证基本链路。第四步准备基础镜像。从cr.loongnix.cn拉取合适版本的基础镜像比如OpenJDK、Python、Nginx、Redis。建议固定版本号不要用latest。第五步构建业务镜像。在龙芯实体机上把业务程序打进基础镜像配合配置文件、启动脚本构建成业务镜像。这里注意保持镜像精简尽量用多阶段构建把编译产物分离。FROM cr.loongnix.cn/library/openjdk:8-jre WORKDIR /app COPY afc-app.jar /app/ COPY application.yml /app/config/ EXPOSE 8080 CMD [java, -jar, afc-app.jar]第六步编写编排文件。用docker-compose.yml把闸机里需要跑的容器定义出来。我的经验是拆成几个容器主业务容器、设备通讯容器、日志采集容器、远程运维agent容器。每个容器独立重启策略互不影响。下面是一个简化的示例version: 3 services: afc-core: image: your-registry/afc-core:1.0.0 restart: unless-stopped devices: - /dev/ttyS4:/dev/ttyS4 - /dev/ttyS5:/dev/ttyS5 volumes: - /var/log/afc:/var/log/afc afc-device: image: your-registry/afc-device:1.0.0 restart: unless-stopped network_mode: host第七步配置开机自启。单独为docker-compose写一个systemd单元文件设置开机自动启动依赖锁定在docker.service之后。[Unit] DescriptionAFC Stack Requiresdocker.service Afterdocker.service [Service] Typeoneshot WorkingDirectory/opt/afc-stack ExecStart/usr/local/bin/docker-compose up -d ExecStop/usr/local/bin/docker-compose down RemainAfterExityes [Install] WantedBymulti-user.target第八步接入看门狗。硬件看门狗必须在系统层面配置好避免业务异常时整机卡死软件层面利用Docker的restart策略和系统的服务守护做到业务进程自动拉起。第九步远程运维通道。给每台闸机分配独立管理IP部署运维agent通过内部管理网统一纳管。镜像更新采用离线升级包或内网镜像仓库方式不在现场逐台手动操作。3.4 高可靠部署看门狗、掉电恢复与日志策略地铁闸机是不能隔三差五重启的设备。一旦卡死或者宕机轻则影响通行效率重则造成站内拥堵。所以可靠性和容灾设计比功能开发更考验功夫。第一层是硬件看门狗。主控板上要有硬件看门狗芯片系统层通过定时喂狗来检测系统是否正常运行。如果内核或应用长时间没有响应看门狗超时会让整机复位。这个机制能兜底解决系统hang死但没有人发现的情况。第二层是软件守护。Docker容器的restart策略配置成unless-stopped容器崩溃时Docker会自动拉起。systemd层面再包装一层即使Docker服务本身出现异常系统服务也能自动恢复docker-compose栈。第三层是掉电保护。闸机可能面临突发断电。程序在写入票务数据、日志时要有原子性设计App层面把关键状态持久化到数据库或者本地文件时记得用事务或者落盘后再确认避免断电导致数据损坏。容器镜像本身是只读层重启后能恢复到干净状态业务数据走数据卷持久化这是推荐的方式。日志策略也容易被忽略。AFC设备长时间运行日志文件会非常大。我建议容器里只输出日志到stdout由统一的日志采集进程收集到数据卷并做日期分片和保留策略例如保留30天或按大小滚动。这样既方便排障也不会撑爆存储。3.5 交付前的验证清单这些坑别等到现场才发现设备在实验室跑得好好的一到现场就各种幺蛾子这是国产化工控项目里最常见的翻车方式。为了避免这种局面我总结了一份交付前的验证清单每一条都来自真实教训。反复开关门测试闸机扇门每天开关几百上千次主控板在反复电机冲击下会不会复位一定要提前跑满24小时循环测试。连续压力测试业务系统全负载跑72小时以上观察内存泄漏、容器重启次数、日志增长情况。断电恢复测试在业务写入的高峰期突然断电再上电确认系统和业务能自动恢复数据不损坏。温度环境测试有条件的话做高低温箱测试模拟站厅极端温度确认系统不会因为过热降频导致闸机反应迟钝。远程更新演练模拟现场设备需要远程升级的场景确认镜像拉取或者离线升级包能稳定执行升级失败能回滚。这些测试如果等到项目交付后再补成本会高到让人怀疑人生。我见过一个项目闸机装到站点之后才发现主控板在高温下会随机重启最后只能全部返厂改散热方案工期和成本全部失控。提前做验证永远是最划算的投入。4. 常见问题与排查技巧实录这一节我整理了一份开发龙芯过程中最常见的故障和处理方法每一条都是自己或者团队在项目里真实踩过的。如果你在项目中也遇到相同问题可以对照排查。4.1 故障速查表现象可能原因排查与修复uname -m 输出异常系统架构判断错误确认输出为loongarch64如果显示其他架构说明系统装错了docker pull 报 manifest unknown镜像仓库没有对应loong64架构标签切换到cr.loongnix.cn等提供loongarch64镜像的仓库某镜像在x86能跑龙芯上报错镜像架构不匹配检查镜像架构尽量拉取loongarch64原生镜像容器里访问串口失败没有把设备映射进容器启动加--device/dev/ttyS4:/dev/ttyS4参数开机后服务没有自动启动systemd或docker自启配置问题检查enable状态、docker restart policy、依赖关系业务进程段错误编译选项或依赖库版本问题确认编译工具链目标架构在龙芯实体机重编系统温度过高触发降频散热设计问题优化机箱风道增加温度监控调整耗CPU任务调度4.2 几个隐藏很深的坑第一个坑是我反复强调的不要在龙芯上用通用安装脚本装Docker。网上流传的快速安装Docker脚本基本都按x86_64架构写死执行完看起来装上了实际上Docker的client或daemon根本无法启动或者报一些莫名其妙的错。一旦遇到docker命令不存在、docker version显示不出server信息先检查自己是不是用了通用脚本然后全部卸载改用系统自带的loongarch64仓库安装。第二个坑交叉编译链和内核版本不匹配。这个特别隐蔽。我们曾经编译一个内核模块在开发机上用的交叉编译链版本偏高编出来的模块在目标板上一加载就报invalid module format。后来换回与内核配套的编译链版本才通过。所以一定要记录内核版本和交叉编译链版本把它们当成一套组合来看待不要单独升级其中一项。第三个坑Java应用莫名其妙崩溃不是代码问题。有同事把x86上编好的JNI原生库拷贝到龙芯上应用启动就崩。查了很久问题出在这个原生库是x86架构编译的。Java字节码是可移植的但JNI库不行。还要确认Lombok、Netty这些框架是否支持LoongArch某些框架版本过旧在LoongArch上会有不自洽的问题升级版本通常能解决。第四个坑设备树里串口别名和外设实际编号对不上。在AFC项目里我们通过/dev/ttyS4接读卡器结果容器映射之后发现ttyS4根本不是读卡器的那个串口。原因是内核设备树中串口别名分配和外设插槽的物理关系跟预期不一致。排查方法是在主机上先用stty和loopback短接法确认每个ttyS对应哪个物理串口再决定容器映射。做这一步成本很低但能省下一个下午。4.3 一句话经验合集写在这里的几句话是我做完项目沉淀下来最有用的复盘龙芯平台的坑90%出在架构不匹配上排查时第一时间确认架构别先怀疑业务代码。常用基础镜像、关键组件版本在项目启动阶段就要固定下来做成公司内部的基础镜像仓库版本漂移会毁掉整个项目的可维护性。所有设备的远程管理凭据、镜像仓库、机柜IP都要落到文档里。AFC项目建设周期长设备散在各地没有文档就是灾难。国产化平台的应用移植不要指望一条命令跑通每次只修改一个变量逐项验证反而最快。5. 写在最后一些真实的体会最后说几句真心话。从第一次在龙芯2K1000上看到登录提示符到现在在龙芯2K3000上跑通完整的AFC业务系统前后跨度不短中间也想过放弃。国产化平台的初期确实比x86要麻烦资料少、软件包不全、遇到问题没人可问这是客观事实。但这两年我明显感觉到LoongArch生态已经不是能不能跑的问题而是怎么跑得更好的问题。Docker补齐了环境交付的短板社区和厂商也在持续跟进基础软件适配。龙芯的启动速度、工具链稳定性、方案的可复制性都比我预想中成熟得多。如果你是刚开始接触龙芯的工程师我的建议很简单先别急着铺大摊子找一块板子装上系统配好Docker把你手头最熟悉的那个小服务容器化部署上去。等你完成这个闭环你会发现原本以为会很艰难的国产化移植其实已经有了清晰的路径。我们团队现在的新人培训基本就是这条路线——龙芯启动从启动那一刻开始后面的一切就都有了着落。
龙芯2K3000与Docker：轨道交通AFC系统国产化实战
龙芯启动这句话是我第一次把串口线接到龙芯2K1000开发板上看到终端里跳出登录提示符时脱口而出的。后来这个习惯一直保留着从2K1000玩到2K3000再到把整套龙芯方案塞进轨道交通AFC系统的闸机里每次系统点亮我都会在心里默念一遍这句话。很多做嵌入式和工业控制的朋友问我龙芯到底能不能用在真正的商业项目里我的回答是能而且我们已经用它跑通了从Docker容器化部署到AFC闸机业务的一整条链路。这篇文章我就把这几年在国产化工控平台上摸爬滚打的经验全部倒出来给准备入坑或者正在挣扎的同行一个参考。我不打算讲太多空泛的概念直接讲实际遇到的事、实际解决的问题、实际踩过的坑。你会看到龙芯平台的完整技术栈、Docker在国产化替代里的关键价值、AFC系统里龙芯2K3000的具体落地方式以及一份可以直接抄的实操命令清单。1. 先弄清楚龙芯平台里的“启动”到底意味着什么启动这两个字在龙芯项目里包含的东西比表面看起来要多得多。它不是按下电源键看到个Logo那么简单而是从bootloader到内核、从根文件系统到容器运行时、从业务进程到远程运维通道一整条链路全部拉通。很多人第一次拿到龙芯板子习惯了x86上装个Ubuntu就完事在龙芯上却发现连系统镜像都要自己选一下子就懵了。这事儿真不怪大家因为龙芯的技术栈确实和x86、ARM都不太一样。1.1 龙芯是“一颗芯片”但更是一整套技术栈先把概念理清楚。龙芯处理器分几个系列3A系列面向桌面和服务器的通用处理器2K系列面向嵌入式、工控、边缘计算场景。我们项目里用得比较多的是2K1000和2K3000。2K1000是双核SoC主频1GHz左右主打低功耗和接口丰富适合传统工控、数据采集、物联网网关2K3000是新一代产品CPU和GPU能力都有明显提升接口更齐全适合需要本地显示、边缘计算、自助服务终端的场景。这里有个关键点必须讲明白龙芯用的是自研的LoongArch指令集不是ARM授权也不是x86授权而是完全自主定义的一整套指令集规范。这意味着所有二进制软件都必须针对LoongArch重新编译。这也是启动难的根本原因——你在x86上apt install的软件在龙芯上不一定有对应的安装源。我举个例子帮大家理解。处理器指令集就像一门语言x86讲英语ARM讲西班牙语LoongArch讲中文。代码就是演讲稿你在英语环境里写好的演讲稿拿到中文环境里哪怕意思完全一样也得重新翻译一遍。所以龙芯生态好不好这个问题本质上就是有多少软件已经翻译成了中文。好消息是这几年LoongArch生态发展很快内核主线支持、主流发行版适配已经能让开发者在龙芯上正常干活了但遇到一些冷门软件依然要自己动手编译这个心理准备要有。1.2 轨道交通AFC系统为什么要关注龙芯AFC是Automatic Fare Collection的缩写也就是自动售检票系统。在城市轨道交通场景里它负责完成乘客从购票、进站检票、乘车到出站扣费的全流程。整个系统由车票介质、车站终端设备、车站计算机、线路中央计算机、清分中心这几个层级构成。我们最熟悉的闸机、自动售票机TVM、人工售票机BOM都属于车站终端设备这一层。AFC设备的工作环境比很多人想象的要苛刻。车站不一定是恒温机房闸机终端散落在站厅、站台可能挨着风口夏天闷热冬天寒冷还有震动和粉尘。设备要7x24小时持续运行停一台闸机就可能影响乘客通行。设备生命周期很长动辄十年以上。这意味着AFC设备对平台的稳定性、工业级宽温范围、接口丰富度都有硬性要求。以前这个赛道基本被x86工控机或者特定嵌入式方案占据。近几年业主方越来越关注核心设备的自主可控。轨道交通行业在尝试把闸机、售票机这些终端的主控平台迁移到国产处理器上。龙芯2K3000的优势在于它在一个不算大的板卡上集成了一颗性能足够的处理器、丰富的I/O接口、显示输出和网络能力功耗和发热也在可接受范围内比较适合做AFC终端的主控。1.3 龙芯2K1000和龙芯2K3000选型时怎么判断我直接用一张表把两个平台的核心区别列出来节省大家查资料的时间。对比项龙芯2K1000龙芯2K3000CPU核心双核多核性能更高主频约1GHz更高多媒体能力更强内存DDR3DDR4/LPDDR4显示能力基础显示图形能力更强适合触摸屏UI主要接口网口、串口、USB、PCIe接口更丰富支持多路显示、更多PCIe功耗低适中定位工控、数据采集、网关边缘计算、自助终端、可视化设备怎么选我的经验是看产品的交互复杂度和数据量。如果项目里主要是串口采集、Modbus轮询、协议网关这类活儿2K1000足够了功耗低硬件成本也更容易控制。如果终端上要跑触摸屏界面、二维码识别、视频推流甚至以后还想加轻量AI功能就直接上2K3000别犹豫。AFC闸机属于典型的既要又要场景屏幕上要渲染票务信息控制器要实时处理通行逻辑和电机响应还要接通读卡器、扫码器、网络通信。选2K3000容错空间大得多。另一个被忽略的选型维度是生态惯性。2K1000出来得早社区资料、BSP、适配案例相对多2K3000性能更好但软件版本可能要自己踩一些坑。所以我建议如果团队里第一次接触龙芯先从2K1000或者龙芯派上手做技术验证跑通容器和业务之后再评估是否迁移到2K3000。贸然用新平台做商业项目风险会偏高。2. 龙芯上的Docker把“移植噩梦”变成“一次打包”龙芯平台最容易让人崩溃的环节就是装环境。一个应用依赖几十个库每个库都得找LoongArch的包版本对不上就是编不过现场换台设备可能又来一遍。这一节专门讲龙芯Docker的用法。Docker不是赶时髦而是实打实地解决国产化平台环境一致性的问题。2.1 容器化在国产化替代里的特殊价值我在x86服务器上玩容器很多年从来没觉得Docker有多救命。直到把应用往龙芯上迁的时候才意识到容器化真正解决的是环境交付的问题。传统做法是开发在x86的笔记本上编译出目标平台的可执行文件运维到现场再装系统、装依赖、调配置任何一个环节出问题整套系统就起不来。现场几十台设备每台手动配光是版本差异就能让人崩溃。用Docker以后开发阶段就把依赖环境锁进镜像测试完的镜像推到内部镜像仓库现场设备只需要一条命令拉取并启动。不管底层是Loongnix哪个小版本、内核有没有打补丁容器里的环境永远一致。我甚至见过团队把整个AFC业务系统打包成四五个容器用一条docker compose up -d全部拉起部署效率提升了一个量级。对龙芯平台来说Docker还有一个额外价值消化架构差异。容器镜像绑定的是平台架构龙芯容器镜像天然是loongarch64的拉取时不会有x86镜像那种装得上但跑不起来的尴尬。只要在开发阶段就把镜像构建成loongarch64现场就绝对不会出现办公室好好的现场跑不了的问题。2.2 在Loongnix上安装Docker干净、完整的命令序列先确认系统架构。龙芯上执行uname -m正常应该输出loongarch64。这一步非常重要后面所有操作都建立在我确实在一台loongarch64机器上这个前提下。uname -m cat /etc/os-releaseLoongnix是龙芯官方适配的Linux发行版在这上面装Docker我建议走系统仓库不要盲目去网上复制安装脚本。很多通用安装脚本默认按x86_64架构下载二进制在龙芯上执行会直接失败而且报错信息容易误导人。sudo dnf install docker -y sudo systemctl enable --now docker docker version装完以后执行docker version确认Client和Server的Architecture都显示loongarch64。这里有个易混点docker version里显示的是运行Docker的主机架构如果显示的是x86_64那你八成装错包了别往下走。再用docker info看一下存储驱动和运行时的基本信息确认一切正常。2.3 拉取第一个龙芯架构镜像容器里跑NginxDocker装好以后第一步就是拉个镜像验证。龙芯官方维护了Loongnix容器镜像仓库地址是cr.loongnix.cn上面有nginx、redis、openjdk、python这些常用基础镜像。拉取时不需要加任何特殊参数Docker会自动根据主机架构选择对应标签。docker pull cr.loongnix.cn/library/nginx:latest docker run -d --name test-nginx -p 8080:80 cr.loongnix.cn/library/nginx:latest curl http://127.0.0.1:8080如果curl能返回Nginx的欢迎页龙芯上的Docker链路就算通了。这一步看着简单却是后面一切容器化工作的地基。我强烈建议团队里每个新人都先走一遍这个流程排除底层环境问题之后再碰业务应用。不要跳过这个验证直接拿业务镜像来试。一旦失败你根本分不清是Docker环境问题还是业务镜像问题。2.4 在x86开发机上为龙芯交叉构建镜像buildx实践实际项目里开发主力机大概率还是x86。这就面临一个很现实的问题如何在笔记本上构建一个loongarch64的镜像答案是docker buildx加QEMU用户态模拟。原理是buildx在创建构建器时可以加载多个平台的模拟器x86机器通过QEMU运行loongarch64的用户态程序从而在x86上完整执行Dockerfile里的RUN指令。命令如下docker buildx create --name loongarch-builder --platform linux/loong64 --use docker buildx inspect --bootstrap docker buildx build --platform linux/loong64 -t your-registry/myapp:loong64 --push .注意两点。第一在Dockerfile里基础镜像要指名loongarch64的仓库地址比如FROM cr.loongnix.cn/library/openjdk:8不要用默认的hub地址。第二buildx模拟构建适合做镜像构建验证和CI流水线但涉及复杂编译或者版本兼容敏感的应用最好还是放到龙芯实体机上构建。模拟环境里能过和真实环境里能跑还是有差距的。我踩过一个坑某C应用在QEMU模拟构建时一切正常推到龙芯真机上一启动就段错误最后发现是某些编译选项在模拟器环境里没有正确启用目标平台特性。从那以后凡是生产镜像我都在龙芯实体机上构建。3. 龙芯2K3000赋能AFC系统从硬件到容器的完整实战这一节是整个项目里最值得细聊的部分。我会按一个真实项目的推进顺序从系统架构、硬件适配、软件容器化三个层面把2K3000在AFC系统里扮演的角色拆开讲透。不同站点和项目的具体细节会有差异但落地路径是可以复制的。3.1 先看懂AFC系统长什么样五层架构与龙芯的切入点AFC系统在轨道交通行业有一套标准的分层架构从下往上大概是这样第一层是车票介质层包括IC卡、二维码、人脸特征等。第二层是车站终端设备层就是乘客直接面对的闸机、自动售票机、人工售票机等。第三层是车站计算机层负责车站内所有终端设备的监控和数据汇聚。第四层是线路中央计算机层把整条线路的数据汇总起来。第五层是清分中心层负责票款清算、客流统计分析。龙芯2K3000在这个架构里的切入点主要集中在第二层和第三层。终端设备层2K3000可以作为闸机和售票机的主控板直接驱动读卡器、扫码器、显示屏、电机控制器车站计算机层2K3000可以作为车站边缘服务器或工业一体机的主控跑数据采集、监控和业务管理软件。这样一来从乘客接触的终端到车站侧的服务节点整条链路都实现了国产化底座。3.2 闸机里的“岗位要求”2K3000需要满足哪些硬条件咱们把镜头拉到一台真实的AFC闸机里。闸机表面上是给乘客通行的设备其实内部是一台集成了多类外设的嵌入式工控设备。主控板要接的东西包括票卡读写器通常是ISO 14443标准的读卡模块通过USB或串口连接二维码扫码器负责扫码过闸通行控制器驱动电机和电磁锁实现扇门的开关红外对射或光幕传感器用于检测乘客位置和通行状态防止夹人乘客显示屏实时显示票务状态和通行引导还有蜂鸣器、急停按钮、维修工控接口等。这些外设对主控板的接口要求是至少3个以上可用串口或USB口、足够的GPIO、稳定的网络接口、支持LVDS或HDMI的显示输出。2K3000在这些方面是够用的。真正要下功夫的是软件层内核要正确识别所有外设设备树要配好每个串口的波特率、数据位要符合读卡器的协议容器的device映射要把外设正确暴露给业务进程。还有散热和工业级可靠性的问题。闸机里不是恒温机房夏季站厅温度可能到四十度设备还要7x24小时运转。我一般建议在结构设计时就把散热做好系统层面也要有温度监控。2K3000功耗比2K1000高一些但整体仍在可接受范围内。实测下来只要机箱风道合理长期稳定运行是可以做到的。这里说句实话我这些数据来自自己项目的实测经验并非官方标称数据各位做整机设计时建议以实际测试为准。3.3 从“裸板”到“业务上线”的九步落地流程我把一套龙芯2K3000 AFC终端主控从零到上线的过程整理下来按项目推进顺序展开。第一步烧写系统镜像。拿到开发板或工控主板后先完成Loongnix或者支持LoongArch的Linux发行版安装。安装在板载eMMC或者SSD都可以关键是确认内核版本较新对LoongArch支持完整。第二步交叉编译业务依赖。在x86开发机上安装LoongArch交叉编译工具链把业务程序用到的第三方库编译成loongarch64版本打包成部署包。每个库都要检查是否支持LoongArch不能编译的库提前找替代方案这是整个项目里最耗时的环节。第三步安装Docker环境。按前面说的方法装好Docker验证基本链路。第四步准备基础镜像。从cr.loongnix.cn拉取合适版本的基础镜像比如OpenJDK、Python、Nginx、Redis。建议固定版本号不要用latest。第五步构建业务镜像。在龙芯实体机上把业务程序打进基础镜像配合配置文件、启动脚本构建成业务镜像。这里注意保持镜像精简尽量用多阶段构建把编译产物分离。FROM cr.loongnix.cn/library/openjdk:8-jre WORKDIR /app COPY afc-app.jar /app/ COPY application.yml /app/config/ EXPOSE 8080 CMD [java, -jar, afc-app.jar]第六步编写编排文件。用docker-compose.yml把闸机里需要跑的容器定义出来。我的经验是拆成几个容器主业务容器、设备通讯容器、日志采集容器、远程运维agent容器。每个容器独立重启策略互不影响。下面是一个简化的示例version: 3 services: afc-core: image: your-registry/afc-core:1.0.0 restart: unless-stopped devices: - /dev/ttyS4:/dev/ttyS4 - /dev/ttyS5:/dev/ttyS5 volumes: - /var/log/afc:/var/log/afc afc-device: image: your-registry/afc-device:1.0.0 restart: unless-stopped network_mode: host第七步配置开机自启。单独为docker-compose写一个systemd单元文件设置开机自动启动依赖锁定在docker.service之后。[Unit] DescriptionAFC Stack Requiresdocker.service Afterdocker.service [Service] Typeoneshot WorkingDirectory/opt/afc-stack ExecStart/usr/local/bin/docker-compose up -d ExecStop/usr/local/bin/docker-compose down RemainAfterExityes [Install] WantedBymulti-user.target第八步接入看门狗。硬件看门狗必须在系统层面配置好避免业务异常时整机卡死软件层面利用Docker的restart策略和系统的服务守护做到业务进程自动拉起。第九步远程运维通道。给每台闸机分配独立管理IP部署运维agent通过内部管理网统一纳管。镜像更新采用离线升级包或内网镜像仓库方式不在现场逐台手动操作。3.4 高可靠部署看门狗、掉电恢复与日志策略地铁闸机是不能隔三差五重启的设备。一旦卡死或者宕机轻则影响通行效率重则造成站内拥堵。所以可靠性和容灾设计比功能开发更考验功夫。第一层是硬件看门狗。主控板上要有硬件看门狗芯片系统层通过定时喂狗来检测系统是否正常运行。如果内核或应用长时间没有响应看门狗超时会让整机复位。这个机制能兜底解决系统hang死但没有人发现的情况。第二层是软件守护。Docker容器的restart策略配置成unless-stopped容器崩溃时Docker会自动拉起。systemd层面再包装一层即使Docker服务本身出现异常系统服务也能自动恢复docker-compose栈。第三层是掉电保护。闸机可能面临突发断电。程序在写入票务数据、日志时要有原子性设计App层面把关键状态持久化到数据库或者本地文件时记得用事务或者落盘后再确认避免断电导致数据损坏。容器镜像本身是只读层重启后能恢复到干净状态业务数据走数据卷持久化这是推荐的方式。日志策略也容易被忽略。AFC设备长时间运行日志文件会非常大。我建议容器里只输出日志到stdout由统一的日志采集进程收集到数据卷并做日期分片和保留策略例如保留30天或按大小滚动。这样既方便排障也不会撑爆存储。3.5 交付前的验证清单这些坑别等到现场才发现设备在实验室跑得好好的一到现场就各种幺蛾子这是国产化工控项目里最常见的翻车方式。为了避免这种局面我总结了一份交付前的验证清单每一条都来自真实教训。反复开关门测试闸机扇门每天开关几百上千次主控板在反复电机冲击下会不会复位一定要提前跑满24小时循环测试。连续压力测试业务系统全负载跑72小时以上观察内存泄漏、容器重启次数、日志增长情况。断电恢复测试在业务写入的高峰期突然断电再上电确认系统和业务能自动恢复数据不损坏。温度环境测试有条件的话做高低温箱测试模拟站厅极端温度确认系统不会因为过热降频导致闸机反应迟钝。远程更新演练模拟现场设备需要远程升级的场景确认镜像拉取或者离线升级包能稳定执行升级失败能回滚。这些测试如果等到项目交付后再补成本会高到让人怀疑人生。我见过一个项目闸机装到站点之后才发现主控板在高温下会随机重启最后只能全部返厂改散热方案工期和成本全部失控。提前做验证永远是最划算的投入。4. 常见问题与排查技巧实录这一节我整理了一份开发龙芯过程中最常见的故障和处理方法每一条都是自己或者团队在项目里真实踩过的。如果你在项目中也遇到相同问题可以对照排查。4.1 故障速查表现象可能原因排查与修复uname -m 输出异常系统架构判断错误确认输出为loongarch64如果显示其他架构说明系统装错了docker pull 报 manifest unknown镜像仓库没有对应loong64架构标签切换到cr.loongnix.cn等提供loongarch64镜像的仓库某镜像在x86能跑龙芯上报错镜像架构不匹配检查镜像架构尽量拉取loongarch64原生镜像容器里访问串口失败没有把设备映射进容器启动加--device/dev/ttyS4:/dev/ttyS4参数开机后服务没有自动启动systemd或docker自启配置问题检查enable状态、docker restart policy、依赖关系业务进程段错误编译选项或依赖库版本问题确认编译工具链目标架构在龙芯实体机重编系统温度过高触发降频散热设计问题优化机箱风道增加温度监控调整耗CPU任务调度4.2 几个隐藏很深的坑第一个坑是我反复强调的不要在龙芯上用通用安装脚本装Docker。网上流传的快速安装Docker脚本基本都按x86_64架构写死执行完看起来装上了实际上Docker的client或daemon根本无法启动或者报一些莫名其妙的错。一旦遇到docker命令不存在、docker version显示不出server信息先检查自己是不是用了通用脚本然后全部卸载改用系统自带的loongarch64仓库安装。第二个坑交叉编译链和内核版本不匹配。这个特别隐蔽。我们曾经编译一个内核模块在开发机上用的交叉编译链版本偏高编出来的模块在目标板上一加载就报invalid module format。后来换回与内核配套的编译链版本才通过。所以一定要记录内核版本和交叉编译链版本把它们当成一套组合来看待不要单独升级其中一项。第三个坑Java应用莫名其妙崩溃不是代码问题。有同事把x86上编好的JNI原生库拷贝到龙芯上应用启动就崩。查了很久问题出在这个原生库是x86架构编译的。Java字节码是可移植的但JNI库不行。还要确认Lombok、Netty这些框架是否支持LoongArch某些框架版本过旧在LoongArch上会有不自洽的问题升级版本通常能解决。第四个坑设备树里串口别名和外设实际编号对不上。在AFC项目里我们通过/dev/ttyS4接读卡器结果容器映射之后发现ttyS4根本不是读卡器的那个串口。原因是内核设备树中串口别名分配和外设插槽的物理关系跟预期不一致。排查方法是在主机上先用stty和loopback短接法确认每个ttyS对应哪个物理串口再决定容器映射。做这一步成本很低但能省下一个下午。4.3 一句话经验合集写在这里的几句话是我做完项目沉淀下来最有用的复盘龙芯平台的坑90%出在架构不匹配上排查时第一时间确认架构别先怀疑业务代码。常用基础镜像、关键组件版本在项目启动阶段就要固定下来做成公司内部的基础镜像仓库版本漂移会毁掉整个项目的可维护性。所有设备的远程管理凭据、镜像仓库、机柜IP都要落到文档里。AFC项目建设周期长设备散在各地没有文档就是灾难。国产化平台的应用移植不要指望一条命令跑通每次只修改一个变量逐项验证反而最快。5. 写在最后一些真实的体会最后说几句真心话。从第一次在龙芯2K1000上看到登录提示符到现在在龙芯2K3000上跑通完整的AFC业务系统前后跨度不短中间也想过放弃。国产化平台的初期确实比x86要麻烦资料少、软件包不全、遇到问题没人可问这是客观事实。但这两年我明显感觉到LoongArch生态已经不是能不能跑的问题而是怎么跑得更好的问题。Docker补齐了环境交付的短板社区和厂商也在持续跟进基础软件适配。龙芯的启动速度、工具链稳定性、方案的可复制性都比我预想中成熟得多。如果你是刚开始接触龙芯的工程师我的建议很简单先别急着铺大摊子找一块板子装上系统配好Docker把你手头最熟悉的那个小服务容器化部署上去。等你完成这个闭环你会发现原本以为会很艰难的国产化移植其实已经有了清晰的路径。我们团队现在的新人培训基本就是这条路线——龙芯启动从启动那一刻开始后面的一切就都有了着落。
