Steffanx- has quit [Quit: Connection closed for inactivity]
Krazubu has joined #openocd
tsal has quit [Ping timeout: 250 seconds]
tsal has joined #openocd
Krazubu has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
thinkfat has quit [Ping timeout: 250 seconds]
thinkfat_ has joined #openocd
tsal has quit [Ping timeout: 250 seconds]
tsal has joined #openocd
Hawk777 has joined #openocd
Bertl is now known as Bertl_zZ
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
nerozero has joined #openocd
LaserPete has joined #openocd
Krazubu has joined #openocd
Hawk777 has quit [Quit: Leaving.]
Krazubu has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
Haohmaru has joined #openocd
Krazubu has joined #openocd
Krazubu has quit [Client Quit]
ErikSchillingAbl has joined #openocd
<ErikSchillingAbl>
Hi, I am trying to debug Linux on an imx8qm using an olimex ARM-USB-OCD-H debugger and OpenOCD (compiled from git). I can break the current execution perfectly fine and see where it was executing, but I seem to be unable to set breakpoints (both hardware, as well as, software). I read some vague "MMU awareness is limited" in the docs and I assume that software breakpoints are not working is due to Linux write-protecting the executable
<ErikSchillingAbl>
sections? But why are the hardware breakpoints not working? Do I need to set those on the actual memory hardware address of the RAM? Or do I also use the MMU address there? Sorry if these are stupid questions, these are my first steps with JTAG debugging, chances are that I am doing something wrong, feel free to tell me :P
<PaulFertser>
ErikSchillingAbl: please stay on channel, I hope someone here has more experience with aarch64 debugging.
<PaulFertser>
Current code just doesn't support hw breakpoints on aarch64.
<ErikSchillingAbl>
PaulFertser: will do :). I am connected via Matrix, so hopefully that will stay connected 😊
<PaulFertser>
Hm, if you have none available.
<ErikSchillingAbl>
Ah. Good to know. Thanks!
<PaulFertser>
ErikSchillingAbl: what do you get if you connect OpenOCD while the target stays in a bootloader?
<ErikSchillingAbl>
I somehow got it into a state where it reliable stopped somewhere in the middle of an entirely unrelated function, but I was unable to reproduce that...
<ErikSchillingAbl>
PaulFertser: gimme a second to try that!
<PaulFertser>
ErikSchillingAbl: but you can stop booting in bootloader by sending it something over serial usually.
<ErikSchillingAbl>
Yes, I am doing that... Somehow getting errors during examination now... Let me drill into that for a sec.
<olerem>
ErikSchillingAbl: hi. if you fail to connect jtag on botloader, then jtag pins are probably now muxed to something different. Or jtag functionality is disabled
<PaulFertser>
ErikSchillingAbl: great, olerem is much more experienced than me when it comes to SoCs, I hope now you're in the right hands :)
<ErikSchillingAbl>
But that is a good hint. I will try to verify the muxing
<olerem>
ErikSchillingAbl: if core is not power on, it wont be examinated
<olerem>
i assume on imx8qm, the a53 is turned on by some secure component (SCM? or something like this)
<ErikSchillingAbl>
olerem: yes, thats how it happens from my understanding too. I am sitting in the u-boot prompt right now. So one of the a53 or a72 cores should probably be running :P (unless the prompt puts it to a sleep again?)
<olerem>
i would not expet from a bootloader to have some active power managment
<ErikSchillingAbl>
Running a while true loop from the u-boot prompt did not help. I will try to confirm the muxing then (though that should probably affect all cores equally, right?)
<olerem>
yes
<PaulFertser>
ErikSchillingAbl: ok, and what do you get from examination when you boot to Linux?
<olerem>
if at least part if the chain is accesable, then it is not pinmux
<ErikSchillingAbl>
<PaulFertser> "Erik Schilling (Ablu): ok, and..." <- PaulFertser: did the file made it through the Matrix IRC Bridge?
<PaulFertser>
It did
<ErikSchillingAbl>
olerem: Ok. Thanks for confirming :). I will try to keep messing while hopefully understanding this better. Thanks for the help so far already!
douardda_ is now known as douardda
LaserPete has quit [Remote host closed the connection]
<ErikSchillingAbl>
<PaulFertser> "It did" <- PaulFertser: did you see anything in the log? 😇
<PaulFertser>
ErikSchillingAbl: yes, Info : 344 303 armv8_dpm.c:1469 armv8_dpm_setup(): imx8qm.a53.0: hardware has 6 breakpoints, 4 watchpoints
<PaulFertser>
ErikSchillingAbl: did you choose the target with "targets" command prior to setting a breakpoint?
<ErikSchillingAbl>
PaulFertser: not manually... Let me check the imx8 tcl config... It looked like openocd hosted one gdb server per core, so I thought it would know what core I am connecting to from there?
<PaulFertser>
ErikSchillingAbl: yes, but if you're running "monitor" commands they go directly to Tcl interpreter probably.
<PaulFertser>
Not sure, never worked with multi-target setups.
<ErikSchillingAbl>
PaulFertser: I get that while standing in `cpu_do_idle` (kernel code)
<ErikSchillingAbl>
Ok... Wait... Now the hardware breakpoints work... I just set a breakpoint using `monitor bp 0xffff0000080a1a9c 4 hw` in my gdb session. It reported: ```gef➤ monitor bp 0xffff0000080a1a9c 4 hw
<ErikSchillingAbl>
can't add breakpoint: resource not available
<ErikSchillingAbl>
no hardware breakpoint available
<ErikSchillingAbl>
So maybe it just did not set the breakpoints on all CPUs and I did not see my other code triggering because it happened on other cores?
<PaulFertser>
ErikSchillingAbl: does OpenOCD know all your course are part of same SMP domain?
<ErikSchillingAbl>
At https://openocd.org/doc/html/GDB-and-OpenOCD.html I found: "20.7 Using OpenOCD SMP with GDB" -> "OpenOCD includes a pseudo RTOS called hwthread that presents CPU cores ("hardware threads") in an SMP system as threads to GDB." is that something I need to enable? Or is it the default? Googling `openocd hwthread` does not come up with anything that helps me to understand this :/
<PaulFertser>
ErikSchillingAbl: it's not enabled by default.
<PaulFertser>
ErikSchillingAbl: if you tried GDB on multi-threaded program with "info threads" then you can see what it's about
<PaulFertser>
ErikSchillingAbl: with this pseudo-rtos GDB will see as much threads as you have cores. And you'll be able to halt them all at the same time and then switch between threads to see backtrace for each of them.
<ErikSchillingAbl>
PaulFertser: But pseudo-rtos sounds like I would need to modify the software running on my target?
<PaulFertser>
ErikSchillingAbl: no, it's just $_TARGETNAME configure -rtos hwthread
<olerem>
ErikSchillingAbl: are you debugging some RTOS or linux kernel?
<ErikSchillingAbl>
olerem: Linux kernel. Thats why the `rtos` thing confused me a bit :P
<olerem>
ErikSchillingAbl: for kernel you will need some gdb helpers provided by the kernel
<PaulFertser>
hwthread helps with debugging SMP issues
<PaulFertser>
It's not RTOS specific
<ErikSchillingAbl>
olerem: ok. I will look into that. Do you have any pointer to that? 😇
<olerem>
ErikSchillingAbl: do you need to debug kernel with jtag to sole some lowlevel boot issue?
<ErikSchillingAbl>
olerem: Thanks a lot! That is enough to keep me busy until tomorrow :P
<ErikSchillingAbl>
olerem: my ultimate target is to debug a reboot and figure out why the reset reason does not have the right value. So this will probably be some interaction between the main and management core... For now I just tried to get the debugging working at all.
<olerem>
ErikSchillingAbl: on some boards, reboot is connected to some extarnal pmic or a reset circuit, which will power down/up complete SoC. In this case, local reset flag will be lost
<ErikSchillingAbl>
olerem: Thanks for the hint. I will also review the circuit diagrams. For now I just wanted to get the JTAG debugging running, since that may be interesting sooner or later anyway :)
<olerem>
have fun!
wolfshappen has quit [Quit: later]
Bertl_zZ is now known as Bertl
ampleyfly has joined #openocd
wolfshappen has joined #openocd
wolfshappen has quit [Ping timeout: 256 seconds]
wolfshappen has joined #openocd
thinkfat_ has quit [Quit: Konversation terminated!]
thinkfat has joined #openocd
thinkfat has quit [Quit: Konversation terminated!]
Hawk777 has joined #openocd
nerozero has quit [Ping timeout: 250 seconds]
Haohmaru has quit []
Bertl is now known as Bertl_oO
<ErikSchillingAbl>
Thx :)
<PaulFertser>
ErikSchillingAbl: got it working better?
<ErikSchillingAbl>
PaulFertser: I did not try the SMP things yet. I am currently looking into getting a debuggable ELF file for the SCU M4 core... Currently I only have a binary blob... Not sure if I can actually exchange that one myself or whether it needs to be signed by NXP...
<PaulFertser>
ErikSchillingAbl: oh. I think olerem might have an idea, they had some imx8 projects iirc.
<ErikSchillingAbl>
I just got started reviewing the documentation. It looks like there is some documentation for manually tweaking it. I just do not fully understand which parts of the firmware are signed and which not... But I will get there :). The documentation seems to be fine, I just need to penetrate the heavy acronym usage 😆
<ErikSchillingAbl>
Anyway... Good night for today! Thanks for all the help! I am sure I will come up with new questions in the next days :)
<PaulFertser>
ErikSchillingAbl: good luck with your project :)
Steffanx- has joined #openocd
jetpax has joined #openocd
diddly_ is now known as diddly
Krazubu has joined #openocd
jetpax has quit [Quit: Leaving]
thinkfat has joined #openocd
Krazubu has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
Krazubu has joined #openocd
Krazubu has quit [Client Quit]
Krazubu has joined #openocd
Krazubu has quit [Client Quit]
thinkfat has quit [Quit: Konversation terminated!]
thinkfat has joined #openocd
tchebb has joined #openocd
Steffanx- has quit [Quit: Connection closed for inactivity]