全文引述 longlong 在 WHLUG 上的演讲，故存在口语化表达。本文仅代表个人观点和立场。
deepin 23 作为 deepin 20 的后继版本，最大的改变之一就是添加了多架构支持：从原本只支持 AMD64 架构，到目前支持 AMD64、RISC-V、LoongArch（新世界）、ARM64 多个 CPU 架构平台。
目前 deepin 23 已经发布了 AMD64 架构的 Stable 镜像，其他 CPU 架构的镜像还处于生态建设的 Preview 版本阶段，直到我们认为其质量满足正式版发版标准，才会发布 Stable 版本。
ARM64
ARM64 架构是 deepin 23 最早导入支持的架构，当 23 开始正式构建仓库的时候，其就作为主要架构支持目标，现在看来也是除了 x86 架构之外生态最好的架构。我们对于 ARM64 架构的支持也获得了合作伙伴：飞腾和此芯科技的支持。
主力构建集群
我们在做 deepin 23 适配的时候，只有一台 FT2000/64 服务器，当我们系统软件包增加到 3000+ 的时候，这样的构建规模远远不足以支撑构建。而且市面上也不是很好购买 ARM64 服务器。所以我们发挥了主观能动性，在公司库房寻宝，最后被我找来了一台鲲鹏 920 服务器，和五台盘古 w510 台式机，作为构建集群。
几乎不存在的生态屏障
ARM64 的 Linux 生态，几乎是比肩 x86 ， 无需担心软件是否适配的问题，几乎在 x86 上能构建的软件包在 ARM64 上都能正常编译。
通用启动的拦路虎
ARM64 初期的应用场景主要是嵌入式设备，所以用 U-Boot 的较多。但是 U-Boot 在启动 deepin 23 的时候就会有一系列问题，比如需要针对不同的设备使用不同的设备树二进制文件（dtb），这对我们 deepin 23 的主线化带来了挑战。所以目前我们的设备也仅适配了能支持 UEFI 的飞腾 D2000/D3000、鲲鹏 920 和此芯科技的新品。对于其他的 ARM64 设备可能只能提供有限度的支持，因为针对不同开发板的板形做不同的适配，对于我们的人力物力都是一个巨大的挑战。但是也欢迎更多的 ARM64 开发板和设备厂商与我们合作，我们尽力适配好。
LoongArch
LoongArch（新世界）最初并不在 deepin 23 的目标支持架构范围内，但在 2022 年前后，随着龙芯大力推进新世界发行版生态的进程，我们决定尝试适配 LoongArch 系统。这一决定的契机源于 Revy 老师寄来的两台 LA50007A2000 机器。
在我们决定开发新世界发行版之初，便面临着一个问题：硬件从哪里来？当时龙芯发布的新世界支持硬件仅有龙芯 3A5000 和 7A2000。由于新世界刚刚推出，7A2000 的桥片状态并不稳定，时常发生假死情况（即内核仍在运行，但不响应输入输出）。我们最初并不知情，直到 Revy 老师赠送给我们一台龙芯 3A5000 7A2000 新世界主机，并附带了一份长达三页的 PDF 文档，详细说明了龙芯硬件的各种问题，这让我们感到担忧。我也在 Revy 的影响下购买了一台 3A5000 主板，幸运的是，这块主板并未出现类似的问题。
从 Loong Arch Linux 到 deepin Linux
我们决定站在巨人肩膀上，选择成熟度较高的 LoongArch Linux 作为基础，而不是使用尚不完善的 qemu 手动制作 rootfs。在此基础上，我们构建了 rootfs 并启动了 OBS worker ，进而获得了 LoongArch （新世界）的构建能力。同时，龙芯的固件也在不断改进，假死情况有所改善。
Loongson 3C5000 Power！
本着 “靠着大树好乘凉” 的原则，我们去找我们的兄弟部门友好交流之后，借来了两台四路 Loongson 3C5000L 服务器，这也是我们最强的构建主力服务器。不过，在一开始的时候，它们没有新世界固件的支持。后来，我们找龙芯的人要了一份固件，才得以使用（当然，阵列卡依然没法在新世界下正常运行）。
而我们社区自己购买的 3C5000LL 双路服务器则出了一点意外：它出厂就自带新世界固件和 BMC，但在通电之后会以最高转速发出 “龙鸣”，其声音之大一度盖过我们机房所有的服务器，并且其运行也不是很稳定，几乎每天都会死机。这让我们感到无奈，只得求助于武汉龙芯的工程师的协助。在他们的帮助下，我们弄清了龙芯服务器发出 “龙鸣” 的原因：“其主板提供了 8 个风扇 4pin 的插座，新的 BMC 会检测 1，2，3，4 位的插座是否连接正常。如果连接不正常，BMC 会让风扇以最大功率运行，导致机器过热。但是，我们购买的主机厂商并不知道这回事，风扇并没有按照顺序插在 1，2，3，4 位上，导致了此现象的产生。
更多的 3C5000：后来，我们通过 UOS 获取了更多的龙芯 3C5000，极大地增强了我们的构建资源。
deepin loong64 启动！
在一切准备完善后。我们手搓了 rootfs ，将 DDE 打包完成，并且做出了第一版的镜像。在龙芯 3a5000 上成功运行，不过由于第一版本我们并不熟悉龙芯内核的特调，所以是从隔壁的 Loong Arch Linux 借用的内核。而系统软件包层面，基本是我们自己打包的系统源，也有部分是从 Revy 老师那 “偷” 的软件包。
3A6000 性能飞升
2024 年初，龙芯发布了 3A6000，Revy 老师又第一时间赞助了一块 3A6000 主板给我们。正如他之前给我们的那些早期样品一样，这块主板遇到了各种问题：开机即死机、系统假死、PCIe 不稳定等。不过，随着后期我们购入的 3A6000 主板和华硕的 3A6000 主板问题逐步得到缓解，系统的稳定性有了很大提升。当然，还是得吐槽一下龙芯的 7A2000 桥片自带的 GPU，因为缺乏稳定和功能完整的驱动，其早期表现非常不稳定，尤其是在外接 4K 显示器时，几乎无法显示，后续我们会和龙芯合作，使用官方驱动解决这一问题，尽情期待。
生态建设
在生态建设方面，龙芯的新世界生态可以说是从零开始。UOS 等基于龙芯旧世界的成果无法直接迁移到新世界上，虽然 AOSC 的 libLoL 出现缓解了部分问题。为了推进龙芯的生态，我们也要求第一方应用必须能在 loong64 上编译通过。所以，现在大家可以看到，deepin 的 unioncode（IDE） 已经能够在 Loong 上正常运行，这无疑为龙芯的开发者生态带来了极大的好处。
然而，我们仍面临一些问题，比如上游对 Loong 补丁的傲慢态度，导致如 neovim 等软件无法在 loong64 上运行。为了解决这个问题，deepin 自主维护了相关补丁，使得 luajit 能够在 Loong 上顺利运行。
目前，我们与各个新世界发行版社区保持着良好的关系，方便获取最新的技术成果并解决疑难问题。比如 23 预装了 libLoL 和在旧世界机器上启动新世界系统的的支持。
何时 Stable？
阻挡我们将 loong64 架构的镜像 stable 的问题在于：
1、目前应用商店还只是一个空壳，作为一个目标就是开箱即用的发行版来说，这个肯定达不到发版本的标准。
2、目前构建资源还是匮乏，没办法做到和 ARM64 同等的构建资源支持，我们目前还在大量使用龙芯台式机作为构建的基础设施。
3、稳定性不满足发版本要求，因为龙架构无论是硬件软件固件都在一个相对快的迭代过程中，很难在某一个时间点去 stable 一个版本，而要求这个版本能稳定的向用户提供服务，所以我们不发 stable 版本，咱一起滚动更新（let‘s roll！）
RISC-V
对于 RV 架构，其实作为个人我参与的不多，deepin 对于 RV 架构的支持，主要在我们的杨同学完成，此时她还在杭州的 RV 峰会上和各位大佬交换意见。那我就代为介绍我们的 RV 适配情况。
板子？食之无味，弃之可惜
我们对 RV 架构的支持实际是早于 loong64 的，中科院 PLCT 团队在我们做主线化支持之前就已经做好了一套非常早期的版本，并且可以启动到桌面，然而那时我们获得的硬件是全志 D1，当时我拿了一个回去玩，跑起了 Linux 之后就再也不想动它，让它吃灰去了，因为性能实在是太弱了，和同样价格的 rk3566 相比，无论是性能，生态，都远远不及。为啥我们要做 RV，可能是因为创吧。
其实我们一开始拿到的开发板也不止全志 D1 还有 TH1520：只能说是能用，但是用不了一点。性能依然堪忧。
所以在我们只有板子的状态下，也没法去做适配，只能用 qemu 手搓 rootfs ，跑起来了内核和 tty，但是全功能的 dde 由于性能问题，是跑不起来的（吐槽：就算适配了看全志 D1 这个样子，似乎也跑不动 dde)
Sg2042 中式暴力美学的 RV 处理器
后来 Revy 给我们弄来了两台 Sg2042 的机器，每一个 Sg2042 使用的是 64 个平头哥 C910 核心，而这个核心同样用在 TH1520 的板子上。虽然单核很弱，但是耐不住它核心多啊。咱就靠堆核，也做到和 PC 级别的性能，至少我们可以在 sg2042 上插一个 AMD 信创神卡了：DDE 启动！
因为 sg2042 的出现，我们已经大概够上了批量构建的门槛了，两台 2042 在机房日夜不休的构建下，我们的 rv 生态几乎追平 ARM64。因为 RISC-V 在上游接受度普遍较高，即使没有比较强的硬件出现，rv 依旧被 Debian 的主线支持，这也极大的方便了我们进行适配。
从笔记本到遥控车：探索 RV 的更多形态
而后我们接触到更多的 RV 设备，（再次感谢各位 RV 厂商的投喂）包括且不限于笔记本，平板，甚至是遥控车这类稀奇古怪的玩意。这样我们接触的设备就不仅限于 EVB 了。这些设备虽然五花八门然而使用的无非那么几种核心，各有各的毛病，现在也还没有一个设备能符合我们测试组的要求的。
GPU：RV 生态的拦路虎
我们对于 RV 生态的构建，其实是非常具有信心的，但是在桌面的支持上我们始终无法忽略 GPU 这个因素。因为 RV 大部分厂商一直以来，未来也将持续把重心放在嵌入式领域，有 PCIE 插槽的设备寥寥可数，寄希望于插一块 AMD 亮机卡就能带动桌面的打算基本上泡汤了。
于是摆在我们面前的问题就是 RV 的板载 GPU，它不仅不支持桌面的 GL，只支持 GLES，还没有开源驱动，只有魔改版 mesa，要我们适配它，意味着我们要往系统里面塞一坨不受包管理的脏东西。
于是后来我们便修复了 RV llvmpipe 试图先扔掉这个残废 GPU 直接使用软件渲染，奈何效果不佳，毕竟 DDE 主打的一个特效好看，关闭特效之后完全没法用。
最后在高人指点下，我们采用了 GLVND 方案实现了开源驱动和闭源驱动的依赖共存，勉强地把它们都纳入到了包管理，这才有了我们现在稍微正常一些的桌面体验。
嵌入式的局限性
在当前的 RV 设备适配领域，我们所接触的大多数产品依然是以开发板的形式存在。这可能是因为对于 RV 技术来说，桌面应用的普及尚处于早期阶段。因此，这种嵌入式设备的设计理念一直影响着我们的适配工作，使得适配过程充满了挑战。这段经历让我们深刻认识到，为了推动 RV 技术在桌面环境中的应用，我们需要与厂商更紧密地合作，共同探索和解决适配过程中遇问题。同时，也需要行业内的共同努力，以促进 RV 技术的成熟和广泛应用。
以上便是本文所有内容了，感谢所有在 deepin 适配道路提供支持和帮助的老师和伙伴们。
