[Openocd-development] Incorrect chain detection for SoC...

[Georg A. <ac...@in...>]

Hi,
I'm currently working on a settop-box chip from Conexant. It contains two
ARMs, a 1176 and a 926. The 1176 is the one I'm targeting for flashing over
JTAG (no debugging or other fancy stuff).

Unfortunately, openocd has huge problems even in detecting in the JTAG
chain. Already all of the Ids are wrong...

According to the documentation, there are 5 devices in the chain: One
test/access controller, some security stuff, then the 1176, then the ETB to
the 1176 and finally the 926.

This is how it looks with the Lauterbach JTAG-tool (that I don't have):

0: IR Length 4 Device No 0x0000 Version No 0 Manufacturer - Man No 0x000
1: IR Length 4 Device No 0x48A0 Version No 2 Manufacturer Intl CMOS Technology Man No 0x027
2: IR Length 5 Device No 0x7B76 Version No 1 Manufacturer Conexant (Rockwell) Man No 0x013
3: IR Length 4 Device No 0xB900 Version No 2 Manufacturer (Generic ARM) Man No 0x787
4: IR Length 4 Device No 0x0926 Version No 2 Manufacturer Conexant (Rockwell) Man No 0x013

The Lauterbach setup for accessing the 1176 IR is 8 pre bits and 8 post
bits, for the ETB it's 4 pre and 13 post. The DR setup for the 1176 is 2
bits pre and 2 post, the ETB-DR is 1 pre and 3 post. Sounds reasonable...

And now the result of the openocd scan (HW is parport wiggler, svn checkout
a few hours ago):

0x90493013 (Manufacturer: 0x009, Part: 0x0493, Version: 0x9)
0x95c80787 (Manufacturer: 0x3c3, Part: 0x5c80, Version: 0x9)
0x0bdbb013 (Manufacturer: 0x009, Part: 0xbdbb, Version: 0x0)
0x12450027 (Manufacturer: 0x013, Part: 0x2450, Version: 0x1)

And then it detects 224 other devices without IDCODE... 

A cross check with the Xilinx-impact-tool and its USB-JTAG adapter also
showed the message "too many devices" and then a crash occured ;-) Looks
like the large number of devices is no HW/level/cable problem.

The part IDs seem to be one bit shifted (2450*2=48a0, bdbb*2=17b76, ...). So
the openocd-list is in reversed order.

But the first device is missing, after the 0x12450027 the IDCODE is really
0. I've hacked the detection to allow one 0-IDCODE as the last device, but
chain validation and the arm11-target failed to initalize with the following
settings:

jtag_device 4 1 0xf 0xe
jtag_device 4 1 0xf 0xe
jtag_device 5 1 0x1f 0xe
jtag_device 4 1 0xf 0xe
jtag_device 4 1 0xf 0xe

The result of the arm11-target detection (SCANR is 8 instead of 0x10) also
indicates the shifted bit like in the IDCODE. Looks like there is one
additional bit shifted out that noone expects...

Are there any hints what I can do? I'm accepting all ugly hacks ;-)

-- 
         Georg Acher, ac...@in...         
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias