00:38 <Guest29> I am trying to connect to Beagle-Y-AI board using OpenOCD. The debugger I use is Olimex - ARM-USB-OCD-H debugger. I am using this guide to connect to it https://openbeagle.org/beagley-ai/beagley-ai/-/blob/main/test-report/test-procedure/am67_jtag_testing.md . When I use the config file in this guide it shows Error: Unknown target type cortex_r5, I

00:38 <Guest29> see in the OpenOCD source code the target supported is only cortex_r4, any idea how to proceed forward?

02:10 <NishanthMenon> Guest29: SoC processor startup sequence requires remote proc to be started up first with Linux. the jtag interface (which openOCD controls) cannot start a CPU by itself. there is a bit of handshake required by s/w to start the processor up (involving communication with secure enclave and the device management components in the SoC).

02:18 <NishanthMenon> Guest29: see https://www.youtube.com/watch?v=mQLLtudWSpQ if you are curious.. that said, your mentioned unknown target type cortex_r5. I just tested the latest tip on another board (am62p, which has r5f), and I see with gdb-multiarch -ex 'target extended-remote localhost:3338': https://www.irccloud.com/pastebin/FGfwYEfa/

02:18 <NishanthMenon> Guest29: tested on "cbc32c3831e3 (HEAD -> master, origin/master, origin/HEAD) flash/nor/stm32l4x: fix permanent write protection on STM32U5"

10:20 <james___> Hi, I asked a while back and nobody seemed to know, for MPC57XX support, but I found this... https://review.openocd.org/c/openocd/+/6148/2

10:20 <james___> does anyone know why it was removed?

10:21 <james___> or just never merged in the first place?

10:22 <PaulFertser> Anyone can pick up unfinished work btw.

10:25 <james___> I'm just not really sure what the state is, do you think it was never merged? Someone sent me some unknown copy of openOCD and it has MPC5xxx, 56xx and 57xx in there so I went looking

10:26 <Haohmaru> maybe no one accepted it?

10:26 <Haohmaru> there's a lot of people poking openocd but in their own personal forks, and not enough volunteers to poke at the original openocd code

10:33 <james___> OK sure, if I can get some sort of interface working then I can test/fix for MPC5777C and 5746G and maybe another that I need to work on soon

10:33 <Haohmaru> which $vendor is that even?

10:33 <james___> I did all the work manually with an arduino mega already and bit banging but it would be nicer to use openocd,

10:33 <Haohmaru> nxp?

10:33 <james___> the chips are NXP yeah

10:34 <james___> One is an existing auto manufacturer - unlocking ECU for tuning, the other two are aftermarket ECUs I need to write the bootloader for from scratch

10:35 <james___> the proper debug tools cost thousands

10:37 <Haohmaru> huh, this is not Arm core?

10:39 <james___> No, they are PowerPC e200 cores

10:42 <james___> I would try to use a pi but the IO voltage is 5v on this ECU, which is why I used an arduino mega originally, I guess I need to make a new openocd driver..

10:44 <Haohmaru> or level-shifting? ;P~

10:44 <james___> I do have some level shift boards handy but wasn't sure if it would cause trouble, sure they will cause a bit of a delay

10:44 <james___> or do raw resistors for level shift..

10:45 <Haohmaru> JTAG or SWD?

10:45 <james___> JTAG

10:46 <Haohmaru> that thing didn't have signals that change direction, right?

10:46 <Haohmaru> (like SWD has)

10:47 <james___> might be OK yeah, it has separate data in/out

10:47 <Haohmaru> so level shifting should be simple-ish

10:49 <james___> yeah I guess, do you have to run openocd on the pi with that bcm2835gpio driver for the pi?

10:49 <Haohmaru> no clue

10:50 <Haohmaru> i only use DAPLINKs with SWD

10:50 <james___> I'll see how complicated the drivers are, would be nice to have an arduino mega rather than have to work on a pi

10:50 <Haohmaru> you wanna use the crapduino board as a debugger?

10:51 <Haohmaru> hm, hold on

10:51 <Haohmaru> what's your current debugger which you normally use?

10:52 <Haohmaru> do i understand right that it's 3.3V while the target you wanna debug is 5V?

10:53 <Haohmaru> because then, what if it could almost work? most JTAG signals are probably debugger->target and probably only a few would be the opposite direction

10:53 <Haohmaru> maybe a 3.3V logic signal could work into a 5V input pin, then all you'll have to do is level-shift down the opposite direction

10:53 <james___> yeah I could try that

10:54 <Haohmaru> HEF4050 for example could work for 5->3.3V

10:54 <Haohmaru> or a pile of other options

10:54 <james___> the only debuggers I have had are maybe a jtagice for AVR, the MPC I have now is on a dev board with a built-in debugger

10:55 <Haohmaru> hm.. is the jtagice "limited" to work only with Atmel stuff or is it usable in general?

10:55 <james___> yeah I might try a raspberry pi and just drop that returning signal and see if it works, it just adds to potential issues

10:55 <james___> that's all

10:56 <Haohmaru> still check carefully how many signals go 5->3.3, "data out" from the target certainly will, but there may be others.. (reset?)

10:56 <Haohmaru> maybe also wait for someone else here who's more familiar with JTAG to give an opinion

10:57 <james___> yeah sure

10:57 <Haohmaru> someone who's name begins with P

10:57 <Haohmaru> ;P~

10:57 <james___> reset definitely, and some of the others might be pulled up to 5v by default so yes I agree

10:58 <Haohmaru> otherwise, for a fancy level shifter, i used some fancy translators.. what were they

10:58 <Haohmaru> 74ahc2g45 or something like that

10:59 <james___> I do have some special level shifter boards with transistors or mofsets or something on, supposedly works in both directions but I'm never sure how they cope with fast comms

10:59 <Haohmaru> https://antonsavov.net/tmp/samd21_daplink.pdf

10:59 <james___> there is still saturation time or whatever it is called with those components before they switch on/off

10:59 <Haohmaru> not g but T

10:59 <Haohmaru> (page 2 there)

11:15 <borneoa___> james___: there is a fork from St microelectronics in GitHub that has support for some PowerPC device, but I don't know if the one you're looking for is also inside. The code level is not ready for upstream, but it's supposed functional. ST has been a second source for NXP PowerPC devices and has also some of it's own devices. You need to check the branch "automotive" something

11:40 <Haohmaru> is that an ST and NXP collab?

11:40 <Haohmaru> not openocd but the chips

13:29 <james___> ah thanks, I will have a look. ST make fake/copy chips which are cheaper but meant to be equivalent

13:31 <james___> I think the ST ones are named like SPC5xxx instead of MPC5xxx

13:33 <Haohmaru> ah, huh

13:39 <james___> I can see PowerPC and some stuff for xPC56 and 58 but not 57, I will come back to it later and see..

14:01 <james___> I have an FT323R USB breakout here, it has all the pins broken out, can I try that with the ft232r driver? I wasn't sure if there was some special FTDI JTAG devices or this is the right thing to use with a raw chip

14:05 <Haohmaru> james___, a bunch of those FTDI adapters can be used with openocd as debuggers, but i don't know details

14:06 <james___> OK I will try and see, I wasn't sure if it was some specific FTDI based JTAG tool or if a raw FTDI chip works, let's see..

14:06 <Haohmaru> particularly i think they have some FTDI chips that support doing bit sequencing in a sorta fast way for "bitbanging" purposes

14:07 <Haohmaru> openocd can use those

14:07 <james___> yeah some of the FTDI chips have more features than others for sure

16:27 <borneoa___> For Haohmaru. No, are not fake NXP devices. Car makers forced NXP to license the PowerPC devices to another company to guarantee having a second source in case e.g. of NXP changing business or products. I don't know how, but ST was choose for becoming second source of compatible devices. Then, later, there was some ST PowerPC device, but I never used them and I don't have all the details.