01:38 <JTAGnuub> hello is anyone there that can help me with a cisco MR18 JTAG hacking quest?

01:56 <JTAGnuub> hello?

02:30 <JTAGnuub> echo

03:05 <jn> hey, be patient!

03:05 <jn> JTAGnuub: welcome to IRC, where people take a while to respond because they might live in another timezone :)

03:06 <jn> JTAGnuub: anyway, what's your request?

12:04 <JTAGnuub> sry im pretty new to all this

13:00 <PaulFertser> JTAGnuub: hi

13:01 <PaulFertser> JTAGnuub: you connected and then disconnected right away.

13:01 <PaulFertser> JTAGnuub: this makes no sense as you won't see the reply if you're not connected.

13:01 <PaulFertser> JTAGnuub: so, what's the question about MR18? I developed that procedure few years ago.

17:05 <JTAGnuub> I basically keep getting an error while trying the MR18 method with a Ras Pi 1 where I can halt the device, but the config file appears to have deprecated stuff, and also It seems always to show "Failed to Enter Debug Mode". Was just hoping to get some advice on why that may be happening

17:23 <PaulFertser> JTAGnuub: you need to use some pastebin to show full output from OpenOCD and all your additional files.

17:31 <JTAGnuub> Ok, I will do it next week sometime, traveling the rest of the week now.

17:33 <PaulFertser> JTAGnuub: where did you get config file from and what did you change in it?

17:33 <PaulFertser> JTAGnuub: also how come you can halt the device but at the same time you say it fails to enter debug mode? At what point?

20:55 <NishanthMenon> at the risk of self promotion, but more on the interest of "if anyone in EOSS, seattle next week wants to talk OpenOCD, lets get together" https://sched.co/1aBGL -> I will be talking OpenOCD recently added dmem support a bit.. if anyone wants to sync up, lets do it..

20:55 <NishanthMenon> my slides should be online atm..

20:56 <PaulFertser> Promotions like that are always good!

20:57 <NishanthMenon> yup.. I hope we see more OpenOCD talks.. but anyways.. threw it in there..

20:57 <NishanthMenon> thank you all for the help and guidance (again)..

20:59 <PaulFertser> Yeah, the slides are there.

21:01 <PaulFertser> NishanthMenon: may I make a suggestion about the config.gz line?

21:02 <NishanthMenon> Paul, sure

21:03 <PaulFertser> NishanthMenon: zgrep /proc/config.gz DEVMEM

21:04 <NishanthMenon> sure, will update. thank you. I was a bit distracted when I copy pasted from history to slide " cat /proc/config.gz |gunzip|grep DEV|grep MEM"

21:04 <NishanthMenon> just need to see if zgrep was installed by default in beagleboard.org minimal images..

21:05 <PaulFertser> First I thought why gunzip when you could have used zcat. Then I saw it pipes into grep, so there's zgrep. Then I saw it filters for something unrelated so includes a V4L option where MEM comes before DEV.

21:05 <NishanthMenon> yep..

21:06 <NishanthMenon> thanks for catching it.. :)

21:12 <PaulFertser> NishanthMenon: I wonder if you normally need mem.devmem=1 kernel parameter too.

21:12 <PaulFertser> And hm, probably STRICT_DEVMEM doesn't actually prevent access to MMIO peripherals on Arm.

21:13 <NishanthMenon> I am not sure, actually - had'nt dug deeper.. However, i know this: autosd from fedora for Arm64 did'nt work out of box (and i went searching why) Vs debian build from beagleboard.org just worked..

21:13 <NishanthMenon> s/fedora/redhat/

21:13 <PaulFertser> ./bootstrap should automatically fetch submodules

21:14 <NishanthMenon> aah ok

21:14 <PaulFertser> And /usr/local is default prefix anyway.

21:14 <NishanthMenon> ok

21:15 <PaulFertser> Do you actually mind all this nitpicking probably?

21:15 <NishanthMenon> i always love it :)

21:16 <NishanthMenon> thank you once again.. you know the effect that one cant see one's own little things.. so it helps.. (i also was organizing booth and working on another paper at the same time.. so probably could have done better..)

21:16 <PaulFertser> The next one is that it was installed already to /usr/local/bin so it should be just "sudo openocd" since you count on it using the installed configs anyway.

21:17 <NishanthMenon> aarghh.. ofcourse :)

21:17 <PaulFertser> Sure, it's really hard to proofread one's own work.

21:18 <PaulFertser> And then you do not need ./ before board/ti...

21:18 <NishanthMenon> ack

21:23 <PaulFertser> Talking about the DAP ROM table, glad to see TI parts finally started to have it :)

21:26 <NishanthMenon> hehe - yeah - we have been verifying it during presilicon as well - except for one little crap.. i think it tends to come out fine.. the problem i have is that ROM entries are integrated at subsystem level, so if the power domain is down, you dont see the ROM entry (as the bus segment will be down). kinda irritating when you want a complete dump of the full SoC.. but you only get the segments that have been powered on..

21:27 <NishanthMenon> but meh, anything is better than crappy or no data..

21:29 <PaulFertser> Indeed

21:30 <PaulFertser> Yes, OpenOCD had some rudimentary trace buffer support but that was even before Cortex.

21:31 <NishanthMenon> yeah - i have'nt had time to dig at CTI and ETB implementations in OpenOCD.. hoping to take it some day if time permits

21:36 <PaulFertser> NishanthMenon: CTI is obviously there for aarch64 breakpoints to work. But ETB just not implemented anyhow if you do not count rudimentary ARM9 stuff.

21:36 <NishanthMenon> aah ok - i didn't know that.

21:39 <PaulFertser> NishanthMenon: I'm not sure about the target audience there, I would probably consider an overview slide about why one might need to debug M4 or R5 cores there at all. And I'm not sure if I get it right but normally they only run code supplied to them from Linux by remoteproc, right? How would that play along with debugging and could one upload new code with "load" in GDB?

21:39 <PaulFertser> BTW, why do you need to set architecture explicitly for gdb-multiarch, isn't it getting it right from the XML file while negotiating with OpenOCD?

21:41 <PaulFertser> Thank you so much about all you kind words and endorsements for OpenOCD community, really appreciated.

21:41 <NishanthMenon> yeah - I did do a different session for R5 and m4f debug :( -> trouble was trying to figure out what depth do we go.. for gdb-multi-arch - you are right, i dont need to set arch specifically.. but with everything else I do (pattern of which u noticed above) - i like to do things redundantly to make sure I recollect what the heck was happeneing.. just an overkill - i will add a note. thanks for noticing it

21:41 <NishanthMenon> in terms of endorsement - that is the very least I can do.. you guys really rock.. I do enjoy just hanging around and catching up every morning.. always something new to learn :)

21:42 <PaulFertser> It's just that the more info on slides the harder to read them, especially from a distance. OTOH it's good to have extra hints when reviewing the slides later on a computer.

21:42 <NishanthMenon> hmmm... true..

21:43 <NishanthMenon> let me try and take your feedback in tomorrow morning and see if i can move more stuff to backup slides.. i did have a feel it was a bunch of busy slides.. but i will make an effort.. thanks for suggesting, Paul.

21:45 <PaulFertser> I wonder where does ITM from M4 go.

21:45 <NishanthMenon> there is a trace funnel path

21:45 <PaulFertser> And how to get data from it? I am just curious.

21:46 <NishanthMenon> i have'nt dug into that either.. the trace path itself is a deep area as well - TRM seems to have some details on it.. on lauterbach at least (native), I had itm data stream out per channel..

21:46 <NishanthMenon> i have'nt tried that on OpenOCD.. :(

21:49 <PaulFertser> I think it wouldn't hurt to add a slide or two with a quick mention something like "typically the R core is running a RTOS to provide guaranteed timely response to external events; and M4 is used for (idk, talking to power controller of motherboard?)" We also saw people (ab)using them for crazy stuff like (something unorthodox).

21:51 <PaulFertser> Something to make people think that debugging those cores is not only fun but also useful :)

21:53 <NishanthMenon> Thanks Paul - Good point, yeah makes sense.. let me get that in as well..

22:02 <PaulFertser> I have a similar "meme" picture for my linkedin profile :)

22:06 <PaulFertser> I'd also mention watchpoints in addition to breakpoints. They're so nice especially on a controller without MPU when one task corrupts another.