When gem5 runs in SE mode, it is intended to mainly run user-level code,
which higher-privilege code that executes during system calls offloaded to
the host. The privileged instructions do have definitions and at least
partial implementations, and you can run them in SE mode because privilege
checking hasn't been implemented yet (and would only matter for FS mode
anyway).
You should be able to run garnet2.0 and ruby, since they are separate from
the ISA definitions and I didn't see anything in the ISAs that needs to be
implemented for them while poking around when I was implementing RISC-V. I
haven't actually used them myself, though.
Yes, inline assembly with CSRR is what I had intended. I'll take a closer
look at it this weekend and try to fix it.
On Mon, Mar 4, 2019 at 12:22 PM Rishabh Jain <rishucod...@gmail.com> wrote:
> Hi Alec,
>
> Thanks for the reply.
>
> First, I have a few queries (for RISCV ISA):
> 1. In which privilege mode does gem5 boot in? If it is supervisor mode or
> user mode, then how do I run binaries in machine mode?
> 2. Can I use garnet2.0 and ruby model for riscv?
>
> I applied the patch by updating the src/arch/riscv/isa.cc file. Then, I
> rebuilt the system using "$ scons build/RISCV/gem5.opt -j4".
> I compiled my C program file using the command: "
> riscv64-unknown-linux-gnu-gcc-7.2.0 -static hello1.c -o a.out"
> Again, I ran my python config file using the command " $
> build/RISCV/gem5.opt configs/multi_core/two_core/two_core_copy.py "
> and I got the same previous value of mhartid. Both 0.
> I used inline assembly :
> asm ("csrr %0,0xF14\n\t"
> :"=r" (hartID)
> );
> to read the value of mhartid and store in variable hartID. But here, I am
> using the csrr instruction, right?
> As you mentioned earlier, may you please elaborate on reading CSRR
> instruction?
>
> Thanks and Regards,
> Rishabh Jain
>
>
>
>
>
>
>
>
> On Mon, Mar 4, 2019 at 1:57 AM Alec Roelke <ar...@virginia.edu> wrote:
>
>> Hi Rishabh,
>>
>> You're right that mhartid should not be the same for every CPU. It looks
>> like you may have found a bug in RISC-V in that mhartid had not been
>> implemented yet. This is odd, though, because I thought I had implemented
>> it. In any case, try this patch (
>> https://gem5-review.googlesource.com/c/public/gem5/+/16988), which
>> implements this CSR by returning the current thread's ID. Note that trying
>> to manually get the contents of the register by inspecting it as you did
>> will still get 0 for all CPUs, but reading it using the CSRR instruction
>> should produce correct results. It would also be helpful if you review the
>> patch (just +1 or -1 is okay unless you have more information you want to
>> share) so I know it works on others' machines.
>>
>> As for your other problem, did you compile with the Linux toolchain or
>> the Newlib one? Gem5 is generally intended to run Linux binaries, so there
>> may be problems running code compiled for Newlib. I tried your program
>> with both, and it works with the Linux toolchain. Try that and let me know
>> if it still fails.
>>
>> -Alec
>>
>> On Fri, Mar 1, 2019 at 9:50 AM Rishabh Jain <rishucod...@gmail.com>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I have started working with gem5 from past 2 weeks and am trying to
>>> simulate a multi-core CPU system with RISC-V ISA on gem5.
>>>
>>> I have written a C file where I use inline assembly snippet to grab the
>>> value of mhartid (Hardware Thread id), marchid and mstatus.
>>> I used this command to statically compile C code: $
>>> riscv64-unknown-elf-gcc-7.2.0 -static hello1.c
>>> The C code is available at (hello1.c) https://pastebin.com/t5XBBWEz.
>>>
>>> I have written my multi-core python configuration code: where the system
>>> has two CPU cores, each having a private
>>> I cache and D cache. These cache memories are connected to shared L2
>>> cache via L2 bus. The L2 cache memory
>>> is connected to the memory controller via membus.
>>> The code is attached or available at (python configuration file)
>>> https://pastebin.com/utxxNfJg
>>> I used the cache python file which Jason has provided as part of
>>> learning-gem5 book. ((python cache file) https://pastebin.com/sTc8vwdh)
>>> The command used to simulate on gem5: $ build/RISCV/gem5.opt
>>> configs/multi_core/two_core/two_core_copy.py
>>>
>>> After running this command, I get the console log : (console log without
>>> loop) https://pastebin.com/t8rM9thk
>>> From this log, I am able to get the values as follows:
>>> CPU1:
>>> mhartid = 0
>>> marchid = 8192
>>> mstatus = 0
>>>
>>> CPU2:
>>> mhartid = 0
>>> marchid = 8192
>>> mstatus = 0
>>>
>>> I strongly feel that mhartid of each processor should be different. Can
>>> someone explain to me why they are the same?
>>>
>>> Out of curiosity, I had put a loop in the C code to observe cache
>>> misses! (please uncomment the loop in above C code to run! )
>>> Again, I compiled the C code using the above command and simulated using
>>> gem5.
>>> I get a long message starting with "panic: Page table fault when
>>> accessing virtual address 0x8000000000000000".
>>> (console log with loop) https://pastebin.com/0xNyGkCE
>>>
>>> Also, my max_miss_count parameter in config.ini remains to be 0 for all
>>> caches.
>>> I am unable to understand this error?
>>>
>>> Other than this, may someone guide me to the steps of finding memory
>>> trace and instruction trace for a binary executed on gem5 in RISC-V isa.
>>>
>>> Thanks and regards,
>>> Rishabh Jain
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
