Hi! On Tue, Oct 13, 2009 at 7:28 PM, Magnus Lundin <lun...@mlu.mine.nu> wrote: > Yauheni Kaliuta wrote: >> >> Hi! >> >> On Tue, Oct 13, 2009 at 1:28 PM, Magnus Lundin <lun...@mlu.mine.nu> 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.
Well, well, but if you check the patch, it does not abstract even coresight components but just provides memory interface to the address space of that IHI0031A components. > 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. yes, I understand it of course. > > 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. > Looks like I understand you now and agree that my implementation is too narrowed to APB-AP and romtables. I did not think about other access methods if apb-ap is available. Will think about it, thank you a lot for the comments! > >> 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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
