You could refer to the section "2. Debug u-boot with CodeWarrior for ARMv8" in Use CodeWarrior for ARMv8 to Debug U-boot and Linux Kernel and Bring up Bare Boards to configure CodeWarrior IDE panels to debug bl2 with "attach" method. Please import atf/build/ls1088ardb/release/bl2/bl2.elf in CodeWarrior IDE.
ATF is a simple bareboard application, so you should be able to debug it accordingly. There’s no special guide needed. Given the fact that ATF resides in flash and then copied to OCRAM, you’ll need an “attach” launch configuration. As far as I know, there are two elf files required for debugging, one for BL2 and one for BL31. Also, depending on the MMU configuration, you might need to mark some areas as read-only, in order to force HW BPs to be used from GDB. See ‘mem’ command for more details.
I brought in discussion the MMU configuration in a more general sense – so not strictly related to ATF. It’s important to know that debugger (GDB) defaults to software breakpoints by default and they will not work on read-only MMU ranges. So you can either set hardware breakpoints using GDB’s ‘hbreak’ command, either add read-only/write-only memory ranges in GDB (see ‘mem’ command) and force GDB this way to always set HW breakpoints inside those ranges.
Regarding the MMU configuration performed by ATF, I’m pretty sure it configures MMU. Moreover, I think I’ve accidentally noticed at some point the ATF marking some memory ranges as read-only – but not sure. So, please discuss this subject with someone working on ATF or inspect the ATF sources yourself. There’s also a GDB command implemented in CW-ARMv8 that allows users inspect current MMU configuration – see ‘mmu’ command and its description (use ‘help’ in Debugger Console or read ch. 6.5.6 from ARMv8 Targeting Manual).
