On Saturday 06 June 2009, Rick Altherr wrote: > > Again, we don't have such cases today. We can speculate all kinds > > of things, but in the absence of real hardware I don't think the > > results of speculation are compelling. Plus, "$target_name curstate" > > has a very limited range of state outputs, and it would need to grow > > to accomodate such states. > > Actually, many Cortex-A8 designs include power/clock gating for the > processor core.
And some earlier ARMs do strange things in idle states too. ISTR that "wait for interrupt" (WFI) instructions may need special treatment with emulators in use; haven't had much need to look at it myself, before now. > Such devices may have the TAP enabled, but the target > isn't enabled because the power/clock is turned off to it. I'm not > sure that a "$target_name curstate" is the right idea either since as > you pointed out, it would need to grow to handle these cases and we > won't necessarily know what all of them are. I think those are somewhat orthogonal issues though. Power gating is through a separate control framework, which one hopes is accessible without the CPU ... that seems to have been an 1149.7 goal (class T1 has power states), also something of a Nexus goal (in the sense that there seem to be bus access primitives that don't go through the CPU, I recall it as a separate TAP). Clock gating for ARM cores is coupled to stuff like the WFI instruction, but once the core is in a real debug mode at least some of them use that trick of having TCK drive the pipeline at "debug speed". At any rate ... we agree that "curstate" is a trifle weak as models go. > > The IEEE 1149.7 stuff seems to incorporate a "tap state" model of > > sorts ... parts relevant to OpenOCD would be the power states, and > > whether it's routed into the scan chain or not. I'd say those use > > cases are relatively "near future". Not so with "target state". _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
