On Thursday 22 October 2009, Øyvind Harboe wrote: > It would be advantageous to move in the direction of > exposing common target functionality through the > target->type polymorphic interface. > > Here are some on my list: > > - cp15 manipulation. The cp15 register exists across a wide > range of arm targets. Perhaps mrc/mcr instructions in a > more general way? cp15 is an interesting case because > target->type is not really arm specific, but since we don't > have C++ w/support multiple interfaces per class, etc. > we have to make do best we can. Perhaps simply returning > "unsupported" by default will be a good way to go here.
We need some sort of "generic ARM" core code. But in this case I think we should start with syntax, not implementation. mrc/mcr is more generic, yes, and cp15 registers are core-specific. Thing is, implementing access to those isn't quite generic, as I recall. And then there's stuff like CM3 which doesn't even have coprocessor support ... > - further mmu handling. I'm not quite sure what to expose and > how here. I suspect we'll know we're done with this when we can handle two distinct scenarios cleanly: - Linux kernel debugging, which runs with MMU active and basically uses a fixed MMU context; - Linux userspace debugging (via GDB!), which also runs with MMU active but where the MMU context changes. So for example, we'd want to have a breakpoint apply when one particular task is active ... but not when a different task's MMU context is in use. > Recently made more general: > > - virtual to physical address translation > - physical memory read/write > Yeah, that seemed like the right direction. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
