lowrisc-chip
lowrisc-chip copied to clipboard
lowRISC
+waitdebug problem
I have managed to build the simulation via:
make CONFIG=DebugConfig in vsim directory
next I would like launch the RTL simulation and but the debug tool couldnt connect correctly when I run:
./DebugConfig-sim +waitdebug
of which I didnt manage to see the output on the terminal. Basically there is nothing printed at all.
Glip TCP DPI listening on port 23000 and 23001
I have successfully build both Glip Software and Open SoC Debug software
and also I tried to connect the daemon on the second terminal
opensocdebugd tcp
I observed the following outcome:
Open SoC Debug Daemon
Backend: tcp
glip: glip_open: Cannot open backend
glip: glip_write_b: No connection; you need to call glip_open() first!
glip: glip_read_b: No connection; you need to call glip_open() first!
opensocdebugd: ../../src/connection-standalone.c:67: receiver_thread_function: Assertion `rv == 0' failed.
Aborted (core dumped)
any advice what could have possibly gone wrong?
Sorry, I cannot reproduce the issue. I just did a clean checkout of the minion-v0.4 branch and it worked as expected. Which distribution are you using? Anything else you tried before?
I am currently using minion-v0.4 as well. However I have made some changes in config.scala in order to build a new CONFIG for simulation. The new CONFIG has the extension of ++ new WithDebugConfig as well. But it didnt work. And everything else I have tried was not successful as well.
But just now have just did a clean checkout of the 'minion-v0.4' and yes you are right it works!
Im wondering could it be that I have messed up the scala codes in the files though Im quite sure that I didnt touch anything related to the UseDebug in the files?
Ah ok. I have checked my coding and yeap I have accidentally messed with the UseDebug in the LowriscvScala.scala file. After amendment and re-run
./DebugConfig-sim +waitdebug
I manage to get the following on Terminal 1
Glip TCP DPI listening on port 23000 and 23001
and hence I proceed with connecting the daemon on the second terminal
opensocdebugd tcp
I get the following outcome:
Open SoC Debug Daemon
Backend: tcp
System ID: dead
6 debug modules found:
[0]: HOST
version: 0000
[1]: SCM
version: 0000
[2]: DEM-UART
version: 0000
[3]: MAM
version: 0000
data width: 16, address width: 32
number of regions: 2
[0] base address: 0x0000000000000000, memory size: 65536 Bytes
[1] base address: 0x0000000040000000, memory size: 134217728 Bytes
[4]: CTM
version: 0000
addr_width: 64
data_width: 64
[5]: STM
version: 0000
xlen: 64
Wait for connection
However on my Terminal 1, I have the following printout running continuously:
C0: 2713091 [1] pc=[0000000000] W[r 5=0000000040000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[40000297] DASM(40000297)
C0: 2713092 [1] pc=[0000000004] W[r 0=0000000000000008][1] R[r 5=0000000040000000] R[r 0=0000000000000000] inst=[00028067] DASM(00028067)
C0: 2713093 [0] pc=[0040000000] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000000] DASM(00000000)
C0: 2713098 [1] pc=[0000000000] W[r 5=0000000040000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[40000297] DASM(40000297)
C0: 2713099 [1] pc=[0000000004] W[r 0=0000000000000008][1] R[r 5=0000000040000000] R[r 0=0000000000000000] inst=[00028067] DASM(00028067)
C0: 2713100 [0] pc=[0040000000] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000000] DASM(00000000)
C0: 2713105 [1] pc=[0000000000] W[r 5=0000000040000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[40000297] DASM(40000297)
C0: 2713106 [1] pc=[0000000004] W[r 0=0000000000000008][1] R[r 5=0000000040000000] R[r 0=0000000000000000] inst=[00028067] DASM(00028067)
C0: 2713107 [0] pc=[0040000000] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000000] DASM(00000000)
C0: 2713112 [1] pc=[0000000000] W[r 5=0000000040000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[40000297] DASM(40000297)
C0: 2713113 [1] pc=[0000000004] W[r 0=0000000000000008][1] R[r 5=0000000040000000] R[r 0=0000000000000000] inst=[00028067] DASM(00028067)
C0: 2713114 [0] pc=[0040000000] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000000] DASM(00000000)
C0: 2713119 [1] pc=[0000000000] W[r 5=0000000040000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[40000297] DASM(40000297)
C0: 2713120 [1] pc=[0000000004] W[r 0=0000000000000008][1] R[r 5=0000000040000000] R[r 0=0000000000000000] inst=[00028067] DASM(00028067)
C0: 2713121 [0] pc=[0040000000] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000000] DASM(00000000)
instead of which I am expecting:
Client connected
What could have possibly went wrong here? Any advice?
Hi,
I observed the same. This somehow got reactivated, it is the printf-style debug output of the rocket core. It tells you which instructions finished. As no software is loaded, it just hangs. @wsong83 can we deactivate it again.
Everything is fine and you should now be able to execute the debug commands.
Cheers, Stefan
Alright noted.
One more concern,
After run
./DebugConfig-sim +load=hello.riscv +waitdebug on Terminal 1 (the program file is in the same directory as the simulator)
opensocdebugd tcp on Terminal 2
osd> reset -halt
osd> terminal 2
osd> start
on Terminal 3
There is a xterm terminal appear but I did not observed the printout of "Hello World" as written in hello.c
And also,
running the python script :
python runelf.py hello.riscv
gives me the following error:
Traceback (most recent call last):
File "./executable/runelf.py", line 1, in <module>
import opensocdebug
ImportError: No module named opensocdebug
sorry again for causing so much trouble and inconvenience thanks for your attention :)
@wallento Originally we though when trace debugger is enabled, trace printout can be replaced with instruction trace collected by trace debugger. However, the instruction trace nearly always buffer overflow. In practice, for debugging the hardware, the trace printout is kind of preferred rather than the instruction trace. So I revert the configuration back to enable trace printout by default, even when the trace debugger is enabled. What do you think? Once the trace debugger is improved, then this trace printout can be finally sent to history.
@clare7 For the no printout in the 3rd terminal, you need to check with the trace printout to see whether you have the hello.riscv successfully loaded and executed, especially looking for the first instruction on 0x4000_0000, is it an illegal instruction again? If not, perhaps now it is a good opportunity to get your hands dirty on using the software trace to debug the program. What you see can be caused by various reasons, I do not think I have enough info to say what went wrong.
Hi I just checked. The first instruction is indeed on 0x4000_0000. I have also run CTM and STM and check the log files. Seems like the hello executable is running alright but just the character was not shown on the xterm terminal. Im wondering could it possibily due to the uart baudrate setting? At one point of testing I get to see one letter H on the terminal.
You mean software trace is by the means of STM?
And one more issue from my last post. I have problem running the phython script which gives me the following error:
Traceback (most recent call last):
File "./executable/runelf.py", line 1, in
Is the library opensocdebug the correct naming?
Hi,
are you sure the opensocdebug python bindings are in your PYTHONPATH?
About the UART the baudrate is not the issue, because the module actually just ignores it. It is as fast as the debug infrastructure. Let me think about it and check locally.
Cheers, Stefan
@wallento Oh you are right there. The path generated from the source set_env.sh is not pointing to the lib folder for python binding. Thanks! now the script works!
as for the XTERM trace printout, this is what exactly I have from my side. As you can see there is a letter 'H' instead of "Hello World" :
Hi,
The problem remained the same of which I am not able to solve yet. At the moment I just the STM and CTM for debugging and testing.
But it would be good if we also know what is the issue for this 'H'
On Wed, Sep 20, 2017 at 7:37 PM, Wei Song (宋威) [email protected] wrote:
Any update on this single 'H' problem?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/69#issuecomment-330825364, or mute the thread https://github.com/notifications/unsubscribe-auth/AcHzHP9q6UF0hxKNYbxECc3COTW-40Z6ks5skPkCgaJpZM4PBNjg .
-- Regards, Ming
I think the reason for neither Stefan nor I had provided any feedback on this was that we cannot reproduce the error.
Generally speaking, this looks odd. If the CTM/STM mechanism works all right, the trace debugger emulated terminal should just work out-of-the-box. To print out a character, some instructions running on a core need to write the control registers of the emulated UART. This emulated UART will then convert such character print request into a debug message and send it on the debug network. This message is delivered to the host computer, which analyses the message and shows the character on the corresponding terminal.
As in your case, a single letter 'H' appears on the correct terminal, that means the emulated UART has at least correctly converted one print to a debug message. All of these, including the hardware connection to the emulated UART and the debug network towards the host computer, are quite battle ready. So I cannot easily think of any reason why it worked for only one character.
If you want to dig deeper and find out why it does not work on your machine, I would suggest: Use the STM to trace the print out process. Add a software trace event every time there is a IO load/store to the emulated UART. Then you can tell whether the print program has successfully sent out all characters to the emulated UART. If this turns out to be true, I think it would then indicate some UART messages are somehow lost on the debug network or mistreated on the host computer. Anyway, it will provide some info which we can play with.