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 _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
