Ah I'm starting to understand things now (atleast in theory).... That was a really insightful!
I just received my debug probe, and I tried setting up openocd with lldb, but I have this weird issue, where the pc is stuck at 0x200 right from when I set the target, and has `udf #0` instructions all the way. The kernel bootstrap code starts at 0x80000, and I don't quite understand why the pc is pointing to 0x200 with an `udf` instruction.
EDIT: openocd logs:And, on setting a target in lldb, I get the following message from openocd:1. The current mode says that the cpu is currently in EL1H mode, but the pc is pointing to 0x200, I don't understand why this is so, because if I'm not wrong, the armstub hands over control to the kernel bootstrap code in EL2 mode.
2. The abort (as seen on a few other online forums) is because the debugger is attempting to write a value onto a memory location, but because the processor is in EL1H mode (and with Secure mode as well), the write fails.
I've also tried the same in gdb, the same abort occurs...
Thanks!
I just received my debug probe, and I tried setting up openocd with lldb, but I have this weird issue, where the pc is stuck at 0x200 right from when I set the target, and has `udf #0` instructions all the way. The kernel bootstrap code starts at 0x80000, and I don't quite understand why the pc is pointing to 0x200 with an `udf` instruction.
EDIT: openocd logs:
Code:
bcm2712.cpu0 halted in AArch64 state due to single-step, current mode: EL1Hcpsr: 0x200003c5 pc: 0x200MMU: enabled, D-Cache: disabled, I-Cache: disabledCode:
Info : New GDB Connection: 1, Target bcm2712.cpu0, state: haltedError: abort occurred - dscr = 0x03047d5b2. The abort (as seen on a few other online forums) is because the debugger is attempting to write a value onto a memory location, but because the processor is in EL1H mode (and with Secure mode as well), the write fails.
I've also tried the same in gdb, the same abort occurs...
Thanks!
Statistics: Posted by kvp_933 — Thu Jun 20, 2024 9:32 am