<karlp>
I'm considering hooking up the LA to it, to see just how ~equivalent it is to SWD,
<karlp>
it's another two wire protocol at least, with zero docs, just this openocd impl that talks to the little soic16 on the right there.
<karlp>
but I'm not actualyl familiar enough with swd wirelevel, and it's not reallllly all that interesting to me itself,
<karlp>
plenty of other stuff to do.
zjason` has joined #openocd
zjason has quit [Ping timeout: 240 seconds]
HelloShitty has joined #openocd
sbach has quit [Read error: Connection reset by peer]
RAMIII has joined #openocd
sbach has joined #openocd
ghostbuster has quit [Quit: WeeChat 3.0]
<dormito>
Hmm is openocd supposed to hold off things like interrupts being enabled while it's attached?
<karlp>
by following the core in questions debug specifications...
<karlp>
do you have a specific problem, or just asking in general?
<dormito>
let me rephrase, it seems that some times when I let my core (a riscv core) run (typing continue in gdb), it will suddently have interrupts disable, where they would have been enable if openocd+gdb had never attached.
<karlp>
that sounds like a poor implementation of either the debug adapter, the target support in openocd, or the core itself :)
<karlp>
that's not the sort of behaviour you should expect :)
<karlp>
what target?
<karlp>
(and what interface?)
<dormito>
it's the hifive1 (original, not rev b)
<dormito>
it uses an ftdi jtag adaptor (on the board)
<karlp>
I'm not personally very familiar with the riscv debug specs, onyl enough to know that they're no-where _near_ as consistently implemented as ARM's ADIv5 for instance.
<karlp>
it seems many RV cores made up all sorts of versions of debugging modules.
<dormito>
anyhow, I didn't think it would make sense for openocd to be shutting off interrupts, even when the cores no longer halter, but want to to make sure.
<karlp>
well, oocd is certainly not reaching into peripheral registers andturning them off, but there may be un/poorl specified instructions on how to manage some interactions that arent being followed...
<karlp>
the riscv core I'm working on at the moment for instance doesn't even say what debug spec it uses...
<dormito>
it doesn't use the "riscv debug specification"? I think most of the sifive cores use that ... I haven't had to deal with any other vedors chips... yet.
<karlp>
it might use part of it, but I don't know, I don't have any docs for that portion :)
<karlp>
also, which spec, 0.13? 1.0draft? something interim?
<karlp>
what spec is on your hifive1?
<dormito>
0.11
<dormito>
sifive did document that bit.
<karlp>
see :) what fun :)
<karlp>
openocd has to handle all the differences, and I'v eno idea personally how well it handles them all.
<karlp>
oocd has riscv-011 and riscv-013 files, so... we're probably trying at lesat :)
<karlp>
have you reported it as a bug anywhere else? the riscv-openocd fork, or to sifive or anything?
<karlp>
it definitely isnt how it should be.
<dormito>
I've not reported it anywhere yet, partly because I wasnt 100% sure what the expected behavior was.
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]