Hi everyone,

besides of the known how to and progress status documents, the minsoc project has now a regular documentation. Please update your project (svn update on project's root directory) or download the last version from the project webpage.

A short introduction:
MinSoC consists only of the minimal requirements for an implementation using
the OpenRISC processor. This documentation aims to support its use and applicability
as a base for custom projects. As an open source project every part of it can be
uncovered and analyzed. However, without guidelines and explanation of what is intended
with its design, this task can be very difficult. Therefore, the following document gives
an overview of the project and explains its design goals and major details in order to allow
its user to adapt and extend MinSoC to fit his needs.

Feedback is very appreciated.

Best regards,
Raul

Nice work Raul


The docs detail how to patch the or-32 gdb tool to fix a bug. Is this going to be fixed in the source or do we have to deal with this for a long time?

The patch is something I found was necessary, it fixes a problem GDB has when running on bare metal. I don't think the problem happens when GDB is connected to or1ksim, only when it's connected to real hardware.

I didn't actually write the patch, I just found it. Apparently, it's not a "clean solution" for the problem, which is why it was never added to the standard version of GDB, but it works for our purposes. I've never bothered following up on it, it's possible Jeremy Bennett knows something more recent.

Hi John,

It's a long-standing issue with GDB, and its representation of null stack frames. GDB uses a single null frame representation for various purposes (invalid stack frame, no stack frame because the program hasn't started executing etc).

The patch is a standard patch from Red Hat, but it only fixes the problem for the particular issue of accessing registers before execution commences.

The correct solution is to modify GDB with multiple representations for null stack frame. This is a major piece of work, which no one has picked up yet. This is the only solution that the GDB community would accept into the mainstream code base. Not unreasonable if the code base is to be maintainable in the long term.

The OpenRISC port of GDB uses the mainstream GDB distribution and only changes it to add the OpenRISC architecture. There should be no changes to generic GDB. That way upgrading to future releases of GDB is less painful.

Hope this explains the situation. I anticipate that when I next update GDB, I'll add a reference to this somewhere in the OpenRISC specific documentations.

Best wishes,

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

Thanks for the feedback John, and thanks Nathan and Jeremy for the explanation.

John, could you tell me if you implement minsoc on hardware? If yes, what hardware do you have?

I wanted to validate all FPGA dependent code, actually only Virtex5 code is missing. Altera dependent code is the same for all FPGAs and should work equally on all. However, it would be good to have information if it really works on other FPGAs. For now only Cyclone II has been validated.

Best regards,
Raul

---------------------------

Not yet I have the orpsocv2 running on a digilant Nexys board but without the debugger. I have had less luck with minsoc and am still trying to bring up the simulations.

John

Hi John,

How far have you got with getting the debugger to work? I'm working on the next generation of debug interface, so I should be interested to understand what problems you are facing.

Best wishes,

Jeremy

I'm glad you are doing good with orpsocv2.

Still, if you remember what was your problem with minsoc I'd be happy to know it, so I can maybe add notes the the howto file or something (in case I could know the answer).

Best regards,
Raul

Getting orpsocv2 running was easy. I found the sim/run directory and typed make rtl-tests and everything worked, With minsoc I still haven't installed the advanced_jtag_bridge on my system.
If I have an install that requires sudo then I always wait until I can test it out in a sandbox before adding it to my production machine. The big hold up has been lack of time.

I am getting to the point where I need a debugger so I will probably try that soon.

Hi John,



First, I wanted to inform, that you don't necessarily need sudo for adv_jtag_bridge. For now only the xpc3 (parallel cable) requires it. It means, simulation, usb cables they all run on a non-privileged/regular-user basis.

Still I found myself on a system I wanted to enable debugging utilities for, but didn't have root access to. So I rewrote the parallel cable driver for adv_jtag_bridge so it doesn't require sudo. That works only for Linux(not for Cygwin). That's why it has not been placed on the adv_debug_sys project. I will attach the file "cable_parallel.c" which you can replace when compiling adv_jtag_bridge so you can debug using a parallel cable xpc3 without using sudo.

I still wanted to say, that you don't need the adv_jtag_bridge in order to run simulations on minsoc. However you have to comment out the "VPI_DEBUG" definition on "bench/verilog/minsoc_bench_defines.v" to simulate then.

You probably still need to compile your own Icarus Verilog since it has to be the version 0.9.1 or higher. Ubuntu-9.10 still on 0.8, I think. That's for generate and `elsif support basically.

To get the simulation running then is easy: on "sim/run":
#./generate_bench
#./run_bench ../../sw/uart/uart-nocache-twobyte-sizefirst.hex (software has to be compiled before)

The simulation outputs data sent to uart to the terminal screen.

In case you're going to debug, you have to open up two more terminals:
1) on "sim/run"
#./start_server (no sudo, software executed by regular user)
Then wait for "JTAG bridge ready!"
2) on "sw/uart"
#./or32-elf-gdb uart-nocache.or32
target remote :9999 (after this you could load the software but it has been auto-loaded by the testbench when calling it)
set $pc=0x100
c (continue)



I asked afterwards which were your problems running minsoc but they were related to simulation (above).

So, are you for now only simulating and not running it on board? Or you gave up on minsoc after the simulation problems? I am just curious.

I am happy orpsocv2 is working for you, after the interconnect problem has been solved you are surely happier with it.

Nevertheless I don't know how easy is to implement orpsocv2 on hardware after you simulated it. The idea of minsoc was exactly to be easily implemented on different platforms. That's why I asked if you had problems :-).

Best regards,
Raul