Using OpenOCD with Ultra96

Hi Chuck,

I know that Avnet has not used OpenOCD with Ultra96, and I have not heard of anyone else using it either. I don't think this is specific to just the Ultra96 either. I'm not sure OpenOCD is used commonly with any Xilinx board given some of the posts I see online:

https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/set-up-device-with-OpenOCD/td-p/974675

https://forum.sparkfun.com/viewtopic.php?t=45482

However, I do see some limited success as well:

https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/OpenOCD-QSPI-flash-programming-versus-Vivado-special-sauce/td-p/10759…

https://tomverbeure.github.io/2019/09/15/Loading-a-Spartan-6-bitstream-with-openocd.html

Avnet does not post the schematics for the USB-to-JTAG/UART Pod publicly due to proprietary information. However, if there is a specific pin that you want me to look up, then I can reply.

Bryan

Programming FPGAs and even Zynqs with OpenOCD is nothing new. The issue at hand is getting the proprietary Ultra96 JTAG pod under control of the lower-level OpenOCD layers.

Several things are required for this:

* Set FTDI GPIO pins to enable level translators for JTAG, UART, and SRST

* Set FTDI GPIO levels to leave POR untouched, though control of POR with some tool would be nice: Zynq 7000 devices are prone to unrecoverable JTAG lockups in the PS part, and those bugs could be also present in US+. POR is probably usable to work around them.

* Tell OpenOCD how to control SRST (a questionable design decision by ARM is to disable the JTAG interface until a SRST edge is received; on Zynq this means only the PL is visible until the SRST edge)

What FTDI pins are connected to what? What are the recommended FTDI GPIO register settings?

I tried playing with the GPIO register values, and could get the PL to be detected by OpenOCD (driving all FTDI GPIOs low enables level translators and drives POR low - in this state the US+ chip has the PL only accessible on JTAG) and apparently control SRST and POR by setting some bits in the data register. But the PS never shows up for some reason. It would be good to check that I am not doing something wrong with the GPIOs...

What's up with the proprietary information? It's a FT2232H, voltage regulator, and some combination of SN74LVC1T45 / SN74AVC2T245 translators - no rocket science there. I generally find JTAG solutions on the market to be extremely frustrating (buggy/unstable/temperamental, lacking features, not interoperable, etc.), and withholding such technical information makes it even worse. Do I really need to take the JTAG pod to my dentist for an X-Ray?

For an example of specifications that would be useful but hopefully without revealing "proprietary information", see e.g. the specs from Olimex:

https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/

Connected LED Inversion Mask 0x0000

Connected LED Mask = 0x0800

nSRST Inversion Mask = 0x0200

nSRST Mask = 0x0200

nTRST Inversion Mask = 0x0000

nTRST Mask = 0x0100

Output Pins = 0x0F1B

Output Value = 0x0D08

Running LED Inversion Mask = 0x0000

Running LED Mask = 0x0800

Hi Sebastien,

The programming of the FTDI chip on the Ultra96 JTAG/UART adapter is proprietary to Xilinx.  Avnet cannot share this information publicly.  You may want to contact Xilinx directly on their forums:

https://forums.xilinx.com/

--Tom

Hi Sebastien,

The programming of the FTDI chip on the Ultra96 JTAG/UART adapter is proprietary to Xilinx.  Avnet cannot share this information publicly.  You may want to contact Xilinx directly on their forums:

https://forums.xilinx.com/

--Tom

Be aware that you may get pointed to this AR: https://www.xilinx.com/support/answers/68889.html

"the proprietary solution is not documented or supported, and cannot be provided to customers as a reference."

This works and, according to my USB analyzer, corresponds to what the Vivado bloatware does:

```

interface ftdi

ftdi_vid_pid 0x0403 0x6010

ftdi_layout_init 0x3dc8 0x02eb

ftdi_layout_signal nSRST -data 0x0080

reset_config srst_only srst_push_pull

adapter_nsrst_assert_width 250

adapter_nsrst_delay 400

```

Next time just don't bother me with your "proprietary programming" BS.

Open On-Chip Debugger 0.10.0

Licensed under GNU GPL v2

For bug reports, read

    http://openocd.org/doc/doxygen/bugs.html

adapter speed: 1000 kHz

Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.

Zynq CPU1.

srst_only separate srst_gates_jtag srst_push_pull connect_deassert_srst

adapter_nsrst_assert_width: 250

adapter_nsrst_delay: 400

Info : clock speed 1000 kHz

Info : JTAG tap: zynq.tap tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x5)

Info : JTAG tap: zynq.dap tap/device found: 0x14710093 (mfg: 0x049 (Xilinx), part: 0x4710, ver: 0x1)

There is still one little problem though: this only works after Vivado has accessed the board at least once. Are you going to tell me what the solution is, or do you want to continue wasting my time with USB dump dissection? It's amazing how some hardware companies make their products deliberately customer-hostile like this.

This ? https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/JTAG-Chain-Configuration-for-Zynq-UltraScale-MPSoC/td-p/758924 , Upstream openocd has some support for zynq mpsoc.

Thanks, Paul. Hopefully this is helpful to Sebastien.

Saying "proprietary" earlier didn't portray an accurate meaning. I should have said "Xilinx Proprietary" and we are Avnet. Of course our intent is to be customer-friendly. However, there are legal agreements to which we must abide. Xilinx designed the FTDI circuit, wrote the firmware, and developed the software in their tools that interact with it. We have a license to use it, but we are not licensed to share the details. Even if Avnet had the information that you seek, we are not legally allowed to share it. I suggest you read https://www.xilinx.com/support/answers/68889.html, which references this identical circuit used on other Xilinx reference boards, and then use the Xilinx forum to request this same information -- https://forums.xilinx.com/ .

Bryan

bhfletcher Are there any non "Xilinx Proprietery Vivado compatible" jtag solutions supported by avnet , I want to use openocd less for the PL but to get through the ARM PS for which openocd is a common and effectively standard tool in the open source community,

Avnet has not developed any original JTAG solutions that we could share. Besides Xilinx, the other primary provider of JTAG circuits for Xilinx is Digilent. I have not seen Digilent offer their solutions as open source. However, I have not directly asked them myself. It would be well worth asking Digilent. For our boards that don't have an on-board JTAG circuit, we use the Digilent HS2 or HS3.

https://store.digilentinc.com/jtag-programmers-fpga-programming-solutions/

https://forum.digilentinc.com/

Avnet did work with Arm several years ago to create a small adapter that allowed their DSTREAM to work with ZedBoard. This worked well for the Arm cores in the PS, but we found that the integration between the Arm debug tools and the Xilinx PL lacked the necessary awareness to work well. I expect you may run into the same thing with OpenOCD, but it sounds like you are OK with only having PS control. Here's that adapter and an old training for reference in case there is anything of value to you here.

ZedBoard Processor Debug Adapter | Zedboard

Debugging ARM Processor Systems | Zedboard

Bryan

Paul: Thanks, this JTAG_CTRL register looks like a good suspect.

Bryan: There is no firmware in the Ultra96 JTAG pod; like I said, it's just a FT2232H and some simple support circuitry such as level translators. The EEPROM is only there so that Vivado recognizes the adapter and is not strictly necessary for operation.

OpenOCD itself works correctly for both PL and PS, though of course debug tools such as GDB are far from ideal, but that's another story. We've been using it on a medium-complexity Zynq-7000 project (https://git.m-labs.hk/m-labs/artiq-zynq  / https://git.m-labs.hk/m-labs/zynq-rs), but eventually we programmed our bootloader to download the bitstream from the LAN since it is rather large and the transfer rate from Ethernet is higher than from JTAG.

Note that we ended up using an Olimex adapter on the ZC706 because the builtin JTAG is another "proprietary" piece of junk, but that's harder to do on the Ultra96 due to 1.8V logic levels which many adapters don't support and the non-standard connector.

Just wondering if you got this working.  I'm trying using your configuration and the target/xilinx_zynqmp.cfg configuration in openocd v0.11rc2.

```

adapter driver ftdi

ftdi_vid_pid 0x0403 0x6010

ftdi_layout_init 0x3dc8 0x02eb

ftdi_layout_signal nSRST -data 0x0080

reset_config srst_only srst_push_pull

adapter srst pulse_width 250

adapter srst delay 400

adapter speed 1000

set PS_TAPID 0x14710093

source [find target/xilinx_zynqmp.cfg]

init

reset halt

```

And I'm running into issues trying to perform a reset:

```

Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.

Info : clock speed 1000 kHz

Info : JTAG tap: uscale.tap tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x5)

Info : JTAG tap: uscale.ps tap/device found: 0x14710093 (mfg: 0x049 (Xilinx), part: 0x4710, ver: 0x1)

Info : JTAG tap: uscale.tap tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x5)

Info : JTAG tap: uscale.ps tap/device found: 0x14710093 (mfg: 0x049 (Xilinx), part: 0x4710, ver: 0x1)

Error: JTAG-DP STICKY ERROR

Warn : target uscale.a53.0 examination failed

Info : starting gdb server for uscale.a53.0 on 3333

Info : Listening on port 3333 for gdb connections

Info : TAP uscale.tap does not have valid IDCODE (idcode=0x28e20126)

Info : JTAG tap: uscale.ps tap/device found: 0x14710093 (mfg: 0x049 (Xilinx), part: 0x4710, ver: 0x1)

Error: Invalid ACK (0) in DAP response

Error: Invalid ACK (0) in DAP response

Error: Invalid ACK (0) in DAP response

Error: Invalid ACK (0) in DAP response

```