>> > - Various ARMs should be enabling DCC downloads more often, >> > for speed. (Not necessarily release-blockers...) >> >> What we agreed on doing here is to print out a warning if DCC >> downloads + fast memory access were not enabled after reset. > > Sounds fair enough to me; for "after reset" I'd might instead > say "in examine()". Would that be warn-once thing, or would > it pop up after every reset?
I don't think "in examine()" will work, because dcc/fast memory access may well have to be disabled until after reset is "complete". >> This will prompt fixing trivial problems in board/target config scripts. >> Should be easy enough. At this point we only expect DCC to >> be broken for contrived situations(in which case a false positive >> warning won't be a problem). > > Could you elaborate on what "contrived" would be? My current > understanding is that it would involve talking to code that's > running in a target CPU that's running MUCH slower than TCK. > (Or maybe is doing too much work-per-word.) That's my understanding too. So some target that is running at speeds sub MHz speeds or thereabouts post reset. I don't think we'll be able to forsee this situation and we can always accept a patch to address it. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
