after pk patch, It seems program hang forever

[etchen66]

[1]+ Stopped ./emulator-rocketchip-RoccExampleConfig ./pk ./rocket-rocc-examples/build/test-accumulator

real 11m56.553s user 0m0.000s sys 0m0.000s

[seldridge]

Unfortunately, I won't be able to look at this for awhile...

Usually a hang is indicative of a tool mismatch.

Can you provide some more info: 1) Sanity checks:

• Can you run a DefaultConfig with one of the bare-metal riscv-tests?
• Can you run a RoccExampleConfig with one of the bare-metal riscv-tests?
• Can you run a DefaultConfig rocket-chip with an unpatched proxy kernel and a hello world binary?
• Can you run a DefaultConfig rocket-chip with a patched proxy kernel and a hello world binary?
• Can you run a DefaultConfig rocket-chip with an unpatched proxy kernel and one of the example tests (e.g., test-accumulator) to see the expected illegal instruction trap? 2) Version information:
• rocket-chip
• riscv-tools (and are the submodule properly updated to match the riscv-tools version?)
  • riscv-fesvr
  • riscv-pk 3) Is the program getting stuck and if so where?

To look at (3) you'll need to run verbosely:

./emulator-Top-RoccExampleConfig +verbose $RISCV_PK_DIR/build/pk $THIS_REPO_DIR/build/test-accumulator 2>&1 | spike-dasm 

You may be able to debug this yourself if you are able to sort out where it's getting stuck.

Clarification: you're running ./pk. Just to make sure that you actually have pk in the same directory as the emulator?

Tangentially, the five minute wait time is absurdly obnoxious and it makes debugging very difficult. Internally, I've switched over to entirely using bare metal testing of RoCCs because you only need to run for ~300k cycles vs. the ~5000k cycles with the proxy kernel.

[etchen66]

Sorry for late response. It was my fault. (a starter to risc-v and git) I applied the patch to newer commits of tool-chain and rocket-chip, which causes the problem.

Applying the patch to the following commits, it works. please close the issue and thanks for your help.
rocket-chip:c5310938 riscv-tools:cd78e37

[etchen66]

Have another question about the doTranslate. I guess we don't need it if we want to run the same test in a bare-metal environment such as VSIM because there is no OS so no need for virtual memory , is it correct ?

[seldridge]

All good! I'm glad you got it sorted out.

Re: doTranslate, yes, if you're in a physical memory environment there's no need for doing address translation. I'm not sure what happens if you try to do address translation when you're running without virtual memory.

For "VSIM", I presume that you mean if you're running in the vsim directory. That's no different than running with the emulator, except that you're using vcs and not verilator. The notion of vsim not using an OS depends on what program you pass in. You can run a full-blown OS inside of the built vcs executable, however, it will be slow... (10KHz) and take an inordinately long amount time to do anything useful. Usually, you're passing a specifically constructed binary, like one of the RISC-V Tests in as the sole executable. If you are doing this, then you are running bare-metal, so long as it's one of the physical memory tests. The RISC-V tests do provide some lightweight virtual memory support for testing, similar to the Proxy Kernel.