jtag access for zybo zynq board
chrisj at rtems.org
Thu Oct 3 01:29:05 UTC 2019
On 3/10/19 9:21 am, Kent Dorfman wrote:
>>> 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 ...
>> ... that I use for clear or non-encrypted FSBL generation and while
>> this I see Xilinx uploaded the bootgen sources to github about a month ago
>> This is significant because there is a bit being used in this code to
>> encrypted loading via the PCAP that is or was under NDA. The side effect of
>> is a subtle change where the PCAP and AES logic based on the eFuse key can
>> used to decrypt files. Up to now you had to encrypt these files using a
>> complicated bootgen sequence.
> My whole point of contention in this process is the seeming or
> implicit requirement to use xilinx tools
I do not use Xilinx built tools unless I need a secure boot and it looks like
that has changed. I use FreeBSD and MacOS and Xilinx does not provide tools for
> and I'm not seeing ANYWHERE
> that provides needed fsbl.elf other than generated through the use of
> those xilinx tools.
A u-boot build creates a boot.bin (the FSBL) without any Xilinix tools. Look for
spl/boot.bin in the build tree. If you place that file and the u-boot executable
in the root directory of a MRB formatted SD card it will boot u-boot and from
there you can boot RTEMS.
Note, the RTEMS Boot Image tool can create Zynq SD card images for you ...
> I've got bootgen and have built the arm version of u-boot, but it's
> apparently not going to be loadable unless I understand how/where to
> get fsbl.elf to "bootstrap" the process.
Try the u-boot spl/boot.bin.
> Is this elf file the (insert
> bad word here) that forces you to use xilinx tools and accept their
> intrusive licensing terms?
No you do not have to, the Xilinx built tools is just one option available.
I am wondering why you are using a Zynq because the major feature of the device
is the integrated PL and you have to use the Xilinx FPGA tools to make use of
it. I get the need and want for the software tools to be separate and not to
depend on vendor tools, I also support this view. I prefer this because it
breaks the dependency between the hardware tools and the PL development life
cycle and the software's life cycle. Each team can control and manage their own
More information about the users