On Wednesday 10 February 2010, Øyvind Harboe wrote: > > I would like to commit this arm11 lockup: > > > > https://lists.berlios.de/pipermail/openocd-development/2010-February/014665.html
This patch addressees a different issue than the bug report you filed (which seems to me to be a clear case of flakey config scripts). This patch addresses a *secondary* failure, which can crop up in other cases ... even you first observed it with a bad config script, which permitted a bad JTAG clock setting during reset. The patch scans OK, except that "i" is a bad name. "loop_count" would be more clear. (And the description is weak, since the problem isn't coupled to reset or jtag clocks.) While you're thinking about it, you might consider a quick audit of at least the ARM11 code to catch any other such "spin forever" loops to fix... It's a general rule that *ALL* "spin until hardware reports success" loops need timeouts. Exceptions are rare, and mostly seem to revolve around "if the hardware is that broken there is no recovery possible". If the loop is in OpenOCD, then a recovery is almost certainly possible. > The arm11 target has only recently become robust enough to > recommend for mortals, "Oh, What Fools These Mortals Be!" ;) I wouldn't disagree ... but it's still kind of messy, as well as incomplete. Thumb support is weak, no semihosting, no soft breakpoints, and so forth. There's also quite a lot more scope for sharing code between ARM11 and Cortex-A cores. Debug entry/exit can be much more similar, for example. > so bugfixes weigh in more heavily than > regression concerns for this target, IMO. If you mean "potential regressions", that seems almost fair ... though we've not yet been deferring bugfixes on grounds of "potential" trouble. As for *actual* regressions ... I don't think there should be any kind of "ARM11 exception", to count regressions for those cores any less than for other cores. Our basic goal in successive releases is to *improve* things. Releasing with unfixed regressions is ungood. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
