17:47 <balrog> borneoa___: thanks for the review :) at this point I'm comfortable with using the Git CLI for Gerrit, so I pushed the fix that way

17:53 <balrog> also I think it would be nice if the next OpenOCD release supports SWD

17:53 <balrog> or rather as part of remote_jtag as more people are getting Glasgow devices

17:58 <PaulFertser> balrog: the next release will get everything that's merged by the time the release is made, there's no separate development branch or anything like that.

17:58 <balrog> Yeah, I figured. The time between releases does seem a little long though

17:58 <balrog> But then again I don't know how much development activity there is in general

18:02 <PaulFertser> That Glasgow is really cool, finally buspirate done by real engineers.

18:06 <PaulFertser> balrog: does using remote bitbang really makes sense from performance point of view there? How does it compare with e.g. FTDI? JTAG and SWD are meant to be batched, that helps a lot with relatively high-latency links. But with a simple protocol there's no way to use that advantage.

18:12 <PaulFertser> balrog: it would make sense to implement FTDI MPSSE for JTAG and SWD there it'd seem.

18:13 <balrog> PaulFertser: ahh, but what hardware would one need to test that?

18:15 <PaulFertser> balrog: not sure I understand. I mean the MCU on Glasgow can implement the device side of MPSSE so from USB host point of view it would be the same as an FTDI chip.

18:16 <balrog> oh I see what you mean

18:17 <PaulFertser> balrog: it really makes sense for most practical JTAG and SWD applications to be able to assemble long queues of commands to be sent all at once to the debug probe. CMSIS-DAP does that too.

18:19 <PaulFertser> remote_bitbang is better than nothing but I'm afraid it's far from optimal, and for the device to be recommended as a debug probe some other protocol needs to be supported.

18:19 <PaulFertser> balrog: what are your practical results speed-wise? How fast can you read from target's SRAM?

18:19 <balrog> I haven't tested that yet

18:20 <PaulFertser> What did you test, flashing?

18:20 <balrog> Mainly reading memory at different addresses, but I didn't test for speed

18:22 <PaulFertser> You can use "load_image" and "verify_image" for testing.

18:24 <PaulFertser> And "dump_image"

18:27 <balrog> will do once I have the hardware set up again

18:28 <PaulFertser> I do not mean having SWD support in remote_bitbang and Glasgow working is bad or useless, not at all. But grossly suboptimal.

18:32 <balrog> right

18:38 <karlp> lol, complaining abotu time between releases is pretty funny coming from glasgow ;)

18:39 <karlp> glasgow's coming together nicely though, glad to see it finally getting out.

19:19 <borneoa___> Apart from license pow, I think that reusing ARM cmsis-dap code would be much easier than implementing MPSSE on device side. But maybe there is already an implementation around...

19:23 <PaulFertser> Indeed, I thought about it but then somehow assumed it's a bit more complicated and filled with ARM specifics compared to basically batched bitbanging that MPSSE or J-Link protocols offer.

20:15 <IoT-Maker> hi, does openocd supports Marvell Armada XP (PJ4Bv7) SOC?

20:16 <PaulFertser> IoT-Maker: any Cortex-A should work for debugging but preparing full config file might take time for complex SoCs.

20:16 <IoT-Maker> can't find a matching target config file

20:36 <karlp> IoT-Maker: so the next thing is, what exactly do you need to do with it? this will determine how much target you need to setup a config file for.

20:45 <PaulFertser> Those are old cores, pre-Cortex, right?

20:49 <PaulFertser> wtf does "ARM v7 MP compatible CPU" mean I have no real idea, the arm naming is confusing

20:50 <PaulFertser> "which has ARMv7 cores somewhat similar to a Cortex-A9 design."

20:57 <IoT-Maker> karlp: I got a Drobo B810i here to fix a failed firmware update. I want a memory dump and upload the firmware to test it.

20:58 <PaulFertser> IoT-Maker: is there a NAND chip there? Does bootloader not start at all, can you interact with it anyhow?

20:58 <PaulFertser> IoT-Maker: have you checked what options the ROM bootloader offers?

21:00 <IoT-Maker> It has a Nand, and an SPI, Device boots, i have 2 UART ports, one with linux root shell, and the other begins a vxworks boot process but i can't enter a working shell environment. I can stop the vxworks boot process ending in a uboot 2.33 shell (with no ethernet)

21:01 <IoT-Maker> strange configuration

21:06 <PaulFertser> IoT-Maker: so dump whatever you need from a u-boot shell over serial

21:07 <PaulFertser> Also if it boots from SPI NOR, you can manipulate that flash externally with a SOIC clip.

21:10 <pedro_a> hi paul , i have been looking for this cpu datasheet from motorola and i can not find it anywhere https://i.postimg.cc/fRPLRwm5/Img-1341.jpg , is there any default pinout for cpus ?

21:11 <PaulFertser> Haha, no pedro_a

21:12 <pedro_a> this one is used in automotive industry , i wanted to jtag the damn thing but i can not find its datasheet anywhere

21:12 <pedro_a> not even reference this model anywhere on the net

21:13 <PaulFertser> JTAG is just a low level transport, you also need debug protocol for this part implemented somehow.

21:16 <pedro_a> most times the same reference of a chip is used in many brands , but this one is from motorola and it looks it is code closed , maybe because it is used in automotive industry

21:18 <pedro_a> i bet those 4 top pins on the left are spi connection :))

21:18 <pedro_a> they are not used

21:24 <IoT-Maker> pedro_a quick check showed me it's used in car-key application, no surprise to me that no public reference is available

22:22 <karlp> 1999 week 20 production code?

22:22 <karlp> man, good lcuk with that one...

22:27 <pedro_a> eheheh

22:27 <pedro_a> there is nothing anywhere on the web about it