tools: add build doc for kernel that use opensbi as bootloader

[cebarobot]

Are you sure to use linux 6.6? This version contains the misaligned memory access tests, which doubles the boot-up time.

[cyyself]

Are you sure to use linux 6.6? This version contains the misaligned memory access tests, which doubles the boot-up time.

In my opinion, the mainline v6.1 does not have vector support. If a misaligned probe wastes boot time, we should use mainline like 6.8 or 6.9 instead of LTS, which provides a config to turn it off.

[cebarobot]

Are you sure to use linux 6.6? This version contains the misaligned memory access tests, which doubles the boot-up time.

In my opinion, the mainline v6.1 does not have vector support. If a misaligned probe wastes boot time, we should use mainline like 6.8 or 6.9 instead of LTS, which provides a config to turn it off.

Ok, that is a problem. So what about asking users to choose kernel version on kernel.org by themselves? I think we could write down some instruction in the document.

[xyyy1420]

你确定使用 linux 6.6 吗？此版本包含未对齐的内存访问测试，这会使启动时间增加一倍。

在我看来，主线 v6.1 没有矢量支持。如果未对齐的探测器浪费了启动时间，我们应该使用 6.8 或 6.9 等主线而不是 LTS，后者提供了将其关闭的配置。

Ok, that is a problem. So what about asking users to choose kernel version on kernel.org by themselves? I think we could write down some instruction in the document.

seems good idea

[cebarobot]

Also, Please consider to use code block instead of inline code to carry all the shell command.

[xyyy1420]

Also, Please consider to use code block instead of inline code to carry all the shell command.

Am I correct modification? in 1c458d0

[cyyself]

I found you have set FW_TEXT_START. You may try mainline OpenSBI since https://github.com/riscv-software-src/opensbi/commit/d4d2582eef7aac442076f955e4024403f8ff3d96 , which can be placed anywhere and only needs to set some offset to use. Whatever, please feel free to leave this as future work. This will simplify the migrating of simpoint from pk.

[cebarobot]

Also, Please consider to use code block instead of inline code to carry all the shell command.

Am I correct modification? in 1c458d0

No, it's not correct. Please STFW or check other md files.

[xyyy1420]

I found you have set . You may try mainline OpenSBI since riscv-software-src/opensbi@d4d2582 , which can be placed anywhere and only needs to set some offset to use. Whatever, please feel free to leave this as future work. This will simplify the migrating of simpoint from pk.FW_TEXT_START

thanks for reminds, already switch to master

[xyyy1420]

Also, Please consider to use code block instead of inline code to carry all the shell command.

Am I correct modification? in 1c458d0

No, it's not correct. Please STFW or check other md files.

I've modified it, please check it again

[cebarobot]

Also, Please consider to use code block instead of inline code to carry all the shell command.

Am I correct modification? in 1c458d0

No, it's not correct. Please STFW or check other md files.

I've modified it, please check it again

Now it looks good.

[cyyself]

The dts we use has a sdhci node with a nemu-sdhost compatible string. However, the kernel we use is the mainline kernel without this driver. The driver of nemu-sdhost may never be submitted to the mainline. Is there another sdhci driver in linux compatible with nemu-sdhost? If yes, we should change the dts. If not, we should add a patch to the Linux repo and use git am or patch to apply this patch to add the nemu-sdhost driver or remove it in dts.

[cyyself]

I followed all your steps to build kernel and opensbi, but there were missed steps to build NEMU. We need to add a description of what configuration to choose in NEMU and how to build NEMU and get it running.

[cebarobot]

I followed all your steps to build kernel and opensbi, but there were missed steps to build NEMU. We need to add a description of what configuration to choose in NEMU and how to build NEMU and get it running.

Building NEMU is not the responsibility of this document. It's included in docs/tools/xsenv.md.

[cebarobot]

In fact, I think we should remake our workload infrastructure and documents... There is a lot of things to do.

[poemonsense]

In fact, I think we should remake our workload infrastructure and documents... There is a lot of things to do.

A CI flow to build the workload will benefit a lot. If the user follows the CI steps, they will never fail.

[poemonsense]

I just realized the workload_build_env repo was probably adapted from the forked opensbi repo (https://github.com/OpenXiangShan/opensbi/tree/github) in OpenXiangShan.

It is not a good practice to extract public code into a personal repository, as it will remove the authorship information. For example, the build.sh for the btb was introduced by Guokai in https://github.com/OpenXiangShan/opensbi/commit/426623afbf99998253a2b96301650a8471392e3d. However, in the personal repo, this information is removed.

If we are separating the scripts from the opensbi (instead of forking opensbi), we must respect the original authorship and avoid migrating any line of code to a personal project. At lease, we should 1) use OpenXiangShan to create the new repo; 2) add code with comments on where the code is originally from; 3) in any doc (such as this PR), indicate the original authors of the patches.

[xyyy1420]

I just realized the workload_build_env repo was probably adapted from the forked opensbi repo (https://github.com/OpenXiangShan/opensbi/tree/github) in OpenXiangShan.

It is not a good practice to extract public code into a personal repository, as it will remove the authorship information. For example, the build.sh for the btb was introduced by Guokai in OpenXiangShan/opensbi@426623a. However, in the personal repo, this information is removed.

If we are separating the scripts from the opensbi (instead of forking opensbi), we must respect the original authorship and avoid migrating any line of code to a personal project. At lease, we should 1) use OpenXiangShan to create the new repo; 2) add code with comments on where the code is originally from; 3) in any doc (such as this PR), indicate the original authors of the patches.

Thank you for pointing out my problem. First of all, I apologize to the original author (@chenguokai ) who was affected. This was my fault. I didn't mean to remove the original author's information, my original intention was to reorganize the build environment to avoid forking opensbi. In any case, I learned my lesson. I would like to apologize again to the original author (@chenguokai ). I will fix this issue as soon as possible and request for review again.