On Sunday 10 January 2010, Øyvind Harboe wrote: > > (b) Øyvind's desire for an "erase_address" option to pad > > to sector boundaries. > > This would be a new feature. If we have the ability to erase > all sectors in an address range, we have no regression outstanding.
The issue is that the previous code had a dangerous interface bug, whereby it implicitly trashed data it was told to leave alone. Adding a "pad" option gives that "ability" without the bug. IME, leaving interface bugs like that is a really bad thing to do. So the way out of that particular mess seems to be adding the option, so those few folk who need that "ability" can invoke it as needed. (And yours is the only complaint I've heard, FWIW.) This is an example of why interface bugs are particularly bad: leaving them alone is dangerous, but someone will have ended up relying on the broken interface. Hence the rule of thumb that they need to be fixed ASAP, to avoid prolonging the pain. The patch is easy; I'll likely send it around in the next day or two. > > - 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? > 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.) But ... I'm not sure I see how such configs could exist with the current downloaded algorithms and cores. Since ARM likes to keep TCK at something like a sixth or an eight of the CPU clock speed, and none of the algorithms in the current tree are doing many instructions between DCC reads. That means that if we're talking JTAG, and using DCC just to speed up a download, we're almost automatically OK. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
