On Sunday 25 October 2009, Øyvind Harboe wrote: > > Comments, objections? I'm inclined to just merge it (with > > some docs to come). It turns fault paths into quasi-success > > paths, with diagnostics about how to get *real* success. > > Neat :-) Merge it.
Done. I thought it was a useful _little_ hack too. > Some ramblings about automatic target config support: > > I'm thinking that we could create a tcl/target/auto.cfg where > we add normal Tcl code to automatically pull in the right target. There are at least two points where it'd be good to pull in TAP-specific intelligence. In the first case the input, as I imagine, would be a TAP name and -- ideally via a new "jtag cget tap.name -idcode" type command -- its IDCODE. For now let's assume we end up calling a procedure called "autoconfig_$IDCODE", if it exists, and its first duty is setting up the IR details. One question is when to call that ... I'm assuming it'd be best done after all the TAPs get instantiated, but before the IR settings will matter. So it would need to be able to do more or lesss "jtag configure tap.name -irlen ..." (new capability). Another question is what else that procedure could do, beyond configuring IR settings. The scan chain isn't really usable yet. It *might* well be OK to declare targets at that point ... a useful simplification, if that's possible. > Those targets that are missing from auto.cfg would not be > automatically detected. The weird "if xxx _CPUTAPID" stuff > could then be taken out of the target config scripts and put into > the auto.cfg file, possibly cleaning up the code a bit. There'd potentially be a LOT of those autoconf_$IDCODE things. So it might be important to segment them by vendor ID... that auto.cfg file looks at the ID and sources "auto/arm.cfg" or whatever. But, I'm not sure I could see them replacing the static configs. Thing is, IDCODE values aren't especially unique between vendors, at least for microcontrollers, and there are a lot of important things they can't expose. If we *do* add a second stage autoconfig call, after the scan chain is usable, it might be able to poke at various chip registers to get more details. I suspect the microcontrollers will expose a lot of that. > auto.cfg could grow some heuristics on how to even > autodetect targets like the beagleboard... The TI chips are easy. The ICEpick has a product-specific JTAG id. Given that, we know what other TAPs exist. BUT ... that wouldn't detect "Beagle", it'd detect just "OMAP 3530" or similar. No clue about what kind of memory or how much, its boot config, and so on. > Perhaps we > could even get the entire LPC family detected and configured > automatically... That's closer to achievable, except for things like clock setup that are extremely board-specific ... - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
