Hi,
I'd like to use JLink to debug the Linux kernel on Raspberry Pi 4B, which is based on the Cortex-A72 architecture.
I have discovered that debugging works fine when the system runs in ARM32 mode, but it fails when using the AARCH64 (ARM64) environment.
I checked the following points:
In the AARCH64 environment, it is unable to set breakpoints from GDB, and memory accesses are also failing, as shown in the example below.
(But I could read 64-bit registers, though.)
I'd like to ask about:
JLink log:
Display All
GDB logs:
Display All
I'd like to use JLink to debug the Linux kernel on Raspberry Pi 4B, which is based on the Cortex-A72 architecture.
I have discovered that debugging works fine when the system runs in ARM32 mode, but it fails when using the AARCH64 (ARM64) environment.
I checked the following points:
- AArch64/ARM32 environment (ARM32 is okay but not AArch64)
- Kernel randomization disabled
- Trying to read 64-bit registers
In the AARCH64 environment, it is unable to set breakpoints from GDB, and memory accesses are also failing, as shown in the example below.
(But I could read 64-bit registers, though.)
I'd like to ask about:
- Is there anything that I am missing to config in JLink (like 32-bit/64-bit mode.. or something else?)
- Methods to check MMU mappings. Are there any functions supported by JLink solution to check the mapping table?
(Reading physical address 0x082DC210 to read virtual address 0xffffffc0082dc210,4 seems strange. I'd like to look into this.) - I found there are JLink scripts to setup the environment. Should I try or write it up to attach the board for the 64-bit environment?
JLink log:
Source Code
- 01-000008B0-00-00010027-0007: $E01#a6
- 00-000008B0-00-00010032-000D: $qSymbol::#5b
- 01-000008B0-00-00010032-0006: $OK#9a
- 02-00000000-00-00011035-0028: T6B24 012:453.837 JLINK_GetHWStatus(...)
- 02-00000000-00-00011036-0025: T6B24 012:454.838 - 1.006ms returns 0
- 02-00000000-00-00013241-0028: T6B24 014:660.227 JLINK_GetHWStatus(...)
- 02-00000000-00-00013241-0025: T6B24 014:660.976 - 0.752ms returns 0
- 00-000008B0-00-00014457-0017: $mffffffc0082dc218,4#c0
- 02-00000000-00-00014457-003B: T94A0 015:876.763 JLINK_ReadMem(0x082DC218, 0x4 Bytes, ...)
- 02-00000000-00-00014457-0035: T94A0 015:876.792 CPU_ReadMem(4 bytes @ 0x082DC218)
- 02-00000000-00-00014490-001A: T94A0 015:909.126 failed
- 02-00000000-00-00014490-0026: T94A0 015:909.174 - 32.412ms returns 1
- 03-00000000-00-00014490-0034: WARNING: Failed to read memory @ address 0x082DC218
- 01-000008B0-00-00014490-0007: $E01#a6
- 00-000008B0-00-00014490-0017: $mffffffc0082dc210,4#b8
- 02-00000000-00-00014490-003B: T94A0 015:909.738 JLINK_ReadMem(0x082DC210, 0x4 Bytes, ...)
- 02-00000000-00-00014490-0035: T94A0 015:909.760 CPU_ReadMem(4 bytes @ 0x082DC210)
- 02-00000000-00-00014523-001A: T94A0 015:942.603 failed
- 02-00000000-00-00014523-0026: T94A0 015:942.683 - 32.946ms returns 1
- 03-00000000-00-00014523-0034: WARNING: Failed to read memory @ address 0x082DC210
GDB logs:
Source Code
- cpu_do_idle () at arch/arm64/kernel/idle.c:32
- 32 arm_cpuidle_restore_irq_context(&context);
- (gdb) print $pc
- $2 = (void (*)()) 0xffffffc008b814cc <cpu_do_idle+12>
- (gdb) print *0xffffffc008b814cc
- Cannot access memory at address 0xffffffc008b814cc
- (gdb) print 0xffffffc008b814cc
- $3 = 18446743798977926348
- (gdb) print *0xffffffc008b814cc
- Cannot access memory at address 0xffffffc008b814cc
- (gdb) print cpu_do_idle
- Cannot access memory at address 0xffffffc008b814c0
- (gdb) print *cpu_do_idle
- Cannot access memory at address 0xffffffc008b814c0
- (gdb) l
- 27 arm_cpuidle_save_irq_context(&context);
- 28
- 29 dsb(sy);
- 30 wfi();
- 31
- 32 arm_cpuidle_restore_irq_context(&context);
- 33 }
- 34
- 35 /*
- 36 * This is our default idle handler.
- (gdb) n
- Cannot access memory at address 0xffffffc008b814cc
- (
The post was edited 2 times, last by Sukbeom Kim ().