There are a few things that I have identified that need to be implemented
or created, including memory attributes/protection and a kernel+boot image,
and a few more things that need to be tested somehow, including switching
privilege modes and interrupts. I think the most important issue is the
creation of a kernel+boot image so we can try to run code and debug
problems. This patch
<https://gem5-review.googlesource.com/c/public/gem5/+/9901> contains an
example for running bare-metal code which does nothing but enter an
infinite loop, but I think a kernel will be necessary if we want to be able
to see output.
I have a GitHub repository I use to work on these in my old lab group's
organization and have created some issues to track them. I don't consider
these issues to necessarily be exhaustive and expect that more will be
added by me or other contributors in the future. Would you like me to
invite you to it?
Also, I've uploaded an update to the hartid patch that should fix the
problem. Please test it yourself and let me know via review if it works or
not.
On Sat, Mar 9, 2019 at 12:14 AM Rishabh Jain <rishucod...@gmail.com> wrote:
> Hi Alec,
>
> Thanks for welcoming me!
> What is current status in the implementation RISC-V FS mode?
> Also, what are the open issues and where are you tracking them?
> For now, I will check the above files pointed by you.
>
> Thanks and Regards,
> Rishabh Jain
>
>
>
> On Fri, Mar 8, 2019 at 8:17 PM Alec Roelke <ar...@virginia.edu> wrote:
>
>> The RISC-V CSRs are implemented as misc regs, which are the
>> responsibility of the ISA to maintain. ISA traits for RISC-V are
>> implemented in src/arch/riscv/isa.cc and .hh. The ISA object itself does
>> not have any references to CPUs or threads, so CSRs such as performance
>> counters and MHARTID can't be initialized and continuously updated by
>> them. However, their methods for getting the values of these registers
>> take ThreadContexts as arguments (implemented in src/cpu/thread_context.cc
>> and .hh), which *do* have pointers the CPU they are running on and can
>> thus be used to get that information. So, to get performance counts or a
>> hartid, rather than reading from the misc reg file, these methods return
>> data stored by the ThreadContext making the request. This is why trying to
>> read directly from the misc reg file won't work, because that is
>> technically never updated. For hartid, I tried implementing it using the
>> ThreadContext's threadId() method, but as you noticed that seems to not
>> always work, so I will have to find another solution.
>>
>> As for FS mode, yes, I have been slowly working toward implementing it.
>> I am always happy for others to contribute to RISC-V development, so I
>> invite you to contribute if you can. If you want any help or have any
>> questions about what is already there, I'll be happy to answer them.
>>
>> On Thu, Mar 7, 2019 at 4:58 AM Rishabh Jain <rishucod...@gmail.com>
>> wrote:
>>
>>> Hi Alec,
>>>
>>> Thanks for the reply.
>>> For the mhart id issue, could you please point out the file which
>>> implements mhart id?
>>> I will give a shot to understand the necessary files.
>>> If you can let me know, I can send a pull request regarding the same
>>> which you can check and merge.
>>> Also, do you plan to implement RISC-V FS mode? If yes, I wish to help by
>>> contributing to gem5.
>>>
>>> Please let me know how to get started.
>>>
>>> Thanks and regards,
>>> Rishabh Jain
>>>
>>>
>>>
>>> On Thu, Mar 7, 2019 at 8:19 AM Alec Roelke <ar...@virginia.edu> wrote:
>>>
>>>> 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
