Skip to content

Running linux kernel #2

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

Open
aj0518 opened this issue Aug 28, 2020 · 4 comments
Open

Running linux kernel #2

aj0518 opened this issue Aug 28, 2020 · 4 comments

Comments

@aj0518
Copy link

aj0518 commented Aug 28, 2020

I am attempting to run a linux kernel on r2vm. The linux kernel, block device, and firmware images (https://cs.binghamton.edu/~marss-riscv/marss-riscv-images.tar.gz) are the 64-bit versions from the MARSS-RISCV simulator (https://github.com/bucaps/marss-riscv). I run the following command ~/r2vm/target/release/r2vm config.toml and my config.toml is as follows:

core = 1   
memory = 1024  
kernel = "/home/ubuntu/marss-riscv/src/marss-riscv-images/riscv64-unknown-linux-gnu/kernel-riscv64.bin"  
cmdline = "console=hvc0 root=/dev/vda rw"  
firmware = "/home/ubuntu/marss-riscv/src/marss-riscv-images/riscv64-unknown-linux-gnu/bbl64.bin"  
[[drive]]  
path = "/home/ubuntu/marss-riscv/src/marss-riscv-images/riscv64-unknown-linux-gnu/riscv64.img"

When running this, I get the error which seems to indicate an operation has not been implemented:

thread 'main' panicked at 'not implemented: 7fff0006523e Cmp(dword [rdx], +0x1)', src/emu/signal.rs:193:14

The backtrace seems to indicate the problem is with loading the kernel:

12: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:391
  13: r2vm::emu::signal::handle_segv
             at src/emu/signal.rs:193
  14: <unknown>
  15: r2vm::emu::loader::Loader::load_kernel
             at src/emu/loader.rs:283
  16: r2vm::main
             at src/main.rs:327
  17: std::rt::lang_start::{{closure}}
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/rt.rs:67
  18: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  19: std::panicking::try::do_call
             at src/libstd/panicking.rs:348
  20: std::panicking::try
             at src/libstd/panicking.rs:325
  21: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  22: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  23: main

This simulator's speed is remarkable so any advice you can provide on what the error may be (the images seemed to work on the MARSS-RISCV simulator) or if the images are formatted incorrectly would be very helpful. Thanks!

@nbdd0121
Copy link
Owner

Could you try without specifying the firmware field? Currently R2VM has limited support custom memory layout, so the firmware "feature" isn't really working unless you tweak the linker script to place it to a certain location.

@nbdd0121
Copy link
Owner

Oh, and previously firmware can only be ELF but not binary.. This is now fixed in 83c240f, so you can give your firmware another try if that is position-independent (but I'll recommend just boot Linux in supervisor mode without extra firmware).

@aj0518
Copy link
Author

aj0518 commented Aug 28, 2020

Appreciate the prompt response and the fix! I gave it a shot with the firmware again but still get the error thread 'hart 0' panicked at 'not implemented', src/emu/interp.rs:516:22 so looks like you're right and I'll have to tweak the linker script if I want to use the firmware--where is that located in the codebase?

I also tried booting Linux without the extra firmware (removed the firmware line from my config.toml) with the command ~/r2vm/target/release/r2vm --lockstep config.toml and this runs but is taking a long time (has not finished running yet) because it seems to be booting up Linux in the full cycle-approximate simulator mode. Is there a way to speed this up and boot Linux in emulator mode (i.e. not cycle-accurate) and then switch to simulator mode once Linux has been booted?

I also just wanted to confirm that the --lockstep mode enables both the InOrder and MESI pipeline and memory models. Thanks!

@nbdd0121
Copy link
Owner

You can do r2vm config.toml and switch to lock-step by pressing Ctrl+A and then T. Alternatively, you can write 0 or 1 to CSR 0x800 to switch on/off cycle-level simulation, write 1 to CSR 0x801 to print stats and write 0 to CSR 0x801 to clear stats.

Currently the lockstep mode is just in order model plus a simple memory model. You can tweak src/sim/mod.rs to choose other models. The MESI model implementation is rough and isn't on master yet, but if you want to try it you can use the cache branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants