-
Notifications
You must be signed in to change notification settings - Fork 11
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
Docs #2
Comments
Hi, There are basically two ways to do this. Either use the old infrastructure from orpsocv2. Please note however that this is no longer maintained and only works with the legacy or1200 implementation. The preferred way to do it is instead to use FuseSoC (https://github.com/olofk/fusesoc) Once installed, you can run I wrote a quick script a while ago to run all the or1k-tests with FuseSoC. You can find it here https://gist.github.com/olofk/76b0b04181a7edd002a7529cf97ea325 Adapt as you want and don't hesitate to ask for further assistance |
Thanks. Running or1k-alignillegalinsn with your script I get errors in verilator.err.log Do you see the same error ? %Error: ../src/uart16550_1.5.4/rtl/verilog/uart_transmitter.v:275: syntax error, unexpected INTEGER NUMBER, expecting IDENTIFIER or ')' |
I do recognize this error. Let me have a look and I get back to you. Also, I remembered that some of the tests might not pass, as they have dependencies on old infrastructure, and we haven't properly updated all the tests yet. They should all compile though |
ok, this should be fixed now. You need an updated elf-loader. Just run |
The update with some warnings including:
But also reports orpsoc-corecs and fusesoc-cores as "Already up-to-date" Running I'm getting the same error when running the test, I guess because elf-loader is not updated Can you give me the name of a test that is know to pass ? I'm using or1k-basic Removing the directory .local/share/fusesoc/fusesoc-cores/elf-loader then running What can I do to download elf-loader:1.0.1 ? |
Hi again, I realize that you managed to hit a number of unrelated bugs. Sorry about that :/ Regarding elf-loader, it turns out I never pushed the new version to fusesoc-cores (fusesoc-cores is the new library that eventually will replace orpsoc-cores). That is done now, and you should be able to run The warnings about plusargs can be ignored, and will eventually go away as we leave the old orpsoc-cores repo behind. It's a backwards-compatible thing The other thing I noticed is that ...but.. I just rewrote the verilator backend for FuseSoC and discovered now that I introduced a few bugs (mostly related to running with the I'm taking the opportunity here to fix the bugs in FuseSoC and trying to make the rest of the tests pass |
No pb. I now have elf-loader:1.0.1 Is the script fusesoc_multi_launch.py intended to run from a specific directory ? e.g. from the directory above or1k-tests I have a directory structure: or1k When running In build/mor1kx-generic_0/sim-icarus/icarus.log I have 4 lines:
I've modified fusesoc_multi_launch.py to only run or1k-basic with --sim=icarus I've also tried running:
which gives the same error message "No ELF file specified" Am I missing a step for generating the ELF file ? |
I can't see a reason however why it shouldn't work to run fusesoc directly as you have also tried. Is there any difference if you build and run in one stage, i.e. Oh wait.. you did compile the test cases, right? Running |
Hi, I was not running make in the native dir, when I do:
Where should or1k-sprs.h be ? Thanks. I found the file in https://github.com/openrisc/newlib and copied it to /opt/or1k-toolchain/or1k-elf/include Now when running
in the icarus.log but or1k-tests/native/build/or1k/or1k-basic is an ELF file now Running with INFO: vvp -n -M. -l icarus.log -melf-loader_1.0.1 -mjtag_vpi_0-r2 fusesoc.elf -lxt2 which does not have the plusarg for the ELF file. I tried:
This gives:
What does the message "Illegal Wishbone B3 cycle type (xxx)" mean ? Is it expected ? I ran across https://olofkindgren.blogspot.fr/2016/08/fusesoc-15.html : "The old [plusarg] sections that were deprecated in favor of the [parameter *] sections are no longer parsed as I have decided that users have had enough time to migrate to the parameter sections. The warning still remains to remind everyone that it's time to move on and the article about FuseSoC 1.4 has more info on what the [parameter] sections should look like." I guess this is different from plusarg arguments but maybe something was changed there too. |
I've never seen an issue with a missing or1k-sprs.h before. Very strange. I'll try do dig into that. Great that you found a solution for now. Could you tell me where you got your toolchain (precompiled or built from source? Where did you find instructions?) I also see now that you managed to uncover another bug in FuseSoC. Try running without the The illegal wishbone cycle warning is expected. It's a false warning, and I should fix that. The test ran successfully. report(0x8000000d) is supposed to be read as gooooood (Yeah, I know. It's far from obvious :)). Combined with exit(0x00000000), it means that the test was ok. |
I think the issue with or1k-sprs.h is caused by my build script cleaning up the src & build directory after installation. I guess or1k-sprs.h is not copied into /opt/or1k-toolchain/or1k-elf/include/or1k-sprs.h by the install script ? I'm building the toolchain based on: Here is the build script (I'm using Docker):
In fusesoc_multi_launch.py it might be nice to add:
just before running fusesoc Removing --keep allows fusesoc_multi_launch.py to run it outputs:
Thank for your help, it is encouraging to see a test running. I can't run more than one test with fusesoc_multi_launch.py without --keep working right ? Do you have any coverage statistics for these tests ? |
Regarding the toolchain instructions, those are unfortunately outdated as we have gradually been getting our code upstream since those were written. These are the recommended instructions. If you don't feel like rebuilding your toolchain again, you could try one of the pregenerated toolchains at the bottom of this page. I filed a bug report at the chiphack repo to see if we can get those instructions updated I agree that we should run I just fixed the issue with Regarding coverage, I don't have any numbers or an easy way to get that, but one idea would be to use modelsim (or any other simulator that supports coverage. Icarus doesn't unfortunately) and add a tcl script that is called prior to running the simulation. If this is done for all tests, they can be combined later |
I'm trying to build the latest tools but running into an issue with fusesoc:
I was trying to use the same build script for fusesoc so I wonder if changes made for other issues broke this ? |
This is unfortunately because the pip package manager for Python packages is broken, and came up now because of a new release of one of the dependencies. The oroginal issue was this It seems now however that newer versions of okonomyaki instead requires attrs >= 16.1.0, which is probably why it fails. I pushed some patches to a I'm pretty fed up with pip at this point that forced me to introduce a workaround in the first place. Thankfully FuseSoC has a better package manager than pip :) |
I'm not familiar with pip etc so it could be stupid mistakes on my side, here is what I see:
I'm using the branch: root@af99723f57c0:~/fusesoc# git branch
|
No faults on your side. It's just pip being stupid and thinks it has already satisfied all requirements. I've added another commit to the depfix branch now that migh fix it. Could you try to again, and if that fails, run |
I'm seeing something strange. After running installing fusesoc as root (which did require
Python 2.7 and 3.5 on the same machine so that may be the issue. |
Have you tried if it works now with FuseSoC 1.6.1? |
I have not, I did not get further than above. https://openrisc.io/newlib is not online. I should probably start from scratch and follow the latest build instructions - can you point me to them ? |
Sorry, I also noticed recently, that it is down. I will dig into that soon. |
Hello, I added a test bench runner script. It depends on a new version of mor1kx-generic in my repo and fusesoc. I'll be working on intergrating the cores into fusesoc-cores. This should make running tests for anyone really easy. |
Is there a testbench for the verilog RTL version of or1k ? Are there any docs on how to set that up ? Are there any coverage results available ? Thanks.
The text was updated successfully, but these errors were encountered: