Yauheni Kaliuta wrote:
> Hi!
>
> On Tue, Oct 13, 2009 at 1:28 PM, Magnus Lundin <[email protected]> wrote:
>
>> Without looking deeply (lot of other work the coming weeks) I think this
>> is good, but I would like it in a separate file(module). Called
>> adiv5_component, adiv5_debug or coresight_component ??
>>
>> So the adiv5 code talks to the MEMAP registers but does not handle the
>> memory mapped components that are accessed through the the MEMAP. This
>> includes the content of the ROMTABLE.
>>
>
> Hmm, I do not think so.
>
> 1) access to components is a part of the same ADIv5 specification IHI
> 0031A (shouldn't it be called then swjdp.c like it was?)
>
>
I will expand my ideas a bit more.
No, IHI0031A does not contain the full component specification, Arm ADI is
the debug interface, and it does not specify the componets. The
specification contains
some information about the rom table structure and peripherial
identification registers.
These are specified in the CoreSight Architecture Specification ARM IHI
0029B.
The actual debug comonents are specified in the ArmV7A TRM and Cortex A8
TRM.
The importatnt distinction is that debug components are accesed through
a memeory space,
from a target level using memory reads and writes to the relevant memory
space/bus.
These components can also be accesed from the processor core over the
memory bus.
The Arm debug interface is just the set of DP and AP registers that the
(recommended)
external access implementation uses for access to this memory range. SWJ
is the method
to talk to DP and AP through JTAG or SW access.
So the only target property that the component needs is the memory
read/write, for the
components the rest of adiv5 is irrelevant. For a target that controls
the components using a
swjdp interface it is also important to use the correct memap port if
there are several, and
to make sure that direct memory access is used with no cache or virtual
addressing handling.
Perhaps we need a taget level structure that describes a "memory port",
something that can
be read and written like memory.
The attributes would be
* valid memory range
* Physical/Virtual memory addressing
* Cache handling
* Pointer to a "memory port driver" that does the actual
For a Cortex A8 we would have one "memory port" for each SWJDP-MEMAP
port for
direct physical access and one "memory port" for program memory that
uses virtual
addressing whem MMU is active and also controls cache cleaning and
invalidation.
We can have a separate "memory port" that accesses memory through the CPU.
Of course twe some work on how to create a user/tcl interface for this
structure.
> 2) if you want to have the layer independent of ap and components
> layers, then there should be no links in that direction, only from
> components towards DP. As a result the cpu layer, which uses both
> components and AP accesses should be aware of scanning, handling
> (storing/freeing...) scanning results and so on.
>
Well, the target layer must be aware that scanning should be done and
that there are
components handled by the "coresight component" layer. Components do
their stuff
by reading and writing to memory.
Even if we let the componets use the swjdp structure to access memory, I
think
it should be placed in a seperate file.
Best regards,
Magnus
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
