On Dec 10, 2008, at 11:07 AM, Øyvind Harboe wrote:
My only problem with this approach is that the assumption that there is a single expected ID is broken. I want it to be both straightforward to handle the normal case and possible to handle more complex cases(multiple expected ID's).-- Øyvind Harboehttp://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer
I'm proposing allowing multiple -expected-id options for a given tap. Internally, we would build a list of the provided expected IDs. Then, when we read the ID from the tap, we compare it against the IDs in the list. If we hit any of those, we fire the "match" event and provide the matched ID to the script. If the tap's ID doesn't match any ID in the list, we fire the "nomatch" event and provide the tap's ID to the script. If there is no "nomatch" script, we return an error.
The normal case would be to provide one -expected-id option and no event scripts.
The more complex case is a device with multiple -expected-id options, but no scripts. This would be for devices that have different IDs but have no practical difference for OpenOCD.
The really complex case is a device with multiple -expected-id options that have scripts to do operations dependent on the reported ID.
This keeps the normal case very simple and handled automatically while allowing the complex cases in a natural way.
-- Rick Altherr [EMAIL PROTECTED]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
