search

riscv-collab / riscv-openocd

Fork of OpenOCD that has RISC-V support
Other
439 stars 319 forks source link

OpenOCD should support targets that don't implement a program buffer #112

Closed timsifive closed 6 years ago

timsifive commented 7 years ago

It would be really helpful to have an FPGA image or something to test against.

TommyMurphyTM1234 commented 6 years ago

What exactly are you looking for in case we (Microsemi) can assist? Do you have one of our boards? If so which one?

timsifive commented 6 years ago

Looking for a RISC-V debug target that does not implement the program buffer, but instead implements the system bus access. The SiFive implementation (which I believe you're using some variant of) doesn't qualify.

I do have an M2GL_M2S_EVAL board, and I regression test against it (mainly to get old trigger coverage) fairly regularly.

ghost commented 6 years ago

I can't offer a FPGA image, but I do have a Debug Module design for the Pulpino that uses system bus access instead of program buffer. I am trying to test the design at the moment and am will to try code and feedback issues.

We have tried using the OpenOCD and get an "Unable to write ebreak" error. Scanning the code I had assumed that, currently, only Program Buffer systems are supported, but this comment list seems to imply that system bus is supported. Are non-program buffer systems supported?

timsifive commented 6 years ago

Non-program buffer systems are not currently supported. I want to support them, but need something to test against.

ghost commented 6 years ago

Thanks for the prompt reply. I was worried that would be the answer. Just to clarify, I understand from your statement that non-program buffer support is not started yet. Is that correct?

timsifive commented 6 years ago

It has not been seriously started. In theory register access as well as run/halt/step should already work.

Also note that when I say non-program-buffer, I'm still referring to a debug interface that complies with the latest draft of the spec. Pulpino used to do something completely different for debug, and I'm not planning on supporting that.

ghost commented 6 years ago

We could not get as far as trying "register access and run/halt/step". As part of the initialisation, OpenOCD seems to check that their is enough (any?) program buffer. When it checks the abstractcs and finds the progsize is zero we get "Unable to write ebreak". This happens early on in the initialisation, in the examine stage I think, but I would need to check.

One thing that occurred to me. Is there any inference made about program buffer presence from the IDCODE. For in house testing we are using the SiFive code ATM.

I understand about the Pulpino debugger. The JTAG and their system bus access module has been replaced. The Pulpino Core has a dedicated "Debug Port" that gives run/halt/single step and GP/CS register access. I have also put in translation logic to convert the 0.13 standard for (abstract) register access and halt/run/stepping control to Pulpino Core Debug Port accesses.

timsifive commented 6 years ago

You're right that OpenOCD currently requires a program buffer for the initial target discovery. As part of some other changes I hope to be fixing that over the next few weeks.

There's no need to rely on IDCODE, since the debug spec already specifies the size/presence of a Program Buffer in the dmstatus register.

ghost commented 6 years ago

The fix sounds great. Let me know here and I can try it out. This is all sounding more positive than I thought at the start :). The program buffer seemed to be heavily relied upon in the start of the code, I thought that removing the dependency would be hard to patch for someone who does not know the code. Adding the system bus access, I guess, might be something I can try to patch.

I'm trying to keep with the 0.13 methodology, but am under pressure to revert to Pulpino design.

Thanks for the clarification on IDCODE.

timsifive commented 6 years ago

I just pushed my work-in-progress to https://github.com/riscv/riscv-openocd/tree/small_progbuf It should pass the initial detect and be able to access registers without a program buffer. Memory access does not work at all in this branch, but depending on how eager you are to try something, you might be interested. It should provide a starting point if you want to implement memory access using system bus access.

ghost commented 6 years ago

Wow that great Tim. We should be able to give it a try middle of next week. I let you know the results. Thanks for your help.

ghost commented 6 years ago

We have given small_progbuf a try. No issues with the OpenOCD. Just a couple of hardware bugs to fix :(. The main issue was that I was not reporting an error for 64bit register access and this resulted in a fail later in the initialisation performed by OpenOCD. I have done the HW fixes, so we will be retrying next week. I'll report back once I have more news.

timsifive commented 6 years ago

Great! Thanks for the update. I anticipate merging small_progbuf some time this week. At that point I think everything will work without a program buffer except for memory access.

On Sun, Oct 22, 2017 at 1:34 PM, cdredd notifications@github.com wrote:

We have given small_progbuf a try. No issues with the OpenOCD. Just a couple of hardware bugs to fix :(. The main issue was that I was not reporting an error for 64bit register access and this resulted in a fail later in the initialisation performed by OpenOCD. I have done the HW fixes, so we will be retrying next week. I'll report back once I have more news.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-openocd/issues/112#issuecomment-338507085, or mute the thread https://github.com/notifications/unsubscribe-auth/APYH7eJsfN0MK-93bkf-TICRZL7wPYBkks5su6bugaJpZM4PberD .

timsifive commented 6 years ago

This is implemented as of change 3c1c6e059c0129743b3b7f26dcd96e0aa0faa380