I've successfully established a JTAG connection and serial port connection to my development board. I've followed the below diagram (with a little bit of difference).

my GDB_client is on my Linux host but my OpenOCD is on my windows host and they communicate with each other using GDB_server over network. they communicate with each other easily and I can load applications to my board via GDB on my Linux over JTAG.


this is my platform specifications:

SOC: STM32H743 (Cortex m7 single core -> ARMv7E-M)
Internal Flash: 2MB (only u-boot is in the flash memory)
Board: Waveshare CoreH7XXI dev board
On-board DRAM: 8MB
SDCARD: 1GB (the ROOTFS and Linux kernel are in the SD card)
Bootloader: mainline U-boot
kernel:     mainline Linux kernel

Debug Probe: STLink V2

According to this guide: Loading a kernel in memory Once you are used to using gdb to debug kernels you will want to use gdb to directly load kernels onto your target. The most practical way of doing this is to set a hardware breakpoint at the start of the kernel and reset your board using the JTAG reset signal. Your boot loader will initialize your board and the execution will stop at the start of the kernel. After that you can load a kernel into memory and run it.

I put beak point on the starting point of my kernel, but the problem is that it won't stop on the breakpoint to let me load the vmlinux file to my memory.

This is what I'm doing:

(gdb) file vmlinux
(gdb) target remote
(gdb) break __init_begin
(gdb) cont
(gdb) mon reset #perhaps this needs to be done from the openocd telnet session..
Breakpoint 1, 0xc0008000 in stext ()
(gdb) load vmlinux

I've also tried this but again, it didn't stop on the breakpoint:

(gdb) break *0xD0008000
Breakpoint 9 at 0xd0008000: file arch/arm/kernel/head-nommu.S, line 61.


Sometimes it works and sometimes it won't. It seems after resetting my board, I should swiftly pause my program using gdb and again resume it to make it work. Why is this happening?


Have you tried disabling the 'kaslr' option? I am also trying to set a breakpoint but mine never hits. I tried disabling it by passing the 'nokaslr' in bootargs but this does not take effect. I am assuming that it is not taking effect because on the target board(Xilinx Zynq Ultrascale+) I still see the 'full randomization' option selected.

I used cat /proc/sys/kernel/randomize_va_space on the target board.

I am not sure if this is the way to go but my gut says that this address mismatch is the reason for the breakpoint not being hit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.