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