-
Notifications
You must be signed in to change notification settings - Fork 439
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Rust support for RISC-V arch #225
Conversation
Does this run on QEMU? If so, would it make sense to run this in the CI, like the other architectures? |
Signed-off-by: Gary Guo <[email protected]>
It runs on QEMU, but you need to supply a firmware (e.g. OpenSBI). I don't think any distro has that supplied yet, so it means in the CI we have to pull and compile another project, which isn't trivial amount of work. |
We are already cross-compiling Busybox on the fly -- does OpenSBI take long to compile? If not, I can take a look at adding it. |
Ubuntu |
Wow, Ubuntu has OpenSBI packaged, I didn't know that. Debian only has OpenSBI in sid, so I assumed Ubuntu wouldn't have it yet. I'll look to see if I can integrate it in the CI. |
Thanks @nbdd0121! If you see any problems or you do not have time, let me know and I can do the CI missing bits. |
@ojeda I had a try, but I got a timeout and GitHub killed it without giving me much information. I don't have any machines with Ubuntu 20.04, and I tried to use nektos/act to test locally but it does not seem to support some constructs used in the CI script. I don't have much experience debugging GitHub actions; could you have a look if you have time? Thanks. |
Sure! Let me take a look. |
The bundled OpenSBI works fine for me in a VM, so no need to recompile. The timing out issue is because 1) The no output issue is due to something missing in the configuration, I think the best approach is merging this without enabling |
Signed-off-by: Gary Guo <[email protected]>
I will likely tweak a few minor nits later on, but I think we can merge this as-is. Thanks a lot! Referencing #66. |
We should add this to |
Yeah! I will do it when actually enabling it in the CI matrix. |
Finishes Rust-for-Linux#225. There were several problems: - No console output. This was due to missing `CONFIG_SOC_VIRT` and `CONFIG_SERIAL_OF_PLATFORM`. - Hanging QEMU. This was due to missing `CONFIG_SOC_VIRT`, plus `-no-reboot` not working in older QEMU versions for RISC-V. We provide a custom build of the latest QEMU (6.0.0, recently released) in https://github.com/Rust-for-Linux/ci-bin. - Broken boot for debug builds. Some debugging options under `Kernel hacking` do not seem to work for RISC-V (in our branched kernel version, that is). Also take the chance to clean up the `.config`s a bit more. Signed-off-by: Miguel Ojeda <[email protected]>
Finishes Rust-for-Linux#225. There were several problems: - No console output. This was due to missing `CONFIG_SOC_VIRT` and `CONFIG_SERIAL_OF_PLATFORM`. - Hanging QEMU. This was due to missing `CONFIG_SOC_VIRT` plus reboot not working in older QEMU versions for RISC-V. We provide a custom build of the latest QEMU (6.0.0, recently released) in https://github.com/Rust-for-Linux/ci-bin. - Broken boot for debug builds. Some debugging options under `Kernel hacking` do not seem to work for RISC-V (in our branched kernel version, that is). Also take the chance to clean up the `.config`s a bit more. Signed-off-by: Miguel Ojeda <[email protected]>
Completes Rust-for-Linux#225. There were several problems: - No console output. This was due to missing `CONFIG_SOC_VIRT` and `CONFIG_SERIAL_OF_PLATFORM`. - Hanging QEMU. This was due to missing `CONFIG_SOC_VIRT` plus reboot not working in older QEMU versions for RISC-V. We provide a custom build of the latest QEMU (6.0.0, recently released) in https://github.com/Rust-for-Linux/ci-bin. - Broken boot for debug builds. Some debugging options under `Kernel hacking` do not seem to work for RISC-V (in our branched kernel version, that is). Also take the chance to clean up the `.config`s a bit more. Signed-off-by: Miguel Ojeda <[email protected]>
Reduce verboseness of test_progs' output in reg_bounds set of tests with two changes. First, instead of each different operator (<, <=, >, ...) being it's own subtest, combine all different ops for the same (x, y, init_t, cond_t) values into single subtest. Instead of getting 6 subtests, we get one generic one, e.g.: #192/53 reg_bounds_crafted/(s64)[0xffffffffffffffff; 0] (s64)<op> 0xffffffff00000000:OK Second, for random generated test cases, treat all of them as a single test to eliminate very verbose output with random values in them. So now we'll just get one line per each combination of (init_t, cond_t), instead of 6 x 25 = 150 subtests before this change: #225 reg_bounds_rand_consts_s32_s32:OK Given we reduce verboseness so much, it makes sense to do a bit more random testing, so we also bump default number of random tests to 100, up from 25. This doesn't increase runtime significantly, especially in parallelized mode. With all the above changes we still make sure that we have all the information necessary for reproducing test case if it happens to fail. That includes reporting random seed and specific operator that is failing. Those will only be printed to console if related test/subtest fails, so it doesn't have any added verboseness implications. Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]>
No description provided.