I currently have Deepin 20.8 running on two different machines. On the Huawei laptop with SSD drive, Deepin works as fast as Windows 11. BUT on the other system with traditional spinning hard disk and old Intel Core i5 CPU, deepin runs 2x slower than Windows 7. I cannot use it on the older system as a work machine, only to watch movies and stream TV shows.
This leads me to think Debian sucks. Deepin needs to be built on top of something that performs better than Debian. So, I am wondering, why doesn't Deepin already begin development on OpenHarmony? I been hearing good things about the OS like how it performs better than Google Android! RISC-V sounds risky. Unless there is already a BIG company doing it, Deepin shouldn't go into that territory yet. I can imagine it only takes a few developers to port the DDE to OpenHarmony...
- 7 days
- 30 days
- 90 days
Realize deepin for RISC-V, our adaptation journey!
In the released V23 alpha version, deepin is officially adapted to RISC-V!
The RISC-V instruction set is an open instruction set architecture (ISA) based on the principle of reduced instruction set computing (RISC), and RISC-V is a new instruction established on the basis of the continuous development and maturity of the instruction set. The RISC-V instruction set is completely open source and simple in design. It has a modular design, a complete tool chain, easy to transplant Unix systems, and a large number of open source implementations and tape-out cases.
Today, we will lead you into our adaptation journey from the aspects of the initiation and selection of solutions, how to solve the problems in the adaptation process, and the realization of core goals!
If you want to adapt to a brand new architecture, you need to start from the lowest system components and gradually adapt. So in the initial plan, we planned to build the entire system warehouse from the bottom up, first use the cross-compilation tool chain to build the underlying libraries such as gcc and glibc, and then use the cross-compiled tool chain to complete the self-build, and then Build the upper layer software sequentially.
However, in the internal discussion of the group, this plan was finally rejected. According to rough statistics, the warehouse needs to adapt at least 6500+ software packages to achieve a relatively complete dependency tree. A large number of software packages require at least three rounds of repeated construction to ensure that the dependency tree is correct. At the same time, there are also errors in the construction of many software packages. Such errors account for about 40% of the total. They are usually caused by problems such as dependency problems, unit test failures, and RISC-V architecture failures.
On this basis, the success rate of batch compilation using the cross-compilation toolchain is low, and the construction rules of a large number of software packages are different: some need to identify the architecture type, and some need to rely on a specific environment... It may take several months to solve the above problems. Therefore, it seems difficult to achieve the goal within the expected time. On the one hand, these problems mentioned above, on the other hand, due to the limited time, it is difficult to deal with so many problems.
Since "time-consuming" has become a key issue, is there a way that is both reliable and time-consuming? This is about a series of considerations before we come to the final solution.
Before we start adapting, many Linux distributions have completed RISC-V support, such as Debian, Ubuntu and other well-known distributions.
The core of deepin is mainly DDE and various applications. The underlying software package is similar to Debian. Therefore, in order to see the effect as soon as possible, we can first adapt DDE and other upper-level software from top to bottom to provide a usable graphics environment. In this way, after we complete the initial adaptation, more developers can participate in discovering and fixing problems, and subsequent warehouse refactoring can also be carried out simultaneously.
So we plan to use this system warehouse to adapt upper-level software such as DDE based on Debian first, and build the RISC-V 64 version of the deepin system warehouse while adapting them. Before the system warehouse is completed, you can use the Debian+DDE version to perform functional testing and repair on the RISCV device. Finally, after the system warehouse is completed, you can reuse the adapted DDE and various upper-layer software, which can save a lot the adaptation time. In addition, after group discussion, we decided to adapt the RISC-V architecture of the system base library by means of cross-compilation and qemu simulation. Part of the compilation tool chain is built by cross-compilation, and a usable basic base environment is first guaranteed to be built. The rest of the system basic library and upper-level applications are built by qemu to simulate the RISC-V architecture.
Although this solution also has problems, such as the low efficiency of the qemu simulation method and the slow compilation speed of large-scale software, etc., qemu can more easily use x86 and other architecture machine nodes to perform batch compilation tasks, and the proportion of compilation errors It also dropped to about 25 percent. Moreover, this solution can also use multiple nodes to build in parallel to speed up the time required for construction.
After comparison, the qemu simulation solution is obviously more in line with our needs.
After the final solution was determined, we went through several rounds of repeated construction, and finally reached the requirement of self-compilation. So far, we have obtained a usable compilation environment, but as mentioned before: the huge number of software repositories brings many difficulties to our adaptation tasks. In addition to the urgency of time, it is also difficult to handle so many compilation tasks with our existing manpower.
Based on this demand, we have developed batch compilation scripts, automatic dependency analysis scripts and other tools to assist in the completion of batch compilation.
A variety of tools can assist us with compilation tasks and speed up the process of the project. But even so, there are still many problems. In this process, we still encountered many problems that cannot be solved by script tools, such as: some software packages lack the support of RISC-V architecture due to the version option of the basic software; various errors encountered during the construction process Resulting in build failures and so on.
The series of problems mentioned above cannot actually be solved by automated tools. For example, among a large number of build errors, some are missing dependencies and some are compilation errors, all of which need to be handled manually. And some of the more common problems, due to space reasons, we do not describe more. Next, we will mainly talk about the realization of our core goals.
Achieve core goals
As one of the core components of our system, the importance of the DDE desktop environment is self-evident, which is why we regard it as the "top priority". After overcoming difficulties and dealing with various problems, we finally started the construction of the core goal - adapting the DDE desktop environment on the RISC-V platform.
Compared with the previous difficulties, the process of building the DDE desktop environment is much smoother. Except for individual software packages that need to modify codes and build scripts, there are no serious problems to deal with. As long as the dependencies of the warehouse are complete, basically everything can be built.
So far, we have completed two rounds of compilation of most software packages, ensuring that all self-developed applications are built and most applications can run normally. Due to issues such as the lack of open source GPU drivers for RISC-V devices at this stage, some RISC-V devices cannot play video. For this reason, we have also specially adapted the soft solution solution of RISC-V architecture for theaters.
At present, the software package in the warehouse is based on the source code, and 6511 software package adaptations have been completed, and this number is still growing. In this process, I would like to thank the small partners of PLCT for their participation and making a lot of contributions to our RISC-V adaptation work. I would also like to thank the small partners in the RISC-V sig group of the Dragon Lizard community for their guidance, answering many questions and providing solutions for us.
At this point, after solving various problems, we can finally see the effect on the hardware platform!
Regarding the RISC-V hardware platform, we have adapted two boards, one is Ali's shadow 152
0 platform, one is the StarFive VisionFive V1 board, the following is the running effect on the Suiying 1520 platform!
StarFive VisionFive V1 and Shadowing 1520 platform
The running effect of the shadow 1520 platform
Pingtouge TH1520 Light-a RISC-V image download: https://cdimage.deepin.com/RISC-V/TH1520-image/
Download the image of Saifang Technology VisionFive v1 RISC-V: https://cdimage.deepin.com/RISC-V/VisionFive-v1-image/
I am also very grateful to the RISC-V SIG group of the Dragon Lizard community, the Institute of Software of the Chinese Academy of Sciences, and the partners of T-HEAD for their support and help during the RISC-V adaptation process.
In the V23 Alpha stage, we have completed the initial adaptation of RISC-V, but there are still many problems to be solved. For example, some applications fail to run, some functions have problems, etc. These situations need to wait for subsequent iterative optimization. On the hardware platform, the video interface and related drivers are not uniform, lack of open source graphics card drivers, and the dependency tree of the warehouse is not complete, etc. It needs to be refactored to solve the problems of some software package dependencies and the lack of third-party applications in the warehouse.
At present, we are gradually migrating the development environment to github. The deepin-community organization is also planning to build related workflows to support RISC-V adaptation requirements. In the future, we plan to adapt more mainstream RISC-V devices.
If you want to build a RISC-V ecosystem, it cannot be easily achieved by a few software developers. This also requires the support of major communities, the participation of major hardware manufacturers, the use of unified standards and standardized interfaces to develop software and hardware products, and providing a unified development interface for community developers. Through continuous optimization and iteration, RISC-V Ecology can be gradually improved.
Therefore, we sincerely hope that the adaptation of deepin can inject new vitality into the RISC-V community, and we also hope that more developers can join the RISC-V SIG group and work with us to contribute to the development of the open source software ecosystem. Perfect and work hard!
welcome to discuss with us：