找不到可以正常支持loongarch架构example正常运行的，支持kcontext特性的commit

[yuanccccccc]

我之前尝试了rcore第七章修改好的代码，并且可以在loongarch上正常运行，后面自己修改我们的内核，可以在riscv64上正常运行，但是切换到loongarch上后编译可以通过，然而在执行qemu上板模拟的时候就出现卡死的情况，卡在了输出OPENSBI的前一步，我又测试rcore的第七章，发现也无法正常模拟，于是尝试了内置的example，同样出现了类似的问题，我在官网寻找各个版本之后，发现0.1.3的代码可以正常运行example，但是我的项目适配的是0.1.0版本，重点似乎是kcontext特性，但是我在各个commit却没有找到可以支持example执行完上板模拟的commit，请问哪一个版本可以支持我正常运行，还是说是bootloader的问题
我尝试了标识了verify的版本，riscv64和loongarch64运行结果都如下：编译报错

Compiling example v0.1.0 (/mnt/rcore/polyhal-ver/example)
error[E0432]: unresolved import arch::console_putchar
--> src/logging.rs:1:5
|
1 | use arch::console_putchar;
| ^^^^^^^^^^^^^^^^^^^^^ no console_putchar in the root

error[E0432]: unresolved import arch::api::ArchInterface
--> src/main.rs:12:12
|
12 | use arch::{api::ArchInterface, TrapFrame, TrapType};
| ^^^^^^^^^^^^^^^^^^ no ArchInterface in api

For more information about this error, try rustc --explain E0432.
error: could not compile example (bin "example") due to 2 previous errors
make: *** [Makefile:49: kernel] Error 101
root@5f2b1ab75ccf:/mnt/rcore/polyhal-ver/example#

[yuanccccccc]

warning: polyhal (lib) generated 1 warning
Compiling example v0.1.0 (/mnt/rcore/polyhal010/example)
Finished release [optimized] target(s) in 13.54s
timeout 40 qemu-system-riscv64 -machine virt -kernel target/riscv64gc-unknown-none-elf/release/example.bin -nographic -smp 1 >output.log 2>&1 || echo "QEMU exited"
QEMU exited
grep "[kernel] Hello, world!" output.log
make: *** [Makefile:69: run-inner] Error 1
root@5f2b1ab75ccf:/mnt/rcore/polyhal010/example#

某些版本还出现了这样的问题

[yfblock]

您是否可以给定一个 确定的仓库和 commit id 让我可以更加方便的复现这个问题

[yfblock]

顺带问一下 您使用的 qemu 版本是什么？

[yuanccccccc]

https://gitlab.educg.net/wangmingjian/os-contest-2024-image/
我使用了这个容器镜像中的环境，并且由于一些网络问题，导致我无法下载一些通过git下载的远程依赖项，因此我将它们下载到了本地并设置路径依赖，由于我不确定这个版本，并且我下载下来之后还需要重新配置本地的依赖，因此我将我本地的仓库上传到了这个仓库：https://github.com/yuanccccccc/testpolyhal，在其中我无法正常在loongarch上运行example

[yuanccccccc]

所有用本地路径的依赖都是将原仓库cargo.toml文件中的网址对应的源代码下载下来放在对应位置的

[yfblock]

我会尝试看一下这个版本的问题，不过您是否尝试过使用更加新的版本
https://github.com/oscomp/polyhal
https://crates.io/crates/polyhal

[yuanccccccc]

我使用旧版本的原因在于我是基于您在readme中给出的rcorewithhal作为参考来修改我的内核的，因此新版本会存在不适配问题，所以使用起来还需要时间了解和适配，后续我会尝试学习使用

[yfblock]

你可以展示一下你运行 qemu-system-loongarch64 的 command，我尝试了 https://github.com/yfblock/rcore-tutorial-v3-with-hal-component 其中使用 cd os && make ARCH=loongarch64 run 去运行，发现也是卡住并不能输出。经过检查发现时在运行的时候没有指定内存大小导致的 (qemu-system-loongarch64 需要 1G 的内存，也就是 -m 1G，旧版本小于 1G 会报错，且默认 1G，新版本的qemu需要自己指定)。

• 原来的 qemu 版本 8.x.x
• 此次测试我使用的 qemu 版本 9.2.1

希望这个能解决你的问题，还有说明一下，之前版本有一些让人迷惑的地方，loongarch64 qemu 的内存开始地址时 0x8000_0000，而不是 example 中的 0x9000_0000，之前是为了在内核前运行一段程序，所以这样设计，目前在 新版本中已经修正。

[yfblock]

顺带提一些我对 这个情况的分析，loongarch64-qemu 默认会将内存首先分布在 0x0000_0000 - 0x1000_0000 也就是 256M 的内存，然后才会在 0x8000_0000 继续分布。所以 如果分配的内存小于 256M 就会导致 0x8000_0000 的地址没有可用的内存，这种情况可以将内核放在 0x0000_0000 - 0x1000_0000 之前解决，或者增大内存，在 0x0000_0000 - 0x1000_0000 之间需要注意不要和设备树地址重叠(0x10_0000 - 0x20_0000)

[yuanccccccc]

你可以展示一下你运行 qemu-system-loongarch64 的 command，我尝试了 https://github.com/yfblock/rcore-tutorial-v3-with-hal-component 其中使用 cd os && make ARCH=loongarch64 run 去运行，发现也是卡住并不能输出。经过检查发现时在运行的时候没有指定内存大小导致的 (qemu-system-loongarch64 需要 1G 的内存，也就是 -m 1G，旧版本小于 1G 会报错，且默认 1G，新版本的qemu需要自己指定)。

• 原来的 qemu 版本 8.x.x
• 此次测试我使用的 qemu 版本 9.2.1

希望这个能解决你的问题，还有说明一下，之前版本有一些让人迷惑的地方，loongarch64 qemu 的内存开始地址时 0x8000_0000，而不是 example 中的 0x9000_0000，之前是为了在内核前运行一段程序，所以这样设计，目前在 新版本中已经修正。

我尝试了修改-m参数来运行，在example中，我尝试直接在命令后面添加运行-m 参数，发现输出了一些内容，但是并没有像riscv中打印了rustsbi的图标，随后我尝试了使用rcorewithhal来运行，修改了makefile，但是还是执行qemu命令后卡死，以下是我的命令：
qemu-system-loongarch64 -kernel target/loongarch64-unknown-none/release/os -nographic -bios ../../rcore/bootloader/rustsbi-qemu.bin -drive file=../user/target/loongarch64-unknown-none/release/fs.img,if=none,format=raw,id=x0 -m 1G -smp 1 -D qemu.log -d in_asm,int,pcall,cpu_reset,guest_errors

以及您给出的分析，example之前执行的程序是qemu默认执行的吗，我在课程上学到过一个程序就是bootloader，不知道是否和这个有关系。您后面提到默认从0x0开始摆放内存导致的0x8000_0000位置可能没有有效内存，导致出现的这样的问题，但是您后面又说“可以将内核放在 0x0000_0000 - 0x1000_0000 之前解决”，可能您的意思是“不将”。

另外关于内存大小的问题，这个卡死的原因我猜测应该是qemu没有找到内核的第一条指令，但是我们内核本身的大小是确定的，在摆放内存的时候我们应该将内核的入口点地址和执行完bootloader跳转的地址对齐，我没有完全明白这个和大小的关系，您的意思是，如果0x80000000上面没有可用内存，我们就无法将入口点的指令放在这里吗，感谢您的解答

[yfblock]

是将内核放在 0x0000_0000 - 0x1000_0000 可以解决这个问题，因为当内存小的时候，只有这个范围上会有可用的内存，如果在一个地址上没有物理内存，那么指定的程序就没有办法被加载到这里，也就没办法找到任务可用指令，程序运行的时候会触发异常 FetchException，然后跳转到异常处理的程序中，但是因为系统没有初始化，异常处理地址为 0，所以会跳转到 0，地址 0 处没有内容。

而在 loongarch64 上没有 sbi 的存在，所以就没有办法输出 sbi 的图标，rustsbi 无法在 loongarch64 上使用，所以指定 sbi 会导致异常，尝试使用qemu-system-loongarch64 -kernel target/loongarch64-unknown-none/release/os -nographic -drive file=../user/target/loongarch64-unknown-none/release/fs.img,if=none,format=raw,id=x0 -m 1G -smp 1 -D qemu.log -d in_asm,int,pcall,cpu_reset,guest_errors

[yuanccccccc]

原来问题出在这里！我现在能够成功运行rcorewithhal了，感谢您的解答，顺便请教一下关于这个项目，我在修改代码的时候，看到代码中有Kcontext，并且在toml文件中看到了这个特性，但是似乎在较新的polyhal的版本中没有这个特性了，请问这是什么原因呢

[yfblock]

在新版的 polyhal 中 kcontext 默认已经对外暴露了 不需要开启 feature 了。

[yuanccccccc]

好的好的，感谢您的解答，受益匪浅

[yuanccccccc]

在新版的 polyhal 中 kcontext 默认已经对外暴露了 不需要开启 feature 了。

想请问一下有关文件系统挂载的问题，您修改的rcorewithhal里面似乎是通过cargo.toml来加载efs文件系统的，而我当前的内核是使用了simplefat文件系统镜像，在riscv上可以正常的打印出文件系统镜像中的测试文件，但是在loongarch上什么都没有显示出来，我想问一下对于不同的硬件平台，是否需要对文件系统的解析做抽象处理呢，我在当前版本的polyhal中没看到相关的处理，以及如果我要使用新版本的polyhal，请问它和旧版本的兼容性做的怎么样呢

[yuanccccccc]

您好，我刚刚才知道，我们使用的环境有一些问题，我使用wsl，在主目录下先执行make docker，再进入到os下执行make ARCH=riscv64 run，我刚刚提交了一次

[yuanccccccc]

您碰到的这个问题我也没有见过，看上去是cd到那个目录失败了，可能是因为您用的commit是最近的？因为我们中间有一次没有将testsuits这个文件夹传上去，因此无法cd，您可以使用新的commit来尝试，这次的里面是有测试样例文件夹的

[yfblock]

我看了以下，你们的问题是将 fat32.img 文件搞混了。

你们的仓库里有两个地方存放 fat32.img 文件。一处是

• os/fat32.img
• simple-fat32.img/[riscv64/loongarch64]fat32.img

riscv64 引入 fat32.img 的方式是 virtio 驱动，所以在 makefile 中指定，这部分你们做得没有问题，第二部分就是 loongarch64，它使用的是 ramdisk，他的引入方式是 os/src/drivers/block/ram_blk.rs, 通过 inc 的方式引入，这部分指向的是 os/fat32.img，而这个文件是一个空的文件，所以两个部分就不对齐了

[yuanccccccc]

我在 os/src/drivers/block/ram_blk.rs,里面看到了./fat32.img，但是这个路径是怎样指定的呢？'.'指的应该是当前目录而不是os吧，以及是只有fat磁盘这样，还是说对于loongarch来说，efs，fat，ext4这些磁盘都不用virtio驱动，而都应该使用inc引入吗，我现在已经将simplefat32下的loongarchfat.32放到os目录下并改名了，只是跑了好久没跑完

[yfblock]

只是 loongarch64 如此，因为 loongarch64 没有 MMIO 的 virtio,只有 pci 的，当时为了方便，直接使用ramdisk 替代了

[yuanccccccc]

好的！！谢谢您的指点，我之前都以为是-drive来挂载文件系统镜像的，乱改了，今天才知道ramblk里面才是相关的模块，我们对MMIO，virtio，pci这些东西还不太熟悉，现在正在学习，刚刚跑完能够在listapps里面显示出来所有的app虽然后面还是没跑起来initproc，真的非常感谢您花时间指点

[yfblock]

对于 riscv64 来说 确实是 用 -drive 来挂载的，只是 loongarch64 没有走这个方式

[yuanccccccc]

我又从仓库拉取了一次第七章代码，同样是riscv运行较快，而loongarch却相比有很高的延迟https://github.com/user-attachments/assets/a2c7d0d9-434f-4c35-89ee-cf690edc8a6f

[yfblock]

我们是不是可以约一次会议一起讨论一下？如果约的话，是否介意别人旁听？

[yuanccccccc]

我们是不是可以约一次会议一起讨论一下？如果约的话，是否介意别人旁听？

当然不介意！！我们队伍三个人很乐意一起跟您学习交流一下这个问题，不知道您明天什么时候有时间

[yfblock]

我们明天晚上 八点左右可以讨论一下？或者说 2 点左右。您可以加我的 QQ 我们讨论具体的时间: 321353225

[yuanccccccc]

我验证了一下自己的猜想，我们的代码确实不是卡住了，只是非常非常慢，最后panic位置仍然是上下文切换，代码在我们仓库的newtestloongarch分支中