jtag access for zybo zynq board

[Chris Johns]

On 2/10/19 3:01 am, Kent Dorfman wrote:
> Yes.  am reading is OpenOCD document.  My specific use-case is
> Zybo-7020 using a USB/HS1 JTAG link and there are things in the
> document I'm not sure about:
> 
> 1) can I ignore anything related to the PL?

Yes and no, it depends. In terms of JTAG access yes you are only interested in
the taps to the ARM cores. The PL tools from Xilinx are needed to access the
SystemZ block which is used to create the ps7_init.[ch] files the FSBL needs.
Your board may have a suitable ps7_init.[ch] available you could use (see the
end of this email).

> I don't know how it's
> configured and really don't care as long as it doesn't interfere with
> the PS (normal computing capabilities)

The separation is not as clean as this. The FSBL contains a range of settings
needed to initialise the hardware and these effect the access from the PS to the
PL. In theory all you need the FSBL to do is initialise the clocks and memory if
the PL is not accessed however you run the risk of the generate PL bitfile view
of the system and your initialised hardware not being the same.

In terms of JTAG access the PS and PL are separate.

> 2) all these OS documents refer back to the xilinx SDK or Vivado as
> how to make a boot image that does (required) initialization/setup.
> I'm very much against using those tools because I take exception to
> their "eavesdropping" licensing terms.

The Xilinx tools are needed to create bitfiles for the PL so someone needs to
register and sign in.

> I need to know if there is
> necessary magic that is being supplied by those tools, or if bootgen
> is all I need.

There is the open tool ...

https://github.com/antmicro/zynq-mkbootimage

... that I use for clear or non-encrypted FSBL generation and while locating
this I see Xilinx uploaded the bootgen sources to github about a month ago ...

https://github.com/Xilinx/bootgen

This is significant because there is a bit being used in this code to handle
encrypted loading via the PCAP that is or was under NDA. The side effect of this
is a subtle change where the PCAP and AES logic based on the eFuse key can be
used to decrypt files. Up to now you had to encrypt these files using a
complicated bootgen sequence.

> 3) the document seems centered around the flyswatter jtag, which I
> don't have, so I'm not sure what's relevant or what needs changed to
> work with the usb/jtag-hs1

The flyswatter pod is documented because that is all I have :). In theory it
should only be a matter of referencing your pod. I suggest a recent openocd and
even git master to make sure you pick any recent ARM specific fixes.

> built a simple rtems app to flash the LED-4 @ MIO/GPIO-7, based on
> realview-pbx-a9 bsp and no build errors, but I'm not sure if the
> bootgen output would execute or if there is more complicated board
> setup required before loading a simple GPIO LED app:
> 
> bootgen -w on -arch zynq -image blink.bif -o BOOT.BIN
> 
> and blink.bif containing:
> image:
> {
> [bootloader] blink-app.elf
> }

You could have the FSBL load a second stage loader (SSBL) such as u-boot and
from there you load RTEMS. This has the benefit of being able to load from flash
or load across network.

U-boot contains its own FSBL and a host tool for creating the image so that may
be even simpler. I see in Xilinx's u-boot repo ...

https://github.com/Xilinx/u-boot-xlnx/tree/master/board/xilinx/zynq

.... a zync-zybo so this may be a better path for you to follow. Note the
various board directories hold the ps7_init file generated for that specific
hardware. This means u-boot and the Xilinx SDK boot.bin are consistent in how
the hardware is set up.

Chris