10:08 <Glaure69> Hi. Is it possible that https://repo.or.cz/w/openocd.git is offline?

10:11 <karlp> very

10:11 <karlp> git clone "https://review.openocd.org/openocd" is probably best.

10:12 <karlp> PaulFertser: https://openocd.org/pages/repos.html still says that repo.or.cz is primary mirror? that's out of date right?

10:13 <Glaure69> My problem is that "yocto" openembedded wants to clone from https://repo.or.cz/w/openocd.git during image build.

10:13 <Glaure69> Well I will try to patch the bitbake recipe

10:20 <PaulFertser> karlp: it used to work nicely...

10:20 <PaulFertser> It says "official" not primary.

10:21 <PaulFertser> Both github and repo.or.cz are official

10:21 <karlp> ah, I thought it had basically shut down operation.

10:21 <karlp> it had problems for so long I thought we'd formally abandoned it.

10:21 <PaulFertser> I'm not sure

10:21 <karlp> nvm, my memory problem

10:22 <PaulFertser> Even http://log.or.cz/ doesn't work.

10:22 <PaulFertser> Hm, it does.

10:22 <karlp> from our page, it's primary purpose was that itw as on https, so worked behind firewalls, but even sf offers that now...

10:23 <karlp> ahh, I'm remembering this: https://sourceforge.net/p/openocd/code/ci/94e7535be85a7bd5905dec68b6eae9a98aae0d7e/

10:23 <karlp> we switched away from using repo.or.cz as a repo for jimtcl

10:23 <karlp> probably not really reasonable to say that we still consider it a good source for _us_ then...

10:25 <barath> hey all! Does anyone know what the procedure is for getting a merge request like https://review.openocd.org/c/openocd/+/5161/ rolling again? Seems like it's abandoned/forgotten. I recently needed it, found it, and applied that on top of master after resolving conflicts. seems to work fine and would be great to have in master?

10:26 <Glaure69> OpenST Linux image builds fail because of this.

10:26 <Glaure69> openstlinux-5.10-dunfell-mp1-21-11-17/layers/meta-openembedded/meta-oe/recipes-devtools/openocd/openocd_git.bb

10:27 <Glaure69> SRC_URI = " \

10:27 <Glaure69>     git://repo.or.cz/openocd.git;protocol=http;name=openocd \

10:27 <Glaure69>     git://repo.or.cz/r/git2cl.git;protocol=http;destsuffix=tools/git2cl;name=git2cl \

10:27 <Glaure69>     git://repo.or.cz/r/jimtcl.git;protocol=http;destsuffix=git/jimtcl;name=jimtcl \

10:27 <Glaure69>     git://repo.or.cz/r/libjaylink.git;protocol=http;destsuffix=git/src/jtag/drivers/libjaylink;name=libjaylink \

10:27 <Glaure69>     file://0001-Do-not-include-syscrtl.h-with-glibc.patch \

10:27 <Glaure69> "

10:27 <Glaure69> I wonder who I should inform to change this recipe ...

10:28 <PaulFertser> Glaure69: looks like you need to follow the way patches are sent for any meta-oe recipe.

10:29 <Glaure69> I will do

10:30 <PaulFertser> barath: I suggest you add your review to the patch and then send a mail to the devel mailing list asking for merging.

10:33 <PaulFertser> barath: the patch however has some unrelated changes. It both adds support for the new part and adds lpc2000_op_codes enum. I'd say the maintainers will ask to split it into two.

10:33 <barath> alright, thanks PaulFertser

10:33 <PaulFertser> barath: you can basically take the ownership of the patch by pushing a new version while keeping old Change-Id. And then ping the mailing list.

10:34 <karlp> that would be nitpicking though, the original patch should never have been accepted by those standards...

10:36 <karlp> bleh, now review.openocd.org is hanging

10:36 <karlp> so much for leaving review comments :)

10:37 <barath> Okay, thanks for the tips :) very new to openocd so the pointers are appreciated

11:05 <borneoa_> Glaure69: I have already patched openSTlinux recipes to skip repo.or.cz due to too many users complaining. I don't remember if it's already in public recipes or would be in the new version that will be published in next weeks

12:32 <dormito> I found a section of the openocd docs that says openocd doesn't really have much (any) support for powerpc targets (especially thinking of the freescale/nxp MPC parts). However it also says that non-jtag isn't support (which I know is false, I use openocd with SWD fairly often). Is the lack of powerpc support still true?

12:34 <PaulFertser> dormito: unfortunately, no powerpc support, there's no documentation.

12:36 <dormito> Hmmm. yeah that'd be a pretty big hurdle :/. Thanks for the confirmation.

12:51 <dormito> Hmmm. While I'm looking for a board to mess with via jtag to larn about jtag debugging (and thus not more that superfically familiar with it), it looks like at least some of the freescale/NXP MCP ppc chips have their jtag insturctions doucmented, it seems the docs for the debug (instead of boundary scan) are available for some of the freescale/NXP core in their core referance manual (I pulled up

12:51 <dormito> the RM for the e200z0 since that was a core on a board I was considering).

12:54 <PaulFertser> dormito: probably things have changed since people last discussed it here. In any case adding a new debug target is challenging, even when documented.

13:30 <dormito> yeah. I'd consider doing it myself... if I wasn't trying to climb up the learning curve of jtag myself, lol (and and the free time).

13:35 <PaulFertser> dormito: jtag is basically a state machine you control with TMS, TCK, TDI. There're standard instructions for boundary scan but everything else is up to the vendor. So CPU, MCU vendors developed their own protocols on top of JTAG using it as a transport for some debug protocol.

13:37 <PaulFertser> dormito: after giving https://www.xjtag.com/wp-content/uploads/tap_state_machine.gif a close look you can say you know JTAG :)

13:37 <PaulFertser> Instructions go to IR (instruction register), data goes to DR.

16:59 <indy_> dormito, keep me informed, i have some ppc (e200 ... e500) targets and other nexus based like rpi's vc4 :)

17:00 <indy_> dormito, there are some unfinished works in gerrit