Author: longlong
This article is a full transcription of longlong’s speech at WHLUG, so there are some informal expressions. The content only represents personal views and positions.
As the successor to deepin 20, one of the biggest changes in deepin 23 is the addition of multi-architecture support: from originally only supporting the AMD64 architecture to now supporting multiple CPU architecture platforms including AMD64, RISC-V, LoongArch (New World), and ARM64.
Currently, the stable image for AMD64 architecture of deepin 23 has been released, while the images for other CPU architectures are still in the preview version stage as the ecosystem is being built. We will release the stable version for other architectures when we believe the quality meets the standard for a stable release.
ARM64
ARM64 was the first architecture introduced in deepin 23. When we started officially building the repository for version 23, ARM64 was already a primary target for support, and it is now one of the best-developed architectures apart from x86. Our support for the ARM64 architecture has also received backing from partners like Phytium and Zhaoxin Technology.
Main Build Cluster
When we were adapting deepin 23, we initially only had one FT2000/64 server. As the number of system packages grew to over 3,000, this build scale became far from sufficient. Moreover, ARM64 servers were not readily available on the market. Therefore, we took the initiative, searched through the company’s warehouse, and found a Kunpeng 920 server and five Pangu W510 desktops to form a build cluster.
Virtually No Ecosystem Barriers
The Linux ecosystem for ARM64 is almost on par with x86, and there is no need to worry about software compatibility. Almost all software packages that can be built on x86 can be compiled normally on ARM64.
UEFI Challenges
ARM64 was initially used mainly in embedded devices, so U-Boot was more common. However, U-Boot presented several issues when booting deepin 23, such as requiring different device tree binary files (DTBs) for different devices. This posed challenges for mainstreaming deepin 23. As a result, we currently only support UEFI-enabled devices like Phytium D2000/D3000, Kunpeng 920, and new products from Zhaoxin Technology. For other ARM64 devices, we can only offer limited support, as adapting different development boards requires significant manpower and resources. However, we welcome more ARM64 development boards and device manufacturers to collaborate with us, and we will do our best to adapt to them.
LoongArch
LoongArch (New World) was not initially within the scope of target architectures for deepin 23, but around 2022, as Loongson began actively promoting the New World distribution ecosystem, we decided to attempt adaptation for LoongArch systems. This decision was triggered by Revy, who sent us two LA50007A2000 machines.
From Loong Arch Linux to deepin Linux
We decided to build on the shoulders of giants, choosing the more mature LoongArch Linux as the foundation, rather than manually creating a root filesystem (rootfs) using the still-imperfect QEMU. Based on this, we built the rootfs and launched OBS workers, giving us the capability to build for LoongArch (New World). Meanwhile, Loongson firmware continued to improve, and the freezing issues were reduced.
Loongson 3C5000 Power!
Following the principle of “benefiting from a large tree’s shade,” we borrowed two four-way Loongson 3C5000L servers from a friendly department. These became our most powerful build servers. However, initially, they lacked support for New World firmware. After obtaining firmware from Loongson, we were able to use them (though the RAID card still couldn’t function properly under New World).
Our community also purchased a dual-way 3C5000LL server, which presented an unexpected issue: it came with New World firmware and BMC out of the factory, but when powered on, it emitted a loud “dragon roar” at maximum fan speed, loud enough to drown out all other servers in our machine room. Additionally, it was unstable, crashing almost daily. Eventually, we sought help from engineers at Wuhan Loongson. With their assistance, we discovered the cause: the motherboard has 8 four-pin fan sockets, and the new BMC checks whether the 1st, 2nd, 3rd, and 4th sockets are connected properly. If not, the BMC runs the fans at maximum power, causing overheating. However, the manufacturer of our server did not follow this order when connecting the fans, leading to the issue.
Later, we obtained more Loongson 3C5000 servers through UOS, greatly enhancing our build resources.
deepin Loong64 Booted!
Once everything was in place, we manually crafted the rootfs, packaged DDE, and created the first image. It successfully ran on the Loongson 3A5000. However, since we were unfamiliar with the special tuning of the Loongson kernel at the time, we borrowed the kernel from the neighboring Loong Arch Linux. As for the system software packages, most were sourced from our own system repository, with some borrowed from Revy.
3A6000 Performance Surge
In early 2024, Loongson released the 3A6000. Once again, Revy was the first to sponsor us with a 3A6000 motherboard. As with the earlier samples, this motherboard encountered various problems: crashes at startup, system freezes, PCIe instability, and so on. However, as the 3A6000 boards we purchased later, along with Asus 3A6000 motherboards, gradually resolved these issues, system stability greatly improved. Of course, we still had to complain about the GPU on the Loongson 7A2000 bridge chip. Due to the lack of stable and fully functional drivers, early performance was very unstable, especially when connecting to 4K monitors. We will work with Loongson to address this issue using official drivers—stay tuned!
Ecosystem Building
In terms of ecosystem building, the New World ecosystem of Loongson essentially started from scratch. Achievements from the Old World, such as UOS, could not be directly migrated to New World, though AOSC's libLoL helped alleviate some of the problems. To promote Loongson's ecosystem, we mandated that first-party applications must compile successfully on Loong64. As a result, you can now see that deepin's UnionCode (IDE) is running smoothly on Loong64, which is a great benefit to Loongson's developer ecosystem.
However, we still face issues, such as upstream’s arrogant attitude towards Loong patches, which has caused software like Neovim to be incompatible with Loong64. To solve this, deepin maintained the necessary patches to ensure Luajit runs smoothly on Loong64.
We currently maintain good relationships with various New World distribution communities, allowing us to access the latest technological developments and solve issues. For example, deepin 23 comes pre-installed with libLoL and supports booting New World systems on Old World machines.
When Will It Be Stable?
The issues preventing us from releasing a stable version of the Loong64 image are:
- The current app store is just an empty shell. For a distribution aiming for an out-of-the-box experience, this clearly does not meet the release standard.
- Our build resources are still insufficient. We cannot yet provide the same level of support as we do for ARM64. We are still heavily reliant on Loongson desktops as part of our infrastructure.
- The stability does not meet the release requirements. Loongson’s hardware, software, and firmware are evolving at a relatively fast pace, making it difficult to stabilize a version and guarantee reliable service for users. So, we are opting for rolling updates—let’s roll!
RISC-V
As for the RISC-V architecture, I have not personally been deeply involved. The support for RISC-V in deepin was mainly completed by our colleague Yang, who is currently at the RISC-V summit in Hangzhou, exchanging ideas with various experts. So, I will introduce the RISC-V adaptation situation on her behalf.
Boards: Tasteless but Hard to Discard
Our support for the RISC-V architecture actually began before Loong64. The PLCT team at the Chinese Academy of Sciences had already prepared a very early version that could boot to the desktop. However, the hardware we received was the Allwinner D1 board. After running Linux on it, I lost interest because its performance was far too weak. Compared to the similarly priced RK3566, it was vastly inferior in both performance and ecosystem. Why did we do RISC-V? Maybe for the innovation.
Sg2042: Chinese Violent Aesthetics in a RISC-V Processor
Later, Revy sent us two Sg2042 machines, each with 64 C910 cores from Pingtouge. These cores are also used in the TH1520 board. While the single-core performance was weak, the large number of cores compensated. We were even able to insert an AMD graphics card into the Sg2042: DDE booted!
Thanks to the Sg2042, we reached the threshold for batch building. With the two 2042 machines running in the server room day and night, our RISC-V ecosystem almost caught up to ARM64. Because RISC-V is generally more accepted upstream, even without stronger hardware, RISC-V continues to be supported by Debian’s main branch, which has greatly facilitated our adaptation efforts.
Embedded Limitations
Most of the RISC-V devices we encounter are still in the form of development boards, likely due to the early stage of RISC-V technology for desktop applications. This embedded-focused design philosophy has made the adaptation process challenging. This experience has made us realize that, to promote the use of RISC-V in desktop environments, closer collaboration with manufacturers is needed to explore and resolve the issues encountered during the adaptation process. Furthermore, it will take joint efforts within the industry to mature RISC-V technology and broaden its application.
That concludes this article. A huge thank you to all the teachers and partners who supported and helped us on deepin’s adaptation journey.
Releated Reading：
（1）deepin Full Version Image Downloads (including deepin V15)
（2）deepin RISC-V Architecture Image (LicheePi 44A, VisionFive2, etc.)
（3）deepin Multi-Architecture Compatible Model List
Content source: deepin community
Reprinted with attribution