If the hard coded mask of 0x3 and value of 0x1 are changed to
ir_capture_mask and ir_capture_value respectively then mx25,31,35
should work. Here is an untested patch. The diagnostic is wrong
since it still has the hardcoded 0x..1 expected value in it. Sorry I
intended to send a tested patch yesterday but my day job is getting in
the way:)
diff --git a/src/jtag/core.c b/src/jtag/core.c
index 854236f..319cee9 100644
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -1113,7 +1113,7 @@ static int jtag_validate_ircapture(void)
* ircapture/irmask attributes.
*/
val = buf_get_u32(ir_test, chain_pos, tap->ir_length);
- if ((val & 0x3) != 1) {
+ if ((val & tap->ir_capture_mask) != tap->ir_capture_value) {
LOG_ERROR("%s: IR capture error; saw 0x%0*x not 0x..1",
jtag_tap_name(tap),
(tap->ir_length + 7) / tap->ir_length,
On Wed, Oct 7, 2009 at 1:56 PM, David Brownell <davi...@pacbell.net> wrote:
> On Wednesday 07 October 2009, Øyvind Harboe wrote:
>> > Thing is, TAPs without IDCODE support have no exemption
>> > from the constraint that the two LSBs be b01, and most of
>> > them conform. Plus, this is the only place which ignores
>> > those mask values when checking ircapture results.
>>
>> Staying tuned for a solution that will work w/imx35 then...
>
> Current SVN uses the IR attributes provided at TAP creation
> time. Since imx35 sets those attributes to zero for the
> offending TAP, it should behave fine now.
>
> - Dave
>
> _______________________________________________
> Openocd-development mailing list
> Openocd-development@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/openocd-development
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
