Radare2 should be the most promising one; I doubt you'll get anything useful from ARM-console on Thumb.
I find GDB useful not for step-by-step debugging (I find that too slow, and IDA crashes very often, so it doesn't help that much), but with:
- watch *0x1234 (to tell what code writes to that memory address)
- custom logging hooks (to tell when a particular sequence of code executes, and with what arguments / return values / etc)
Most of the time, I use various logging options from qemu -d (many of them are custom logging code, not found in vanilla QEMU), possibly coupled with small GDB scripts (see e.g. generic_log) and grep. The most useful ones: I/O trace with interrupts (-d debugmsg,io,int), call trace (-d calls,tail), RAM trace (-d ram, with variations, or temporary edits to source code to define filters if grep is too slow).
Back to our issue. From what I could tell, the second core (CPU1) gets stuck waiting for interrupt 0xA, early in the boot process; see the EOS M5 notes about GIC.
; 77D
ROM:E0007752 BL gicc_setup ; writes to 0xC1000100 and 104
ROM:E0007756 MOV R0, #0xA
ROM:E000775E BL wait_some_interrupt ; calls WFI in a loop until it gets the expected interrupt
I believe these are meant to generate a software interrupt for CPU1 (77D):
[CPU0] [GICD] at Startup:E0152F04:E0092855 [0xC1001F00] <- 0x2000A : ???
[CPU0] [GICD] at RscMgr:E0152F04:E0092855 [0xC1001F00] <- 0x2000A : ???
[CPU0] [GICD] at RscMgr:E0152F04:000350BF [0xC1001F00] <- 0x2000C : ???
See arm_gic_architecture_specification.pdf, 4.3.15 Software Generated Interrupt Register GICD_SGIR: lowest hex digit is the interrupt ID, and the 0x2 is CPUTargetList (second CPU).
We've got some generic GIC emulation code in QEMU (intc/arm_gic.c); would be great if that can be reused.