<clever>
PaulFertser: i can now read AP(0) IDR, and it claims to be revision 2 of an ARM memory access port, for AMBA AHB3!
<clever>
AP 1 thru 15 all return 0 for IDR
<PaulFertser>
clever: are you implementing a subset of ADI yourself for now?
shibboleth has joined #openocd
<clever>
PaulFertser: partially just to test things, partially to learn and be able to do basic things without openocd
<clever>
and then openocd can slot in at whichever layer makes the most sense
<clever>
also, i cant get debug logs out of the device if openocd is driving a custom protocol over the main interface
<clever>
so i would have to pause the jtag work and focus on the usb interfaces more
<clever>
as an example, just being able to dump the PC of the cpu, would massively help debug, along with maybe some exception cause registers
joconor has quit [Ping timeout: 265 seconds]
joconor has joined #openocd
<PaulFertser>
clever: I see, makes perfect sense
slobodan has quit [Ping timeout: 255 seconds]
<clever>
for simple tasks, just knowing the PC and fault address is enough to debug things, and you dont have to go thru the whole mess of getting openocd and gdb to play nicely together
<clever>
and if the pico is also handling the uart, it could just detect an unhandled exception and print it right into the uart stream
<clever>
which makes me wonder, can arm trap to the external debugger, only if an exception happens in an exception handler?
<clever>
or would i have to trap every exception, and then filter in the debugger
<Hawk777>
IIRC for Cortex-M you can set vector catch on specific exceptions, so I think you could vector catch on hardfault.
<Hawk777>
No idea how Cortex-A works.
<Hawk777>
I *assume* that if you did that then the others would be handled by the OS.
<clever>
ive had an issue on cortex-A7 before, where the SMP enable flag in ACTLR wasnt set
<clever>
so the load/store exclusive opcodes would jump to the undefined opcode vector
<clever>
the painful part, is that linux hasnt setup the vector table yet, its pointing to undefined data
<clever>
and printk uses load-exclusive...
slobodan has joined #openocd
<clever>
even if the exception handler existed, any attempt to print would trigger itself recursively!
<clever>
hence, wanting an external debugger that can just point to the fault address
<Hawk777>
Again, if you were talking about M, maybe you could point the DWT at the address of the start of the fault handler and maybe configure trapping debug for DWT only? Not sure.
<Hawk777>
Again, may not be relevant to A.
<clever>
how many AP's am i expecting to find on an A53?
<clever>
ive heard mention of a debug rom, where is that?
<PaulFertser>
The Cortex devices are supposed to have "ROM Table" which lists all the components. It's the thing you see with "dap info 0"
<borneoa___>
clever: in each the AP there is a register that points to the beginning address of the ROM table . I think it's named "base"
<borneoa___>
clever: the number of AP depends on the soc. Arm fix the address of cortex-m, so you are forced to have one AP per cortex-m. But cortex-a can be relocates, so a whole smp cluster of A53 can be on a single AP.
<PaulFertser>
MEM_AP_REG_BASE
<clever>
MEM_AP_REG_BASE cant be found in my copy of the ADI
<clever>
but also, i believe the only purpose of the rom-table, is so you can auto-discover the components they relocated?
<clever>
and if i know how a given SoC is laid out, i can skip that
<clever>
assuming its the SoC i expect
<borneoa___>
clever: I forgot you are on adiv6! Then the story is more complex!
<clever>
ah, my pdf says 5.2
<clever>
found a 6.0
<clever>
still no sign of MEM_AP_REG_BASE in that version
<clever>
borneoa___: is there clear documentation on which version of the debug port and ADI each arm core implements?
<Hawk777>
In my copy of the ADIv5 reference (IHI 0031D), the BASE reg is documented on page 167.
<borneoa___>
clever: again if I remember correctly, the DP has a "base" register for the first level ROM table that in turn provides the base address of all the AP (already this is completely different than adiv5). Then, at each of the addresses of these AP you have the base address of the respective ROM table that point to the coresight components.
<Hawk777>
It’s part of MEM-AP.
<Hawk777>
Don’t know about v6.
<clever>
borneoa___: ah, i do see a "Debug Base Addr. (BASE) 0xDf0" sideways on page 173 in v6
<clever>
and yeah, its part of the MEM-AP box on that page
<clever>
is that rom then addressed the same as the base register itself?
<clever>
so basically i just read addr 0xdf0 to get the base, then read addr $base the same way?
<borneoa___>
clever: no, no such document as far as I know. There is the doc adiv6, then several other documents for general coresight 600, and the the technical reference manual of the CPU you get other specific stuff. Then the big mess gets out if you want all the registers of the ETM for that specific CPU
<clever>
would something like the A53 TRM at least say those things? or is it something the implementor can still change up?
<clever>
ah, i do see mention of ADIv5.0 and ADIV5.2 in the A53 TRM
<clever>
hmmm, v6 says IDR is at dfc, while v5.2 says IDR is just at FC
<clever>
given the fact the FC worked, and the A53 TRM doesnt mention v6, i'm thinking i should ignore v6 for now?
<clever>
but that also leads to a new question, how is something like openocd meant to know if its at 0xdfc or 0xfc, and if its v5.2 or v6
<clever>
ah, it looks like reading the rom table involves going thru TAR and DRW, i saw an example of that earlier
<clever>
but this also returns back to a question i was thinking of yesterday, is the MEM-AP accessing the virtual space of a core? the physical space? or some debug space?
<borneoa___>
clever: since your device is adiv6, stick at ihi0074. The CPU TRM only describe the features that are not in the general manual for cortex-a (arm-v8a). You first need to read/write across an AP. The CPU debug registers are after the AP.
<clever>
given that all 4 cores are squashed into a single AP, and could have different paging tables, i'm thinking not virtual
<Hawk777>
Does the IDR tell it whether it”s v5 or v6 maybe?
<clever>
AP(0) IDR: 0x24770002
<clever>
Hawk777: type 2, variant 0, class 8, designer 0x3b, revision 2
<Hawk777>
Ah, maybe not that then.
<clever>
borneoa___: but the A53 TRM only says this:
<borneoa___>
V5 or V6 should be in one register of the DP
<clever>
> The Peripheral Identification Registers provide standard information required for all
<clever>
> components that conform to the Arm® Debug Interface Architecture Specification, ADIv5.0 to
<clever>
> ADIv5.2. There is a set of eight registers, listed in register number order in Table 11-32.
<clever>
no mention of v6 there
<clever>
borneoa___: aha sort of found it, DPIDR, bits 15:12, tells you if its DPv1 or DPv2,
<clever>
oh, but what does v6 say....
<clever>
that adds a DPv3 to the same field
slobodan has quit [Read error: Connection reset by peer]
<borneoa___>
The doc adiv5 don't mention adiv6, neither the other way around
slobodan has joined #openocd
<clever>
so, what address space is the TAR of the MEM-AP refering to?
<borneoa___>
If you read DPIDR, what version you get? DPv3?
<clever>
> The architecture does not require that the TAP IDCODE register value and the DPIDR value are the same.
<clever>
i think this means that DPIDR is missing, because the tap IDCODE replaces it
<Hawk777>
Not necessarily.
<Hawk777>
On the parts I’m most familiar with IDCODE and DPIDR are both present, but IIRC unequal.
<clever>
why might it be reading as 0 then? maybe a mistake in my code?
<clever>
AP(0) CSW: 0x80000042
<clever>
AP(0) DRW: 0x10003
<Hawk777>
No idea. But CSW and DRW are APACCs, while DPIDR is a DPACC.
<Hawk777>
Though it looks like you did that fine in your code you posteed.
<clever>
looking at this diagram, it looks like TAR becomes bits 31:2 of the addr, and then BD0 thru BD3 become a 16 byte window?
<Hawk777>
Do other DPACC reads work fine?
<clever>
CTRL/STAT seems to behave fine
<clever>
when i set one of the REQ UP bits, the matching ACK sets itself
<clever>
and it ignored one of the REQ's, i likely cant bring up SYS and DBG in the same action
<clever>
and it persists between test cycles, so i added code to only REQ if its down
<clever>
which would imply that both dpacc_read() and dpacc_write() are fully functional
<Hawk777>
DPv0 has CTRL/STAT and not DPIDR.
<Hawk777>
Could it be a DPv0?
<borneoa___>
Adiv5 say that DPv0 does not implement DPIDR
<clever>
it could be v0, that would match up with the 0, and never hearing about it having an SWD mode
<clever>
the version summary in v5.2, implies that DPv1 and DPv1 support both jtag and swd
<borneoa___>
I'm checking a stm32f4. In SWD I read DPIDR and get DPv1. But the same device in JTAG I get DPv0!
<clever>
so if it lacks SWD, it must be DPv0?
<clever>
borneoa___: thats also strange!
<borneoa___>
clever: the same device can show different DP depending on the protocol you access it
<clever>
the bcm2837 does also have 2 completely seperate jtag scan chains
<clever>
the VPU jtag is the true system debug port, but public documentation is limited, and the debugger is behind NDA
<clever>
the ARM jtag port only exposes the arm cores, must be enabled by VPU software first, and gets muxed onto the main GPIO array
<borneoa___>
And if you look in the target files of stm32f4, but also other devices, the TAP ID is different on JTAG or SWD, with different DPv*
<clever>
and there are signs that the VPU can bit-bang the ARM jtag from within the SoC, using some non-standard control registers
<clever>
but also, the DP version, doesnt seem to affect the ADI version...
<clever>
or wait?, the ADIv6 seems to imply DPv0 maxes out at ADIv5.0? (page 50)
<borneoa___>
clever: I think the easiest way to handle this is to temporarily stop, take an off-the-shelf adapter supported by OpenOCD and play debugging with your target cortex-a. Discover all the DP/AP map, register content, adiv5 vs adiv6, ROM tables, and only at this point resume your work.
<clever>
i have used an rpi to do that in the past