<Guest16>
Needing help with openocd on raspberrypi 4
Guest16 has quit [Quit: Client closed]
tsal has quit [Ping timeout: 252 seconds]
Hawk777 has joined #openocd
tsal has joined #openocd
boru` has joined #openocd
boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
thinkfat_ has quit [Ping timeout: 265 seconds]
thinkfat has joined #openocd
emeb has quit [Quit: Leaving.]
nerozero has joined #openocd
<antto>
PaulFertser, openocd source? does openocd need to know the chip revision?
<PaulFertser>
antto: sometimes it needs to know the revision to account for quirks
<PaulFertser>
So yes, it does know, and it prints it in the log.
<antto>
hm
<antto>
but does it get that "0x0001" from the chip via the debugger, or does it read .svd files to get the "r0p1" thing?
<PaulFertser>
antto: openocd doesn't read any svd files, it gets it from the chip.
<antto>
i thought so
Hawk777 has quit [Quit: Leaving.]
[_] has joined #openocd
[itchyjunk] has quit [Ping timeout: 265 seconds]
[_] is now known as [itchyjunk]
<clever>
ok, slight problem
<clever>
i'm trying to debug a linux driver, and i want to dump some MMIO manually
<clever>
but i just realized, the MMU is on, and i dont know what virt addr linux mapped that MMIO to!
<clever>
its also giving me trouble with hardware breakpoints
<clever>
Num Type Disp Enb Address What
<clever>
1 breakpoint keep n 0xc0640d78 in unicam_isr at ../drivers/media/platform/bcm2835/bcm2835-unicam.c:800
<clever>
(gdb) enable breakpoints 1
<clever>
[ 2.373117] Unable to handle kernel NULL pointer dereference at virtual address 00000028
<clever>
[ 3.295501] [<c0640d78>] (unicam_isr) from [<c015c7d4>] (__handle_irq_event_percpu+0x6c/0x170)
<clever>
that looks like a useless breakpoint to me!
dodo__ has joined #openocd
<dodo__>
Hello, I'm trying to debug a code that is randomly reseting an STM32 board. I'm not using a watchdog, and I'm not using an RTOS. How would you address a problem like this?
<dodo__>
is it ok to talk about this here? or should I ask in #GDB?
<clever>
dodo__: i suspect you can use a watchpoint to trap any attempt to write to the reset control registers
<clever>
if the reset is coming from the arm core
<dodo__>
Ok, thanks, I will try to do that.
nerozero has quit [Remote host closed the connection]
<antto>
is there like, a reset controller with status registers that can tell you the reason for the last reset? could be many different reasons
<antto>
...like watchdog, power on, brown out, external/debugger, software reset, or none
<dodo__>
That's what I'm looking for, I have been digging in the datasheet of the microcontroller, but It doesn't have that info... I think that it is in the datasheet of the family of microcontrollers
<antto>
it should be documented wherever the other peripherals are documented in detail (how they work, how to use them, registers and stuff)
<dodo__>
I also learned now that there is a hardfault_handler() routine that could be available, but don't know if it was enabled by default, so I have implemented a custom one. A simple buggy code test ended in the hardfault handler, so now I'm waiting that the "random" error in the real code arise.
Hawk777 has joined #openocd
PaulFertser has quit [Read error: Connection reset by peer]
PaulFertser has joined #openocd
<PaulFertser>
clever: mdw has "phys" option, does it not work?
<clever>
PaulFertser: ?
<PaulFertser>
clever: I think you want to poke some MMIO peripherals and you know where it's mapped to, so "mdw phys <addr>" should work if openocd doesn't have another bug in that area.
<clever>
ah, *tries*
<clever>
0x3f801000: 00001210
<clever>
(gdb) monitor mdw phys 0x3f801000
<clever>
yeah, that seems to work
<PaulFertser>
And regarding the breakpoint, apparently it sets something at the right address. And you can check with disassembly (but keep in mind by default GDB installs all breakpoints only before "continue" and removes them after any target halted event).
<PaulFertser>
So I'd first check if the instruction it inserts there as a sw breakpoint is sane.
<clever>
PaulFertser: i'm using hardware breakpoints, because i'm setting a breakpoint in virtual space, before the kernel is even loaded
<clever>
it worked fine last week
emeb has joined #openocd
<clever>
PaulFertser: when transitioning from bootloader to linux, can linux potentially interfere with hw breakpoints jtag/gdb had set?
<PaulFertser>
clever: I think Linux can reconfigure CTI or other related debug modules while it boots.
<borneoa_>
clever: yes. I vaguely remember that by default Linux erases the hw breakpoints and watchpoints at boot. There should be a config option to prevent it
<borneoa_>
clever: that's on armv7, but I expect something similar on armv8 too
<clever>
borneoa_: i'm on cortex-a7 currently, armv7
<clever>
probably near thos string in the source
<clever>
[ 0.156314] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
<clever>
but ive now complicated the situation, by switching from a linked in module, to a loadable .ko module
<clever>
so i wont know what address its at, until i load it
<clever>
but the instant i load it, the system faults hard