<zear>
but it's not being used in this case, because mips32_pracc_queue_exec is called with check_last = false
<zear>
I'd like to send this fix upstream, so here goes my question:
<zear>
should I manually add extra NOPs to the epracc_list, or rather call mips32_pracc_queue_exec with check_last = true, subjecting it to those extra checks unrelated to instruction padding?
<zear>
also, I have no idea how that would affect other MIPS32 platforms, and whether this should be a JZ4780 specific quirk
<PaulFertser>
zear: there's a chance nobody here knows :(
<zear>
yea, I imagine MIPS is not a popular platform anymore :)
<PaulFertser>
zear: probably someone with PIC32 can check.
dliviu has quit [Ping timeout: 260 seconds]
dliviu has joined #openocd
nathanhi has quit [Quit: bye]
nathanhi- has joined #openocd
nathanhi- has quit [Remote host closed the connection]
nathanhi- has joined #openocd
nathanhi- is now known as nathanhi
<olerem>
zear: some day ingenic contacted our company to mainline openocd support for this series of chips. But at the end decided to not doing it. MIPS went to be a hot potato which no body rellay wont. I would not recommend creating new products with it
<zear>
olerem, they maintain their own port of openocd, but guess what - it doesn't work with JZ4780 :D
<olerem>
it looks like to company is stalled back for 3 years. Somewhat in the time of last contact
<zear>
I'm not particularly interested in their current products, but I maintain Linux platform drivers for JZ47xx family
<zear>
so I have interest in openocd working with those SoCs
<olerem>
zear: do you do this for hobby or some kind of sentimental reasons?
<zear>
both
<olerem>
i see. for same ereasons i kind of try to maintain MIPS on openocd. But i do not use it in any projects
<zear>
back in the day, I wrote a bunch of software for the JZ47xx based handhelds, particularly Dingoo A320, GCW Zero and Ben Nanonote
<zear>
that's the sentimental part
<zear>
and I upstreamed a bunch of platform drivers for those SoCs to the Linux kernel, that's the hobby part
<olerem>
i feel your pain, but ma be it's time to let it go? (I ask it for my self too)
<zear>
well, at the company I work for, we recently had a project where I used openocd to debug client's MIPS based board
<zear>
and that was a pretty lucrative deal for us :)
<zear>
so I don't think it's time to let MIPS go
<PaulFertser>
I'd say if you feel like supporting MIPS in OpenOCD, go for it, do what you need to get your hardware working and let the other complain and send patches.
<zear>
yea, I think I'll do just that
<PaulFertser>
zear: and lack of feedback shouldn't discourage you, just keep pinging Antonio here once a week :)
<zear>
noted :)
<olerem>
if you have patches, add me to CC for revieing
<zear>
I will
<zear>
these go through gerrit?
<olerem>
ack
<zear>
hmm... can I send in patches without creating a Gerrit account?
<PaulFertser>
zear: not really :( Is that a huge obstacle, why?
<PaulFertser>
zear: I mean how one is supposed to participate in patch review then? It's not a mailing list patchwork unfortunately.
<zear>
It's an obstacle, yes. I'm not interested in creating accounts.
<zear>
I somehow expected to send in a patch to a mailing list
<PaulFertser>
zear: account is created automatically when you log in using any of the third-parties SSO services or your own OpenID instance.
<PaulFertser>
zear: if you can't do it it's still better to send a patch to the mailing list (than not sending it at all anywhere) so that someone could find it searching the Internet.
<zear>
Is there a mechanism in place for submitting someone else's patch, like with the Linux kernel?
<PaulFertser>
Yes, one can just submit someone else's patch, pushing to Gerrit is the same as pushing to a remote git repo.
<PaulFertser>
(in Gerrit terminology "submit" means merge the change to official branch; here I used submit as in "send for review")
<zear>
so it sounds like I could send it over to the mailing list, or just drop the patch here, and someone else could publish it on gerrit
<PaulFertser>
Could, but how will you be able to reply to feedback?
<PaulFertser>
And to push amended versions if CI fails.
<PaulFertser>
It's better to have it on Gerrit even if you do not plan to proceed with it.
<PaulFertser>
I can push your patch no problem.
<zear>
hmm... I guess checkpatch.pl also requires gerrit integration, because it refuses to parse my patches
<olerem>
zear: do you use tools/checkpatch.sh or tools/scripts/checkpatch.pl
<zear>
the former, which then calls the latter
<zear>
<PaulFertser> zear: I mean how one is supposed to participate in patch review then?
<zear>
That one is tricky indeed. As mean as it sounds, I guess the person publishing the patch takes the responsibility of responding to review feedback. And I sit on IRC and talk to that person :(
<PaulFertser>
zear: no, checkpatch can be run locally the same way as CI runs it.
<PaulFertser>
zear: do those two patches on pastebin pass checkpatch for you?
<zear>
no, I think I am lacking those gerrit ids that are supposed to be automagically appended to the commit message
<borneoa___>
zear: the script considers the second argument as a git revision
<PaulFertser>
And yes, the error is not related to Change-Id.
<borneoa___>
zear: by the way, locally here the two patches pass through checkpatch with no errors. I just had to run dos2unix and split them in 2 files
<zear>
they apply cleanly through `git am dump_of_pastebin`
<zear>
but I'm glad to hear they pass through checkpatch on your end
<zear>
ah, I'm supposed to run it like this: ./tools/checkpatch.sh HEAD~2
<zear>
now both patches pass cleanly on my side as well
<zear>
PaulFertser, do I need to pastebin the patches again with the Change-Ids, or is that irrelevant?
<zear>
uh-oh, a merge conflict? These aren't applied against master?
<PaulFertser>
zear: for the second the merge conflict is expected as the default strategy is cherry-pick.
<zear>
ah, makes sense
<PaulFertser>
zear: do you also refrain from contributing from projects hosted on github?
<zear>
sorta - I have an old account that I used to contribute to some projects, but I don't host any new projects of mine on github
<PaulFertser>
You could be using that old account to log in to OpenOCD Gerrit...
<zear>
I am aware of that, but I don't want to use it
<PaulFertser>
I can relate to that, I self-host an old OpenID instance just for using OpenOCD Gerrit.
<zear>
free software projects should be free to contribute, and I feel that creating accounts and accepting various terms of use to those services is not exactly free
<zear>
interesting, maybe I should look into that
<zear>
not many services these days accept OpenID though, huh?
<zear>
On a sort of similar note, good job on maintaining the openocd project, guys :) My colleagues use super expensive J-TAG hardware with even more expensive commercial software, just because they are "easy to set up" and don't require you to use a terminal...
<zear>
while I can use a $100 j-tag probe and debug pretty much any hardware
nerozero has quit [Ping timeout: 256 seconds]
<PaulFertser>
zear: btw, OpenOCD Gerrit (code review) and Jenkins (CI) are self-hosted too.
<zear>
that is nice
<zear>
usually people (companies) use externally hosted solutions, just because it absolves them from responsibility in case of data breach