I've cloned this repo and built tests using toolchain.
But faced some issues:
riscv-qemu faults running these tests (segfault or memory allocation fault). Followed the instruction on your site
starting pc in the test header (ex., rv32(64)mi-p-csr) is set to 80002000, but there is no code in this place (section .tohost)
Can you explain me how to fix this?
Currently on RISCV v1.9 as latest avaliable
Related
Does anyone know how to use the make proxy command from the command line in order to see the documentations of the modules? I have installed Instant Veins 5.0 i2 with SimuLTE. It doesn't work generating from the IDE of OMNeT++, it returns an error and the cars simulation can't run, so i need to re-install the whole instant-veins-5.0-i2-simulte.ova file from scratch.
For "Veins LTE 1.3", module documentation can be generated by opening a terminal, changing to the veins/ directory (the one that contains sumo-launchd.py), and running make doxy. Module documentation is then available in doc/doxy/index.html.
Note, however, that Veins LTE has not been in active development for quite some time and integrating much more recent versions of SimuLTE and Veins is now possible via Veins_INET. For more details, see https://veins.car2x.org/documentation/modules/#lte
I am currently using the linux-x86.img which I downloaded from the documentation page for gem5 (http://www.m5sim.org/Download), but since I was not able to compile the fscanf and fopen commands on this image I was wondering if there is a more recent image which I could download and use instead.
The error message throw when trying to compile the lines with fopen and fscanf are
./obj/edgelist.o: In function loadEdgeArray': edgelist.c:(.text+0x148): undefined reference to __isoc99_fscanf'
./obj/edgelist.o: In function loadEdgeArrayInfo': edgelist.c:(.text+0x20c): undefined reference to __isoc99_fscanf'
collect2: ld returned 1 exit status
make: *** [test] Error 1
This error is thrown when trying to compile from both from qemu as well as gem5.
Here's one setup that generates such an image with Buildroot. I'm a fan of Buildroot because it builds everything from source. I don't understand how fscanf and fopen could fail in that image, but I have tested them in the above setup and they work fine.
Boot used to work in the past, but gem5 X86 full system boot has been broken for likely easy to fix reasons for a few months now as of March 2020 on the gem5 side, although there are efforts in place to fix it, and so likely it will work again soon: https://www.gem5.org/project/2020/03/09/boot-tests.html
Other alternatives include:
https://gem5art.readthedocs.io/en/latest/ which Jason has been pushing and uses Packer to generate disk images
You can also extract working disk images from Docker: https://hub.docker.com/_/ubuntu This requires exporting them to a file to give to gem5.
It is also worth noting that when the gem5.org website migrated from the old Wiki to the new static website setup in Q1 2020, we lost the ability of doing directory listing under http://dist.gem5.org/dist/current/arm/ for some reason, and so devs were forced to list them one by one on the static website... https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries
I am not sure why the error is no longer occurring for me, but documenting the steps I went through which might have fixed something. I reinstalled Ubuntu18.04 therefore had to rebuild gem5 and I used the parsec image (http://www.cs.utexas.edu/~parsec_m5/x86root-parsec.img.bz2) referenced in this answer Booting gem5 X86 Ubuntu Full System Simulation
I ran the gem5 and could run ARM and full system on geme5.now I need to run DVFs on gem5 but I do not do it and looking sites for example :
1.http://www.gem5.org/Running_gem5#Experimenting_with_DVFS
2.http://www.gem5.org/docs/html/classDVFSHandler.html
but I don't understand and I don't know how to run DVFS on gem5.please help me and guide how I can do it and introduction site or reference for it?
I have got very similar problem to this one stated here : Intel CPU OpenCL in Mono killed by SIGXCPU (Ubuntu)
Essentially, I have a very simple C# application using OpenCL (through OpenCL.Net wrapper, but it shouldn't make a difference as it is merely wrapping native functions and nothing more). In the code I just build kernel and then allocate a big array of floats.
To be more specific my platform: It is Ubuntu 12.04, OpenCL 1.1 (with CUDA) and mono 3.0.3.
Problem: When running my code through mono i get CPU LIMIT EXCEEDED error
Few things:
If I set a breakpoint (in monodevelop) somewhere between building the kernel and allocation it works..
Changing array size to small one also makes it work
Strace doesn't show anything useful. I tried also passing a callback to ClBuildProgram (to note: if I comment out line with ClBuildProgram it works).
Any ideas?
That's what worked for me in the end.
There is a major problem with mono - it uses SIGXCPU for GC handling (which is strange btw). Unfortunately OpenCL uses it as well so it conflicts.
Workaround is to modify mono code.
Go to source directory and grep -r SIGXCPU . In my mono (3.0.3) there were 2 imporant files
./libgc/pthread_stop_world.c:# define SIG_THR_RESTART SIGXCPU
./mono/metadata/sgen-os-posix.c:const static int restart_signal_num = SIGXCPU;
Replace SIGXCPU with SIGWINCH and recompile. One note is that I am not sure if it didn't break something, but for now looks OK and OpenCL problem is gone. If it breaks something (like gui) replace SIGWINCH with different signal that you have (signals.h for signals defs)
I have been trying to run valgrind on a MIPS machine.
I successfully cross compiled valgrind and ran a few test from the test suite.
But whenever valgrind tries to create a coredump, an assertion fails.
Its from the file coredump-elf.c
vg_assert(sizeof(*regs) == sizeof(prs->pr_reg));
well apparently this assertion checks if the size of the byte array is same as the struct of registers made by the valgrind.
But i am not able to get past this error.
I am using valgrind on MIPS 32 machine.
thanks
Trunk Valgrind is well supported for MIPS32 LE/BE and MIPS64 LE/BE.
Download the code from the trunk:
svn co svn://svn.valgrind.org/valgrind/trunk valgrind
configure it, make it, and use it. You should not see any MIPS32 issues.