<zapb__>
PaulFertser, Gerrit is unreachable / slow at the moment
Haohmaru has joined #openocd
<Haohmaru>
gamiee, i don't like mailing lists either, not sure how gerrit is involved, to me it looks more similar to gitlab/github/etc..
<Haohmaru>
i personally use gitlab, i also submit and keep track of a lot of "issues" for kicad, which is on gitlab, so i'm at least somewhat familiar with the UI around that
<Haohmaru>
gerrit kinda sorta looks like a similar thing in my eyes
Hawk777 has quit [Quit: Leaving.]
<PaulFertser>
zapb__: it's like Heisenbug, I'm starting to look at it and it disappears.
<PaulFertser>
I noticed high i/o wait for a while.
<Haohmaru>
hm, wasn't there also a copy of the original openocd on github?
<Haohmaru>
that gets sync'ed up with the gerrit thing
<Haohmaru>
oh, the main code is on sourceforge, but code is reviewed on the gerrit thing, huh
<PaulFertser>
I ionice'd gerrit and jenkins appropriately, let's see if it changes the responsiveness.
<Haohmaru>
PaulFertser, perhaps on the "irc" page it should be mentioned that the people in here are from all kinds of timezones and that visitors should have patience longer than a few minutes
<PaulFertser>
People using Internet kinda know about different timezones.
<Haohmaru>
of course, but then they come here ask a question and /quit after 2 minutes
<Haohmaru>
(not just here, happens in other channels too)
<PaulFertser>
Yeah but probably they are not worth talking to? ;)
<karlp>
re maintainers and process time, perfect is often the enemy of good.
<karlp>
I completely understand that maintainers often err towards perfect to attempt to steer load towards the contributoros instead of future maintainers, but it means things can get stuck for a LONG time.
<Haohmaru>
perhaps you're right... how good can an impatient developer be
<karlp>
no, that's not what I mean,
<karlp>
well, perhaps.
<karlp>
but sometimes it's "this hasn't been tested against these other 50 things taht you don't have" isn't ever going ot happen.
<Haohmaru>
if it was up to me i'd still add that chunk of text to the page, an impatient guy still won't sit here for over 2 minutes because he's impatient, so it can't hurt
<karlp>
so we have no k32l anything in the meantime.
<Haohmaru>
isn't there room in openocd for partial support?
<Haohmaru>
or "work-in-progress" or "experimental-support"
<karlp>
it's not an openocd thing only
<karlp>
micropython has been holding up a change on pwm for esp32 for almost 2 years because it's not "flawless"
<karlp>
openwrt/linux do this all the time as well.
<karlp>
but maintainers always have a lower threshold
<karlp>
it's completley understandable of course,
<karlp>
maintainers are the limited resource,a nd they only want to work on their own things.
<Haohmaru>
yeah my impression is that some dude is suddenly interested in some chip, openocd doesn't know about it, he hacks it in and he only cares for that
<Haohmaru>
thus a pile of forks exist
<PaulFertser>
karlp: probably Tomas has it and can give you remote access?
<Haohmaru>
NXP have done some sh*t with device identification, huh
<karlp>
nothing out of the ordinary, just 40 years of product evolution, with attempts to move both forwards and to new styles.
<karlp>
PaulFertser: it's just an example of progress being blocked because it's not enough progress.
<PaulFertser>
karlp: reading the conversation on 8089 it looks like you can come to common ground even without physically getting a k32l3 or testing on one. There were many other review points and I guess if you "just" make a reasonable effort at not making future k32l3 support harder by following the datasheet and Tomas's advice that would already count as good enough.
<PaulFertser>
The driver is apparently used in production now even though it's rudimentary.
<karlp>
heh
<karlp>
"production"
<karlp>
that's where perfect never comes up :)
<PaulFertser>
I also do not have access to the hardware by now :/
<karlp>
yeah, threee different people tried to get efm32 "series 2" devices into openocd, they all failed on perfection ratings, and now none of us work at those companies anymore.
* karlp
shrugs.
<karlp>
it's ok, removing const keywords will make it better ;)
<Haohmaru>
eh, const everywhere!!11
<gamiee>
Haohmaru : yeah, like, it's useful if someone hacks support for some chip together in a fork and it's done, as it's better than nothing. But I don't like when companies does this and treat it as "oh we have openocd support".
<Haohmaru>
that sux
<gamiee>
(also, thank you borneoa___ for review and great suggestion! will implement it soon)
<gamiee>
I am kinda surprised that Zephyr and companies around it does not support upstreaming and stuff in openocd.
<karlp>
too busy adding more layers to zephyr :)
<Haohmaru>
if only... vendors added support for their stuff into openocd, or at least gave technical information about it so others could without having to h4x0r it
dliviu has quit [Ping timeout: 272 seconds]
dliviu has joined #openocd
Deneb has joined #openocd
olerem has quit [Quit: WeeChat 3.8]
olerem has joined #openocd
en-sc has joined #openocd
braunr has joined #openocd
<en-sc>
Hi everyone! I'd like to ask for feedback on https://review.openocd.org/c/openocd/+/8504 . Is there anything I can do that would help with reviewing this patch chain?
en-sc has quit [Remote host closed the connection]
en-sc has joined #openocd
<PaulFertser>
en-sc: hey
<PaulFertser>
en-sc: your patches look nice but I can imagine why it can be hard to review. It's really not that obvious when and how exactly you're going to use that multi-tap scan. I see https://review.openocd.org/c/openocd/+/8505 but I can't find a rationale explaining how this functionality is needed for what usecases.
<PaulFertser>
en-sc: you might want to write a mail to the mailing list explaining the needs and ideas behind your patch series to draw more attention and interest.
<en-sc>
Thanks! Will do
<karlp>
it also sounds like "this will do no harm, but no-one else needs => ignored"
<PaulFertser>
en-sc: OpenOCD is really understaffed unfortunately so you're doing the right thing adding maintainers and asking for review. Sometimes it takes few tries unfortunately.
<PaulFertser>
en-sc: from my really cursory look (I do not properly review patches since long, so take with a grain of salt) the patches are good but without a rationale it's hard to convince maintainers more code is not going to hurt maintainership long-term.
<PaulFertser>
en-sc: and btw, thank you for taking time to upstream properly, it's really nice, important and appreciated!
<Haohmaru>
i don't even know what a single-tap is ;P~
<Haohmaru>
target access port?
<PaulFertser>
en-sc: I can kind of guess you have several risc-v targets there in a chain and you want to do something with them faster than it's currently possible but it's not at all clear how a Tcl command helps (OpenOCD is supposed to handle the cores at target level properly) and whether it's really a bottleneck given the big picture.
<en-sc>
Haohmaru: here TAP is a JTAG's Test Access Port
<en-sc>
PaulFertser: the concern is not the throughput but the latency in-between accessing different targets
<en-sc>
Imagine you have a couple cores behind two different TAPs
<en-sc>
and you want to resume them both
<PaulFertser>
en-sc: it would be nice to know more specifics about a usecase requiring lower latency there.
<Haohmaru>
so basically, write this sorta as a motivational/marketing text so the reviewers understand it better and get all hyped up? ;P~
<PaulFertser>
en-sc: so is the plan to add more machinery to the target level to allow synchronous resuming? Because I guess it doesn't belong to the JTAG layer (though I understand you need that multi-tap scan to actually implement it).
<en-sc>
Sure, I'll describe it in the letter. Thanks again for the guidance!
<PaulFertser>
en-sc: when I think about resuming I mostly imagine interactive debugging sessions where latency doesn't matter much.
en-sc has quit [Remote host closed the connection]
en-sc has joined #openocd
en-sc has quit [Ping timeout: 240 seconds]
en-sc has joined #openocd
en-sc has quit [Remote host closed the connection]
en-sc has joined #openocd
en-sc has quit [Remote host closed the connection]
en-sc has joined #openocd
en-sc has quit [Remote host closed the connection]
en-sc has joined #openocd
en-sc has quit [Remote host closed the connection]
en-sc has joined #openocd
en-sc has quit [Changing host]
en-sc has joined #openocd
en-sc has quit [Remote host closed the connection]
Deneb^ has joined #openocd
en-sc has joined #openocd
en-sc has quit [Remote host closed the connection]
en-sc has joined #openocd
Deneb has quit [Quit: Leaving]
Haohmaru has quit [Quit: saionara]
en-sc has quit [Remote host closed the connection]
Deneb^ has quit [Quit: Leaving]
zjason`` has joined #openocd
zjason` has quit [Ping timeout: 260 seconds]
nerozero has quit [Ping timeout: 252 seconds]
russ has joined #openocd
tlwoerner has quit [Remote host closed the connection]