Hi Arnd,

...

The memory-mapped interface is hugely unreliable in real hardware because you have to calculate the address of the memory-mapped debug registers by using a base and offset, which are hardcoded in some information registers. Unfortunately, I've never found a board where these registers have been programmed correctly so (a) I had nothing to test my code with (b) few people would be able to use it and (c) there's not really a safe way to go around poking random areas of memory.

So the only problem is that it's board specific? That's something we know how to deal with -- all I/O components have some random board specific address, and we put them in a platform device that is listed in the board file. This should be easy enough to do for another register area, though it means we have to do it separately for each board.

Correct - and I think registered this thing statically from the BSP code is the only real option we have. This does mean that somebody will need to find a board where this stuff works and then try and find out where the debug registers live in memory.

...

The simple rule is Cortex-A8 is unsupported and Cortex-A9 is supported. The A5 should work (untested) and the A15 will need a bit of hacking to get it supported.

Is that because A8 is memory mapped and A9 uses CP14, or is there another problem with A8?

That's right, the A8 is memory mapped so is why it doesn't work with the current code. It's worth taking into account that I don't know of any other cores (current or future) that use the memory-mapped debug interface, so any work in this area will benefit only the A8 (and those platforms known to have working (i.e. powered) memory-mapped debug at a known offset) for the forseeable future.

Will