Skip to content
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

Merge to upstream #8

Open
MarekPikula opened this issue Nov 12, 2019 · 14 comments
Open

Merge to upstream #8

MarekPikula opened this issue Nov 12, 2019 · 14 comments

Comments

@MarekPikula
Copy link

Do you consider merging this version upstream so that there is no need for custom build in future?

This would require also making it Windows-compatible (mainly WinSock-compatible for jtag-tcp). I'll create separate issue for this though.

@MarekPikula
Copy link
Author

Also keeping it aligned with upstream would be beneficial to prevent issues like #6 from happening, which were fixed in upstream already some time ago.

@Dolu1990
Copy link
Member

Dolu1990 commented Nov 12, 2019

Do you consider merging this version upstream so that there is no need for custom build in future?

I personnaly have no interrest in that, but i understand that some people have.

This would require also making it Windows-compatible (mainly WinSock-compatible for jtag-tcp). I'll create separate issue for this though.

Yes that's one of the issues :/
jtag-tcp is quite usefull to connect with simulations, so we should not drop it.

Also keeping it aligned with upstream would be beneficial to prevent issues like #6 from happening, which were fixed in upstream already some time ago.

Yes that's right, already had issues with update of GCC being more picky ^^

So, i'm all for what you propose, the issue is just man power and my personnal willing to do it myself, as i never use it on windows.
If you are interrested into it, i would be happy to review pullrequest and merge them, and at the end try to get this fork upstream.

#9

@MarekPikula
Copy link
Author

Good to hear that. I'm adding it to my backlog for next week.

@MarekPikula
Copy link
Author

Note that for some time I won't have a Windows machine at hand, so I won't be able to work on #9.

@adamfeuer
Copy link

+1 on this.

@MarekPikula Did you ever make progress on this? I'd like to help if I can.

@Dolu1990
Copy link
Member

@MarekPikula @adamfeuer
I got the official RISC-V debug spec implemented on VexRiscv via :
https://github.com/SpinalHDL/VexRiscv/blob/0979f8ba805d23be7989ffff44cb2a383f7fb61d/src/main/scala/vexriscv/TestsWorkspace.scala#L149

  • CsrPluginConfig(withPrivilegedDebug=true)

( Efinix provide the funding :) )

I will have to do some area overhead mesurement to soo how much is lost exactly.

@Dolu1990
Copy link
Member

@MarekPikula @adamfeuer

Amagad, on Artix 7, the whole CPU (in a small config), with the debug infrastructure + jtag tap :
VexRiscv style debug -> 938 LUT 788 FF
RISC-V official style debug -> 1297 LUT 1235 FF

So, not a small overhead to get the official style debug :(

@Dolu1990
Copy link
Member

So, i think it would make sense, even if VexRiscv implement the official RISC-V debug spec too, to merge the lightweight VexRiscv non standard debug implemention in upstream openocd.

@adamfeuer
Copy link

@Dolu1990 That's fantastic about getting the standard RISC-V debug spec implemented. Personally that would be the way I would prefer, despite the lots of extra LUTs/FFs. Has this change already been merged to the master/main branch?

Re: getting the lightweight JTAG for VexRiscv merged to upstream, does it provide the same functionality?

I guess either way I'd be willing to try to get it merged to upstream. I'll look at it today and see if I can update the current code to the current OpenOCD head, I guess that would be the first step.

@Dolu1990
Copy link
Member

Has this change already been merged to the master/main branch?

Not yet merged, but soon will be merged in dev for sure (~2 weeks).

getting the lightweight JTAG for VexRiscv merged to upstream, does it provide the same functionality?

For regular baremetal stuff, yes, that's mostly the same, but things as debug linux kernel / mmu handeling could be way better with the official RISC-V openocd implementation.

I guess either way I'd be willing to try to get it merged to upstream. I'll look at it today and see if I can update the current code to the current OpenOCD head, I guess that would be the first step.

See #24

And as far as i know, that should be all.
let's me know if you have any question / issue :)

@adamfeuer
Copy link

Thanks @Dolu1990. When you say this will be merged to dev, does that mean once this PR gets merged to the dnltz:WIP/dnltz/fix-upstream branch, @dnltz wants to submit a PR to merge his branch to OpenOCD?

@MarekPikula
Copy link
Author

@adamfeuer Hi, unfortunately I didn't have much of a chance to work on it since the 2 years or so.

@Dolu1990
Copy link
Member

@adamfeuer

When you say this will be merged to dev, does that mean once this PR gets merged to the dnltz:WIP/dnltz/fix-upstream branch, @dnltz wants to submit a PR to merge his branch to OpenOCD?

Ahh that's two diferent things, i was talking about the official RISC-V debug implemention in VexRiscv to be merge in the VexRiscv dev branch in 2 weeks.

The dnltz thing is about update this openocd fork with openocd upstream (VexRiscv style debug support)

@Dolu1990
Copy link
Member

@adamfeuer Note, that this openocd fork also add a jtag driver over TCP, with a very simple protocol :
Each byte from openocd to the jtag client (can be a sim) ->
on byte :
jtag.tms #= (byte & 1) != 0;
jtag.tdi #= (byte & 2) != 0;
jtag.tck #= (byte & 8) != 0;
if ((buffer & 4) != 0) { tcpSend(jtag.tdo) }

And that's all. Here is a client implementation for SpinalSim :
https://github.com/SpinalHDL/SpinalHDL/blob/dev/lib/src/main/scala/spinal/lib/com/jtag/sim/JtagTcp.scala#L32

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants