deepin 实现多架构适配的背后,我们做了什么?

  全文引述 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 适配道路提供支持和帮助的老师和伙伴们。