在无MMU的RISC-V MCU上移植Linux 6.10内核：基于HPM6360的实践指南

1. 项目概述：为高性能MCU移植Linux的探索

作为一名长期在嵌入式领域折腾的开发者，我对各种高性能微控制器（MCU）总抱有浓厚的兴趣。HPMicro的HPM系列MCU以其出色的主频和丰富的外设，在圈内一直有“性能小钢炮”的名声。很早就萌生过一个想法：能否在这类资源相对受限但性能强劲的MCU上跑起Linux呢？这听起来像是个“螺蛳壳里做道场”的挑战，但乐趣也正在于此。传统的思路往往依赖于内存管理单元（MMU）来实现Linux所需的内存虚拟化保护，而多数MCU并不具备MMU。转机出现在Linux 6.10内核，它正式加强了对RISC-V架构在监管者模式（S-mode）下运行无MMU（nommu）内核的支持。这就像打开了一扇新的大门，让我下定决心，拿起手边的HPM6360开发板，开始这段将Linux移植到高性能RISC-V MCU上的实践之旅。

这个项目的核心目标非常明确：在HPM6360这颗基于RISC-V架构的MCU上，成功引导并运行一个功能完整的Linux系统。这不仅仅是把内核镜像烧录进去那么简单，它涉及到底层引导流程的重新设计、硬件缺陷的软件弥补、以及一整套运行时环境的构建。整个过程就像为一位“武功高强但招式独特”的侠客量身定制一套内功心法和武器，使其能施展出Linux这套复杂的“拳法”。最终，我们不仅实现了启动，还看到了可观的CoreMark跑分和内存带宽测试数据，证明了其可行性。无论你是对RISC-V架构感兴趣，还是想深入理解嵌入式Linux的启动精髓，亦或是正在寻找在资源受限平台部署Linux的实践方案，这次折腾的经历和踩过的坑，或许都能给你带来一些参考。

2. 核心思路与架构选型解析

2.1 为何选择RISC-V与nommu Linux？

首先得厘清一个基础问题：为什么是RISC-V和nommu Linux的组合？这源于硬件特性和软件生态的交汇。HPM6360采用基于RISC-V指令集的Andes D45核心，这是一颗支持机器模式（M-mode）和监管者模式（S-mode）的处理器。RISC-V特权架构的清晰分层（M/S/U）为系统软件提供了天然的隔离框架。然而，该核心没有集成内存管理单元（MMU），这意味着无法使用传统的、依赖虚拟内存的Linux内核。

幸运的是，Linux社区一直维护着CONFIG_MMU=n的配置选项，即nommu支持。这类内核运行在物理地址空间，省去了虚拟地址转换的开销，但同时也失去了内存保护、按需分页等高级特性，对应用开发提出了更苛刻的要求。Linux 6.10版本对RISC-V nommu的增强支持，正是我们这个项目得以启动的软件基石。它意味着内核本身能更好地适配在没有MMU的RISC-V硬件上启动和运行，减少了我们前期需要打补丁的工作量。

2.2 启动流程对比：ARM vs. RISC-V

理解启动链是移植工作的第一步。对比熟悉的ARM架构，能帮助我们快速抓住RISC-V启动的特殊性。

在典型的ARM Linux启动中，流程通常是线性的：芯片内部的ROM（BootROM）上电后，初始化最基本的环境，然后加载第一级引导程序（如U-Boot SPL）。SPL进一步初始化DRAM等关键硬件，再加载完整的U-Boot。U-Boot负责更全面的硬件初始化、加载设备树（DTS）、最终加载并跳转到Linux内核。内核接管后，U-Boot的任务就完成了。

而在支持S模式的RISC-V架构中，流程多了一个常驻的“管家”角色。其标准启动流程为：

1. Boot ROM：芯片固件，进行最底层的芯片初始化。
2. Loader：相当于ARM的SPL或U-Boot，负责初始化SDRAM等关键硬件，并加载下一阶段固件。
3. SBI Runtime：这是RISC-V特有的监管者二进制接口运行时。它被Loader加载到M模式并运行，之后常驻后台。
4. 操作系统内核：SBI Runtime将系统控制权移交给运行在S模式的Linux内核。
5. 用户程序：运行在U模式。

关键区别就在于SBI Runtime。它不像U-Boot那样“功成身退”，而是作为一个永久的底层服务存在。内核在运行过程中，会通过发起ecall指令陷入M模式，调用SBI Runtime提供的服务，例如定时器、IPI（处理器间中断）、复位等。这种设计实现了特权级的隔离和功能的模块化。

2.3 为什么是RustSBI？放弃U-Boot的考量

明确了需要SBI Runtime后，接下来就是选型。常见的SBI实现有OpenSBI、Berkeley Boot Loader (BBL)等。本项目选择了RustSBI。RustSBI是一个用Rust语言编写的SBI规范实现，它并非一个完整的引导加载器，而是一个库（crate）。开发者可以基于它，编写针对特定平台的引导代码。

选择RustSBI主要基于以下几点考虑：

1. 可定制性强：作为库，它允许我们深度定制引导阶段的硬件初始化逻辑，非常适合HPM这种启动流程相对特殊的芯片。
2. 代码质量与安全：Rust语言的内存安全特性，减少了底层固件开发中常见的指针错误，提升了可靠性。
3. 活跃的社区与规范支持：它紧跟RISC-V SBI规范（支持v2.0），并且社区活跃。

那么，为什么没有采用更常见的“U-Boot + OpenSBI”组合呢？这需要对HPM芯片的启动特性做具体分析。HPM系列芯片通常通过XPI（eXecute-In-Place）接口从外部Flash启动。其BootROM已经完成了XPI控制器的初始化，并将Flash映射到了固定的内存地址（如0x8000_0000）。这意味着，对于简单的引导场景，我们不需要一个复杂的、支持多种存储设备的U-Boot来重复初始化XPI。

基于此，项目决定不移植U-Boot，而是采取更轻量直接的方案：基于RustSBI库，编写一个专用于HPM6360的Bootloader。这个Bootloader需要完成以下几项核心工作：

• SDRAM初始化。
• 从XPI Flash加载Linux内核镜像和设备树到SDRAM。
• 将设备树地址等启动信息传递给内核。
• 跳转到内核入口点，并将控制权移交。
• 同时，它集成的RustSBI库将作为SBI Runtime常驻，为后续的Linux内核提供服务。

这样设计的优点是启动链条更短，镜像更小，启动速度理论上更快。最终的启动流程如下图所示，清晰地展示了从芯片上电到Linux内核运行的完整路径，以及RustSBI作为常驻服务的作用。

[HPM6360 上电] | v [Boot ROM] | (初始化XPI，映射Flash) v [自定义 Loader (基于RustSBI)] | (初始化SDRAM, 加载内核和DTB) v [RustSBI Runtime] <--- (常驻M模式，提供服务) | (跳转到内核，进入S模式) v [Linux Kernel (nommu)] | (通过ecall调用SBI服务) v [User Applications]

3. 关键挑战与解决方案深度剖析

移植过程绝非一帆风顺，遇到了几个硬骨头。这些问题直接关系到内核能否正常启动和运行，需要我们在Bootloader层面进行精巧的“手术”。

3.1 Zicntr扩展缺失：模拟TIME/CSR寄存器

第一个拦路虎是Zicntr指令集扩展的缺失。Linux内核（包括nommu配置）的计时和调度严重依赖一个名为time的CSR（控制和状态寄存器）来获取时钟周期计数。在标准的RISC-V架构中，这是通过Zicntr扩展提供的TIME和TIMEHCSR实现的。

然而，HPM6360使用的Andes D45核心并未实现这两个CSR。当内核执行csrr rd, time或csrr rd, timeh指令时，会触发非法指令异常（Illegal Instruction）。如果放任不管，内核会在启动早期就崩溃。

解决方案是进行“软件模拟”。我们在M模式的异常处理程序中拦截这个异常。具体步骤如下：

1. 捕获异常：当非法指令异常发生时，处理器会将触发异常的指令编码存入mtval寄存器。
2. 指令解码：我们需要解析这条非法指令。这里使用了riscv-decode这个Rust库。通过decode(mtval)函数，我们可以获取指令的详细信息，特别是操作码和CSR地址。
3. 判断与模拟：检查解码出的CSR地址是否为0xc01（TIME）或0xc81（TIMEH）。如果是，我们就需要“伪造”一个返回值。HPM芯片通常有一个名为MCHTMR的硬件定时器，其MTIME寄存器提供了类似的单调递增计数。我们将MTIME的值（或它的高32位）读出来，写入到目标rd寄存器中。
4. 恢复执行：手动更新mepc（异常程序计数器），使其指向异常指令的下一条指令，然后从异常返回。这样，内核软件“以为”它成功读取了time寄存器，实际上拿到的是我们提供的MTIME值。

注意：这里有一个关键细节是MTIME的频率需要与Linux内核配置的CONFIG_RISCV_M_TIMER_FREQ匹配。如果两者频率不一致，会导致内核的时间计算出现偏差。我们需要在设备树中正确设置timebase-frequency属性，并在Bootloader中确保MCHTMR按此频率运行。

3.2 SDRAM原子指令支持：模拟AMO与LR/SC

第二个挑战更为棘手：HPM6360无法在SDRAM地址范围内执行原子指令。当内核尝试在SDRAM中执行原子操作（如amoadd.w,amoswap.w）或lr/sc指令时，会触发存储/原子指令访问错误异常（Store/AMO Access Fault）。原子指令是实现锁、信号量等同步机制的基础，缺少它们，多任务Linux内核根本无法运行。

这个问题需要分两种情况处理：

情况一：AMO指令对于amoxxx系列的原子内存操作指令，处理相对直接。当此类指令触发异常后，流程与模拟TIME CSR类似：

1. 从mtval获取故障地址，从mepc获取指令地址并解码指令。
2. 在异常处理程序中，用软件逻辑模拟该原子操作：读取内存值，进行计算，再写回。这个过程必须是原子的，因此需要暂时关闭全局中断。
3. 模拟完成后，更新mepc指向下一条指令并返回。

情况二：LR/SC指令这对指令用于实现“加载-保留/条件存储”的原子操作，常用于实现自旋锁。它们的模拟非常特殊：

• lr指令执行时，会触发加载指令访问错误异常（Load Access Fault）。我们可以在异常处理中模拟lr：读取目标内存地址的值到rd寄存器，并在处理器内部（或软件维护的一个表）标记该地址为“保留”。
• 真正的难点在sc。当sc执行时，如果目标地址的“保留”状态仍然有效且未被其他硬件上下文破坏，则存储成功，rd寄存器被置为0；否则失败，rd置为1。关键在于，HPM6360上执行sc指令可能不会触发任何异常，而是直接返回失败（rd=1）。这导致我们无法在sc执行时介入模拟。

我采用的是一种“指令替换”的非常规方法：

1. 在模拟lr指令的异常处理中，除了完成加载和标记保留，还会向前扫描内存，寻找紧随其后的、对应同一地址的sc指令。
2. 找到后，将这条sc指令在内存中临时替换成一条已知的非法指令（例如csrrw x0, time, x0）。
3. 当执行流走到这个位置时，原本的sc变成了非法指令，从而触发非法指令异常。
4. 在这个非法指令异常处理程序中，我们判断异常地址是否是我们之前做过替换的地址。如果是，则：
   • 将内存中的指令恢复为原来的sc。
   • 检查“保留”状态，据此决定模拟存储成功还是失败，并设置rd寄存器的值。
   • 更新mepc，跳过已被执行（模拟）的sc指令，继续执行。
5. 如果不是我们替换的指令，则按普通的非法指令异常处理（可能委托给内核）。

这种方法虽然复杂，但有效地在硬件不支持的情况下，为SDRAM区域提供了完整的原子操作语义，确保了内核同步机制的正常工作。

3.3 设备树（DTS）的定制与传递

设备树是向内核描述硬件资源的蓝图。对于nommu Linux，一个正确且精简的设备树至关重要。

我们的设备树需要包含以下关键部分：

• CPU信息：指定CPU类型、ISA字符串（rv32imafdcp）、中断控制器。
• 内存节点：准确描述SDRAM的起始地址和大小（如0x4000_0000开始，32MB）。
• 系统时钟：正确设置timebase-frequency，与Bootloader中模拟的MTIME频率一致。
• 串口：配置一个用于早期控制台和内核输出的串口设备。这里使用了SBI的hvc0作为控制台，对应RustSBI实现的SBIconsole_putchar调用。
• 启动参数：通过chosen节点传递bootargs，例如设置console=hvc0和根文件系统位置。

Bootloader需要将设备树二进制文件（DTB）加载到SDRAM中，并在跳转前将DTB的起始地址放入a1寄存器（按照RISC-V的SBI调用约定）。内核启动后，会解析该地址处的DTB来获取硬件信息。

4. 实战：构建与引导流程详解

4.1 开发环境与工具链准备

工欲善其事，必先利其器。首先需要搭建交叉编译环境。

1. RISC-V GNU工具链：用于编译Bootloader和内核。需要选择支持rv32imafdc架构的版本。可以从SiFive或RISC-V官方获取预编译版本，或自行从源码编译。

   # 例如，将工具链加入PATH export PATH=/opt/riscv32-unknown-elf-gcc/bin:$PATH

2. Rust工具链：用于编译基于RustSBI的Bootloader。通过rustup安装稳定的Rust版本，并添加riscv32imac-unknown-none-elf目标。

   rustup target add riscv32imac-unknown-none-elf

3. 项目源码：
   • Bootloader:https://github.com/rustsbi/rustsbi-hpm
   • Linux内核:https://github.com/hpm-rs/linux(包含针对HPM的nommu配置和补丁)
   • Buildroot:https://github.com/hpm-rs/buildroot(用于构建根文件系统)

4.2 编译引导程序（rustsbi-hpm）

进入rustsbi-hpm目录，编译过程相对简单，因为主要的硬件适配代码已经完成。

cd rustsbi-hpm # 使用 release 模式编译以优化大小和速度 cargo build --release --target=riscv32imac-unknown-none-elf

编译完成后，在target/riscv32imac-unknown-none-elf/release/目录下会生成一个ELF文件，例如rustsbi-hpm。我们需要的是纯二进制镜像，使用objcopy工具进行转换：

riscv32-unknown-elf-objcopy -O binary target/riscv32imac-unknown-none-elf/release/rustsbi-hpm rustsbi-hpm.bin

这个rustsbi-hpm.bin就是我们的Bootloader镜像。它内部已经包含了SDRAM初始化代码、内核加载逻辑、以及我们前面详述的异常模拟处理程序。

4.3 配置与编译Linux内核

进入Linux内核源码目录，首先需要加载针对HPM6360 nommu的默认配置。

cd linux # 应用默认配置，它已设置好 ARCH=riscv, CONFIG_MMU=n, 以及HPM相关的驱动 make hpm6360_nommu_defconfig

接下来，可以根据需要进行内核配置调整。一个关键的配置是确保时钟频率正确：

make menuconfig

在菜单中，确保以下选项被正确设置：

• Kernel Features -> Timer frequency -> 1000 HZ(可根据需求调整)
• Boot options -> Kernel command line可以与设备树中的bootargs保持一致或留空。
• 检查Device Drivers -> Character devices -> Serial drivers中是否支持SBI HVC控制台。

然后开始编译内核：

# 指定架构和交叉编译器 make ARCH=riscv CROSS_COMPILE=riscv32-unknown-linux-gnu- -j$(nproc)

编译完成后，在arch/riscv/boot/目录下会生成Image文件。这就是压缩后的内核镜像。对于nommu系统，我们通常使用Image（非压缩的vmlinux有时也可用，但更大）。

4.4 制作系统镜像与烧录

HPM6360通常从XPI Flash启动。我们需要将Bootloader、内核和设备树打包成一个可以被BootROM识别的镜像。HPM的BootROM期望一个简单的镜像布局：通常是一个包含加载地址和入口点的头部，后面紧跟代码。

项目仓库中一般会提供一个链接脚本或打包工具。以本项目为例，可能需要创建一个flash.bin：

1. Bootloader (rustsbi-hpm.bin) 放置在偏移0处。
2. 设备树二进制 (hpm6360.dtb) 放置在一个固定偏移（如0x10000）。
3. Linux内核镜像 (Image) 放置在另一个固定偏移（如0x20000）。

Bootloader的代码里会知道这些偏移量，从而在启动时将它们加载到SDRAM的正确位置。可以使用dd命令进行拼接：

# 假设每个部分大小为64KB对齐 dd if=/dev/zero of=flash.bin bs=1k count=1024 # 创建1MB空镜像 dd if=rustsbi-hpm.bin of=flash.bin conv=notrunc # 写入Bootloader到开头 dd if=hpm6360.dtb of=flash.bin bs=1k seek=64 conv=notrunc # 写入DTB到64KB偏移处 dd if=Image of=flash.bin bs=1k seek=128 conv=notrunc # 写入内核到128KB偏移处

最后，使用HPMicro官方提供的编程工具（如hpmicroprog或OpenOCD脚本），将flash.bin烧录到开发板的外部Flash中。

4.5 上电启动与调试

烧录完成后，给开发板上电，并通过串口工具（如minicom或picocom）连接到调试串口。如果一切顺利，你将看到类似以下的启动日志：

RustSBI for HPM6360 . . . Initializing SDRAM... Loading kernel from flash... Jumping to kernel at 0x40000000... [ 0.000000] Linux version 6.10.0 ... [ 0.000000] riscv: ISA extensions acdfim [ 0.000000] riscv: ELF capabilities acdfim [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x40000000-0x41ffffff] [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x40000000-0x41ffffff] [ 0.000000] Initmem setup node 0 [mem 0x40000000-0x41ffffff] [ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 8128 [ 0.000000] Kernel command line: earlycon=sbi console=hvc0 ignore_loglevel rootwait root=/dev/mtdblock0 [ 0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear) [ 0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [ 0.000000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.000000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.100000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns [ 0.120000] sbi_console: hvc0 at I/O port 0x0 (irq = -1, base_baud = 0) is a SBI [ 0.140000] printk: console [hvc0] enabled ... 更多内核初始化信息 ... Please press Enter to activate this console. / #

看到熟悉的/ #提示符，恭喜你，Linux已经在HPM6360上成功跑起来了！

5. 性能测试与问题排查实录

5.1 性能基准测试

系统启动后，最直观的就是看看它的性能表现。我们使用CoreMark和ramspeed进行测试。

CoreMark测试： 在BusyBox环境下编译并运行CoreMark，结果显示了芯片的计算性能。如前文所示，在HPM6360上获得了约1437.5 Iterations/Sec的分数。这个分数需要结合芯片的主频（如600MHz）来评估，它反映了CPU核心在编译器优化下的整数计算能力。对于一颗没有MMU、运行nommu Linux的MCU来说，这个成绩是相当可观的，证明了其处理能力足以承担一定的计算任务。

Ramspeed测试： 内存带宽测试更能揭示系统瓶颈。运行ramspeed -b 2 -g 1 -m 1 -r进行整数读取测试，结果清晰地展示了缓存层级的影响：

• 当数据块在L1缓存内（1K-16K）时，读取速度高达~1.5 GB/s。
• 当数据块大小超过L1缓存（32K）时，速度降至~1.3 GB/s，可能触及L2缓存或开始出现瓶颈。
• 当数据块远超缓存大小（64K及以上）时，速度稳定在~116 MB/s，这基本就是SDRAM本身的实际读取带宽。

这个测试结果非常重要，它告诉我们：

1. 系统的缓存工作正常。
2. SDRAM的初始化配置是正确的，带宽符合预期。
3. 在优化应用程序时，需要特别注意数据局部性，尽量让热点数据待在缓存里，否则性能会因内存带宽而大幅下降。

5.2 常见问题与调试技巧

在移植和调试过程中，我遇到了不少问题，这里总结几个典型的：

问题1：内核启动早期就卡住或复位。

• 排查思路：
  1. 检查Bootloader的SDRAM初始化：这是最常见的原因。使用仿真器（如OpenOCD）在跳转到内核前暂停，检查SDRAM控制器配置寄存器是否正确，并尝试手动读写SDRAM地址，看数据是否可读可写。
  2. 检查内核加载地址：确保Bootloader将内核镜像加载到了设备树中memory节点定义的范围内，并且地址是合适的对齐地址（通常是4KB或2MB对齐）。
  3. 检查设备树传递：确认a1寄存器传递的是正确的DTB物理地址，并且DTB本身没有被错误加载或损坏。可以在Bootloader中先打印出DTB的魔数（0xd00dfeed）进行验证。
  4. 简化内核配置：尝试一个最简化的内核配置，关闭所有非必要的驱动和功能，排除驱动初始化导致的问题。

问题2：内核打印乱码或没有任何输出。

• 排查思路：
  1. 确认控制台配置：确保内核命令行参数console=hvc0，并且内核配置启用了CONFIG_SBI_HVC和CONFIG_EARLY_PRINTK。
  2. 检查RustSBI的SBI_CONSOLE_PUTCHAR实现：在RustSBI中，console_putchar函数最终需要映射到你的具体串口发送函数。确认串口波特率、引脚配置是否正确。可以在Bootloader阶段就先测试串口输出功能。
  3. 模拟TIME CSR的影响：早期内核打印可能依赖计时。如果模拟timeCSR的逻辑有误（如返回值为0或频率不对），可能导致内核的printk时序出现问题。检查MCHTMR是否已启用，并且timebase-frequency设置是否正确。

问题3：运行用户程序时出现“Illegal instruction”或“Store/AMO fault”。

• 排查思路：
  1. 指令模拟逻辑缺陷：这很可能是因为我们实现的TIMECSR模拟或原子指令模拟有漏洞。例如，没有正确处理timehCSR（32位系统下读取time可能只需要模拟一次，但某些代码路径可能会读timeh）。使用调试器在异常处理函数中设置断点，仔细检查mtval中的指令码和解码结果。
  2. LR/SC模拟的竞态条件：软件模拟LR/SC在真正的多核环境下会非常复杂且容易出错。在单核HPM6360上，主要需确保在模拟lr和sc的整个过程中中断被禁用，防止其他中断处理程序访问同一保留地址。检查你的“保留地址”标记和检查逻辑是否严谨。
  3. 编译工具链问题：确认用户程序是用正确的-march=rv32imafdc等标志编译的，确保编译器没有生成目标硬件不支持的指令。有时静态链接的库可能包含非法指令。

问题4：系统运行一段时间后死机或不稳定。

• 排查思路：
  1. 内存越界：nommu Linux没有虚拟内存保护，错误的指针访问会直接导致系统崩溃。使用kmemleak或slabinfo等内核工具（如果配置了）检查内存泄漏。在用户态，使用busybox自带的memtester进行长时间的内存测试。
  2. 中断冲突：检查设备树中的中断号分配是否与Bootloader或RustSBI中设置的中断控制器配置冲突。确保时钟中断、串口中断等被正确接管和处理。
  3. 电源管理：检查是否因为某些低功耗模式配置不当导致外设或时钟停止工作。在初期调试阶段，可以暂时关闭所有电源管理相关配置。

调试心得：在如此底层的移植中，一个可靠的硬件调试器（如JTAG/SWD）是必不可少的。它允许你单步执行Bootloader代码、检查任何时刻的寄存器状态、设置硬件断点。当串口没有输出时，调试器往往是唯一的“眼睛”。另外，善用RISC-V的mstatus、mepc、mtval、mcause这些CSR寄存器，它们记录了异常发生时的完整现场信息，是诊断问题的第一手资料。

6. 总结与未来展望

这次将Linux 6.10 nommu内核通过RustSBI移植到HPM6360 MCU上的实践，是一次深入RISC-V特权架构、Linux启动流程和底层硬件交互的绝佳学习过程。它打破了“MCU只能跑RTOS”的刻板印象，展示了在高性能RISC-V MCU上运行功能丰富的Linux系统的可行性。项目的成功，离不开RustSBI项目提供的优秀底层框架，以及Linux社区对nommu架构的持续支持。

目前实现的功能已经是一个坚实的起点：系统可以正常启动，运行基本的命令行工具，并进行性能测试。然而，这只是一个开始。未来的工作可以围绕以下几个方面展开：

1. 驱动完善：目前可能仅支持了串口等基础驱动。可以进一步移植或开发其他关键驱动，如以太网（MAC）、SD/MMC卡、USB等，让开发板具备网络和外部存储能力。
2. 电源管理集成：实现更完善的CPU空闲状态和电源模式切换，在保证功能的同时优化功耗，这对于电池供电的应用场景很重要。
3. 优化启动时间：分析启动流程的每个阶段耗时，例如是否可以优化内核解压速度、减少不必要的驱动初始化等，追求极致的启动速度。
4. 用户态生态探索：研究在nommu环境下，如何运行更丰富的用户态程序。可以考虑使用uClibc或musl库构建更小的根文件系统，探索运行轻量级图形界面（如DirectFB）或特定应用的可能性。
5. 多核支持：如果未来使用多核的HPM芯片，需要完善RustSBI中对SBI IPI（处理器间中断）的支持，并让Linux内核能够识别和启动多个CPU核心。

整个项目的代码和预编译镜像都已开源，希望能为更多对RISC-V、嵌入式Linux感兴趣的开发者提供一个参考案例。移植过程就像解谜，每一个问题的解决都建立在对硬件手册和软件规范的深刻理解之上。当你最终看到内核提示符出现在串口终端的那一刻，所有的调试和等待都是值得的。