龙芯嵌入式:菜鸡大学生折腾Loongarch32嵌入式记
工欲善其事,必先利其器。这篇Blog将着重介绍如何从零开始构建一个loongarch32-unknown-elfsf目标的工具链,并利用其构建一个龙芯1C102单片机的点灯程序。
💡 下文若未特殊指定,默认 Host 主机架构为
x86_64-linux-gnu。
在目前(2026年1月2日),GCC 官方仍然没有合并 Loongarch32 平台目标的分支,因此,我们只能找到 GCC 16.0 的源代码,并 patch 上 Loongarch32 平台的补丁。对于 binutils 和 libc,我们则可以很轻松地找到官方或第三方支持 Loongarch32 平台的分支,对于 picolibc 来说,官方甚至就已经支持了该平台。
笔者找到的 gcc 源代码主要来自三个途径:第一是龙芯官方发布的源代码包,第二是 gcc 官方的不稳定分支,第三是龙芯开源社区提供的预编译的工具链以及 patch 过的 gcc 源代码。
龙芯官方工具链存在的“玄学”问题
我们首先就 LoongIDE 上的工具链进行研究。根据工具链的文件名来看,该工具链的编译目标为 loongarch32-newlib-elf ,甚至不是一个标准的三元组;且对于任何一个可开发的目标(龙芯 1C102, 1C103 等 MCU)来说,该类 MCU 皆是软浮点,并不具备 FPU 浮点寄存器,而 loongarch32-newlib-elf 目标却隐式指定该目标为双精度浮点,这可能并不是我们所想要的。
为了验证该工具链的可用性以及获知编译该工具链时指定的编译选项,笔者开了一个 Windows 7 虚拟机。但经过笔者的测试,在龙芯官方演示该 IDE 所使用的 Windows 7 旗舰版环境之下,loongarch32-newlib-elf-gcc.exe 几乎无法运行,或者该程序编译时本身存在问题,使得运行时根本不会产生输出,且后期笔者进行了一些深度测试,可以确定的是该工具链根本不具备编译能力。
后来,笔者又通过龙芯开发者社区获取到了某一较为流行的工具链。然而,根据该工具链的文件名与编译输出,我们却发现:该工具链的编译目标似乎并非是裸机,而是loongarch32-linux-gnuf64 。因此,根据社区上的信息以及笔者的测试,我们可以得到下面三个结论:
- 龙芯单片机所需编译器的三元组并不唯一,且可能的匹配情况非常多;
- 龙芯单片机本身的链接过程可能并不会涉及到 libc 的启动代码与
_start段; - 在刷写程序时,是否为软浮点或硬浮点对程序本身并不会产生影响。
因此,在指定编译工具链时,我们或许并不用考虑 ABI 浮点的情况,但为了程序未来可能会需要的稳定性,我们应当编译一个裸机的、软浮点的 ELF 工具链,对应的三元组应当为 loongarch32-unknown-elfsf。
💡
loongarch32-unknown-elf仍然为双精度浮点,为了采用软浮点,我们应当采用loongarch32-unknown-elfsf。这不是一个标准三元组,但在 gcc 16.0 版本中,官方的 configure 脚本已经弃用了 ABI 的显式指定,因此,我们必须通过该三元组指定软浮点 ABI。
且由于我们采取了交叉编译的方式,我们必须将编译分为四个阶段( Stages ):
- Stage 0. 编译 binutils,得到汇编器、链接器与其他重要工具;
- Stage 1. 编译一个初步可用的 GCC,用于编译libc;
- Stage 2. 使用 Stage1 获得的 GCC,编译 picolibc;
- Stage 3. 使用 Stage2 获得的 libc,重新编译 gcc,并链接 libc。
binutils 的编译( Stage 0 )
经过笔者的测试,官方分支的 binutils 的 configure 脚本根本无法识别 loongarch32 架构。我们使用社区上已经打好了 patch 的一个 binutils-gdb 分支:
1 | git clone https://github.com/cloudspurs/binutils-gdb |
运行 configure 脚本,配置 binutils 的编译选项:
1 | ../binutils-gdb/configure --target=loongarch32-unknown-elfsf \ |
这里的 —disable-multilib 是为了禁用多架构选项。
若脚本运行无误,我们直接开始编译:
1 | make -j32 |
然后,我们在 /opt/loongarch32-unknown-elfsf/bin 中就可以找到 binutils 以及 gdb 的可执行文件了。同时,为了方便接下来的操作,我们还需要将该路径添加进 PATH 中。
GCC (仅 C 编译器)的编译( Stage 1 )
这里,我们使用第三方打上了 Loongarch32 patch 的 GCC 分支:
1 | git clone https://github.com/cloudspurs/gcc |
由于此时我们根本没有 libc,我们无法得到 C++ 的标准库 libstdc++ ,因此在本阶段内我们只能编译一个最基本的 C 语言编译器,且该编译器几乎完全不可以用于链接,只会用到预处理、编译、汇编这三个步骤。因此,我们不需要保证生成的文件是可执行文件,只需要保证生成的文件对应的汇编指令是正常编译而来的,且静态库之间可以相互链接即可。
1 | ../gcc/configure \ |
我们这里启用了 —without-headers ,是为了防止编译器将我们 Host 平台的头文件当成了目标平台的头文件,从而导致我们不希望出现的链接错误。且我们禁用了大量 GCC 编译时可能会顺带着一起编译或链接的库,仍然是因为在 Stage 1,我们并不具备编译这些库的能力,因为我们甚至连 libc 都没有。在配置 GCC 编译选项时,我们仍然启用了 —disable-multilib ,禁用了其他架构的编译选项,从而保证我们编译出的文件更加具有专一性,在 Stage 2 编译 libc 时,把因为架构问题出错的可能性进一步降低。
若脚本运行无误,我们直接开始编译:
1 | make -j32 |
由于我们禁用了太多编译时可能会顺带着编译进去的库或其他支持,整个编译过程只会持续大约十分钟左右。接下来,我们便可以在 /opt/loongarch32-unknown-elfsf/bin 中找到 GCC。
Picolibc 的编译( Stage 2 )
经过了 Stage 1,我们获得了一个具有初步功能的 GCC,同时也具有了初步编译的能力。为了获得一个具有完整功能的 GCC,我们就必须编译一个 libc,使得 GCC 能够正常完成链接。由于我们的开发对象的 FLASH 体积较小,且开销有限,我们选择比 newlib 更为轻量的 Picolibc。且 Picolibc 官方已经将 Loongarch32 平台的支持合并进入主线,而 newlib 则仍然没有合并。因此,在这里,我们直接使用 Picolibc 的官方分发即可。
1 | git clone https://github.com/picolibc/picolibc |
为了编译 Picolibc,且由于 Picolibc 使用了 meson 构建系统,我们还需要配置交叉编译选项。
1 | vim ../picolibc/cross.tmpl |
将其修改:
1 | [binaries] |
修改后开始配置编译选项并使用 ninja 进行编译:
1 | meson setup ../picolibc \ |
但是最终出现了报错:
1 | FAILED: [code=1] picocrt/crt0-semihost.o.p/machine_loongarch_crt0.c.o |
笔者推测,这极有可能是因为 Loongarch32 的各个编译系统仍然处于上游测试期,Picolibc 对 Loongarch32 平台的汇编支持并不是特别完善。但是我们也注意到,报错原因在于 CFI 表达式的使用方式出现了问题,而 CFI 表达式本身则是用于 Picolibc 的调试,且我们在编译的时候很可能并不会用到 Picolibc 的启动指令,而是我们自己写的 _start 段。如果去掉,影响可能不会特别大。因此,我们尝试直接修改 ../picolibc/picocrt/machine/loongarch/crt0.c ,并去掉其中的所有 CFI 段。
1 | vim ../picolibc/picocrt/machine/loongarch/crt0.c |
1 | /* |
再次运行:
1 | ninja |
现在没有报错了,且我们的 libc 已经正确地安装到了目标位置上。
完整 GCC 的编译( Stage 3 )
现在,有了 libc,我们已经具备了编译 C++ 标准库乃至其他运行时库的能力。
1 | mkdir gcc-final |
配置编译选项:
1 | ../gcc/configure \ |
在这里,我们仍然禁用了线程,因为它需要借助 glibc 以及 Linux 用户态,然而这在我们的开发对象上是几乎完全不可能实现的。且我们将 Picolibc 的安装位置设置为了 sysroot,这是为了告诉编译器需要在这个路径之下寻找链接库。我们直接开始编译并安装:
1 | make -j32 |
在经历了大约二十分钟左右的编译之后,完整的 GCC 就被安装在了交叉编译工具链的路径上,至此,我们的交叉编译环境就算是搭建完成了。
总结
通过交叉编译工具链的构建过程中发现的种种社区现象,我们可以得出下列结论:
- 龙芯嵌入式的开发在 x86_64 平台上的支持仍然较少,大多数软件仍然在 Loongarch64 平台上;
- 龙芯嵌入式在软件方面并不存在一个官方统一的工具链或硬件抽象层(HAL),配置起来相当麻烦,但也给这个架构带来了相当大的可玩性;
- 龙芯的软件平台虽然在适配 x86_64 架构这方面存在着强大的社区支持,但在 x86_64 架构上的反适配却支持明显不够。
龙芯架构的 MCU 虽然有着可观的参数,但它所具备的软件支持却远远不足。笔者也因为该原因,在该平台上开发时必须手写一份 HAL,存在着极大的不便,但也使得笔者的能力得到了进一步提升。至于龙芯架构的开发方式,笔者决定于下一个 Blog 进行深入讲解。