boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
[itchyjunk] has joined #openocd
cluelessperson has quit [Ping timeout: 264 seconds]
cluelessperson has joined #openocd
pi0 has left #openocd [#openocd]
[itchyjunk] has quit [Read error: Connection reset by peer]
<borneoa_>
PaulFertser: yes, agree. Will send a v2
Hawk777 has joined #openocd
nerozero has joined #openocd
tarekb has joined #openocd
Haohmaru has joined #openocd
Hawk777 has quit [Quit: Leaving.]
<PaulFertser>
borneoa_: tarekb: hey, asking in case you probably /want/ to pull some ST strings to give clarifications to STM32 users regarding PWM outputs gating by timers. Here's a discussion https://github.com/Ralim/IronOS/issues/1057 and apparently ITRx bits are not documented properly anywhere. You might want to raise an issue with the documentation team or something.
<PaulFertser>
The essential part starts from the second paragraph.
[itchyjunk] has joined #openocd
thinkfat has joined #openocd
thinkfat has quit [Remote host closed the connection]
thinkfat has joined #openocd
thinkfat has quit [Remote host closed the connection]
thinkfat has joined #openocd
thinkfat has quit [Quit: Konversation terminated!]
thinkfat_ has joined #openocd
thinkfat_ has quit [Remote host closed the connection]
thinkfat_ has joined #openocd
thinkfat has joined #openocd
thinkfat_ has quit [Ping timeout: 246 seconds]
emeb has joined #openocd
thinkfat has quit [Ping timeout: 265 seconds]
thinkfat has joined #openocd
[itchyjunk] has quit [Remote host closed the connection]
LinuxHackerman has quit [Write error: Connection reset by peer]
Ulli[m] has quit [Remote host closed the connection]
Helmholtz has quit [Write error: Connection reset by peer]
Jybz[m] has quit [Remote host closed the connection]
pisquo[m] has quit [Write error: Connection reset by peer]
lh has quit [Write error: Connection reset by peer]
Jybz[m] has joined #openocd
lh has joined #openocd
pisquo[m] has joined #openocd
Helmholtz has joined #openocd
LinuxHackerman has joined #openocd
Ulli[m] has joined #openocd
Haohmaru has quit []
jerwd has joined #openocd
<jerwd>
Hi everyone. I just wanted to introduce myself to the group. I just submitted my first patch to the project seen here:
<jerwd>
Please let me know if you have any questions or concerns. Thanks!
<PaulFertser>
jerwd: hey. Thank you for the patch indeed.
<PaulFertser>
jerwd: the review process is rather slow-paced, and sometime you might need to remind about your submission, sorry about that.
<jerwd>
Absolutely! I'm happy to contribute. We've got more patches that I'm going to share as well, mainly around ARMv8 trace stuff.
<jerwd>
Oh, good to know. Thanks.
<jerwd>
For what it's worth, with that patch, we can run the JTAG speed using the Xilinx debug bridge IP on a UltraZynq up to ~20Mhz quite successfully.
<PaulFertser>
Please do not hesitate to send the other patches too, they can be reviewed in parallel.
<jerwd>
Great, thanks. I should have the others ready early next week.
<PaulFertser>
I wonder if your (or similar) setup is documented anywhere, probably some blog post about the features involved. I guess you're elbows-deep in the topic so that's obvious to you but the reviewers might be missing the point completely.
<PaulFertser>
jerwd: I'm personally not doing reviewing but I'll be glad to help should you have any infrastructure (e.g. Gerrit) problem.
<jerwd>
Great, thanks @PaulFertser. I'll let you know if I have any problems. So far, the online documentation for doing the submission was great.
<PaulFertser>
Polished by many failing attempts by quite a few struggling people :)
<jerwd>
Doh! Looks like it failed the Jenkins build. I'll look into that.
<PaulFertser>
Talking about online documentation, there's in fact a paper book with OpenOCD User Manual printed and sold by somebody :)
<PaulFertser>
It would be interesting to learn how and why that happened but I have no idea how to uncover that story.
<jerwd>
I've used OpenOCD for many years. I'm glad that I have a chance to give something back.
<PaulFertser>
Not sure, I think it's dumb to print it. It's changing all the time. That's why it's recommended to always use the _online_ documentation, that is, the one that is installed along with the OpenOCD binary or source on your computer.
nerozero has quit [Ping timeout: 260 seconds]
<jerwd>
Oh yeah, that makes sense. I was kinda thinking the same thing.
<PaulFertser>
jerwd: every commit should be buildable on its own, fix-up commits do not work
jerwd has quit [Quit: Client closed]
jerwd has joined #openocd
<jerwd>
Would it be better to rebase my change and resubmit then?
<jerwd>
And then abandon these previous gerrit submissions?
<PaulFertser>
jerwd: neither
<PaulFertser>
jerwd: I suggest interactive rebased and squash. Just keep the Change-Id of the original main patch.
<PaulFertser>
The extra useless submission with the fixup should be abandoned, yes.
<jerwd>
Ah okay, will do. Thanks. I'll wait to make sure it passes Jenkins first if that's alright.
<PaulFertser>
jerwd: sure :)
thinkfat has quit [Ping timeout: 264 seconds]
<jerwd>
Okay, build worked. Rebased and pushed with the original changeset id. Thanks for the pointers.
<PaulFertser>
jerwd: so are you basically able to HW debug cores on a PCIe board that features UltraZynq via the main PCIe link to it?
<PaulFertser>
Or am I completely missing the point?
<jerwd>
So we have a design that's based on a Zynq, and we use it to debug external devices over JTAG. Think of it like using a raspberry pi w/gpios to debug an external target, but accelerated.
<jerwd>
So it's using a Zynq running Linux w/OpenOCD and a hardware accelerated JTAG logic core in the FPGA side to debug a external device at higher speeds than bitbanging.
<jerwd>
The PCIe code was already there. In that instance, they use a host with a PCIe board with the JTAG acceleration logic. Then they connect that to the device to test.
<jerwd>
We just combined the host and the logic into the same chip.
<PaulFertser>
jerwd: I get it now. Is the source for the accelerated FPGA logic available? Should a reference to it be added to the User Manual?
<PaulFertser>
The manual is in doc/openocd.texi
<jerwd>
Yep, it's available. It's actually provided by Xilinx under license from them.
<jerwd>
Since we based on the existing PCIe version, I assumed that was already there, but I'll double check. Good point.
<PaulFertser>
Thank you!
jerwd has quit [Quit: Client closed]
<antto>
aww, gd32 .svd has a random \t tab char in the middle of a peripheral name
<karlp>
awww did someone start relying on uncleaned machine data? :)
<antto>
what else will you rely on, karlp
<antto>
we're surrounded by machines
<antto>
actually, it's the name of a peripheral's interrupt, but still illegal
<antto>
anyone knows how come "Revision: r0p1" turns into 0x0001, and what should "r2p1" turn into?
<PaulFertser>
antto: you have OpenOCD source for the that, why asking?
jerwd has joined #openocd
jerwd has quit [Client Quit]
jerwd has joined #openocd
_franck_ has quit [Excess Flood]
_franck_ has joined #openocd
<jerwd>
@PaulFertser it didn't look like there was any documentation on the Xilinx debug bridge. Thanks for asking about it. I updated the patch to include some docs/links to it.
<PaulFertser>
jerwd: appreciated!
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
<PaulFertser>
jerwd: hm, guess I should enable building it for GNU/Linux targets but not for windows? I think with the code like it currently is no build coverage is made at all?
<PaulFertser>
If libgpiod is a fix and it's unrelated I think it should be submitted as an unrelated commit.
<jerwd>
oh, the libgpio thing was added in our code by mistake. I don't think that's in the mainline and doesn't need fixing.
<jerwd>
it was a backwards dependency that shouldn't have been there in my commit.
<jerwd>
As for windows, yeah this is specifically for Linux, but it should compile without this feature on other platforms just fine.
<PaulFertser>
I'm looking at Patchset 5 and it's adding "PKG_CHECK_MODULES_STATIC([LIBGPIOD], [libgpiod]" ?
<jerwd>
oh right. okay. Yeah, this changeset requires libgpiod. I think this it's required by anything else though so it's a dependency on this new feature. Does that make sense?
<jerwd>
Lemme look to see if it's used elsewhere real quick.
<PaulFertser>
But libgpiod is upstream since long.
<jerwd>
Ah yeah, I see what you're saying.
<jerwd>
So yeah, we needed that to link statically. You're saying that that single change should be a different fix then?
<jerwd>
Maybe I should take it out as I'm wondering if it will break other uses of it.
<PaulFertser>
jerwd: I see after your commit src/jtag/drivers/Makefile.am gets two identical USE_LIBGPIOD sections
<jerwd>
Ah yep. I see it. I'll fix that. I think I know what happened. When I implemented this, there was no support for libgpio. Merging forward, the same changes were made in the mainline in a different place.
<PaulFertser>
Yes, I think PKG_CHECK_MODULES_STATIC shouldn't be there. Static build should be possible without it too.
<jerwd>
Yep, agreed. I'll remove that too.
<PaulFertser>
I think if the driver depends on libgpiod then it should either auto-select it or configure should fail if you ask for the driver but not for the libgpiod.
<jerwd>
Yep, agreed. I just took those out and retested the build. Seems fine.
<jerwd>
Just submitted patch.
c4017_ has joined #openocd
c4017 has quit [Ping timeout: 246 seconds]
<jerwd>
Oh, one thing I noticed in the docs PaulFertser, it says that // are preferred (C99), but the checker script doesn't like them. Just something I noticed if that's helpful. I removed all mine before I noticed they were okay in the doc.
<PaulFertser>
jerwd: I guess the doc is wrong and some patch is needed for them.