3

I have a question for those familiar with the Xilinx Zynq and associated design tools....

  1. Is it possible to compile and run C code for the Zynq 7010 (Zybo dev board), WITHOUT using the Xilinx toolchain (Vivado/SDK)?
  2. Is it possible to assemble and run ARM assembly code (Thumb2) on the Zynq, WITHOUT using the Xilinx toolchain (Vivado/SDK)? By this I mean writing a program that does NOT use any of the Xilinx driver libraries or autogenerated init code (i.e. constructing your own simple vector table, giving definitions to the various exception handlers, etc.)
  3. If not, is it possible to at least assemble and link ARM assembly code from within SDK?

I'm helping to port an intro embedded systems course from the STM32F4 (ARM M3 dev board) to the Zynq, and the first few weeks are always an introduction to assembly. Usually we manually do everything from the command line using the arm-none-eabi toolchain, so I would be interested in maintaining that structure, rather than immediately jumping into the Xilinx Vivado/SDK environment. However, I have not been able to find any resources on programming the device without the Xilinx toolsuite, which I find odd. I can't imagine its impossible, so any information would be greatly appreciated.

Thanks!

asmvolatile
  • 522
  • 5
  • 22

3 Answers3

4

I have no direct experience with the ZyBo, however it happened to me to be in a similar situation various times and I learned how to gather information from the Internet (even, before the Internet) and fill the gaps with a bit of reverse engineering followed by trial and error.

I've collected what I believe are useful information but I never had a ZyBo, so take this with a grain of salt.
Also, take time to read the linked document if you don't understand some terminology.

It seems that you can avoid part of the Vivado SDK and the IDE, the Zynq 7000 Software Developer guide in Appendix A describes the use of bootgen and BIF files to generate a boot image.

In Zybo terminology, the boot image contains the BootROM header and the First Stage Bootloader (the stage 1 phase of the bootstrap process, it also contains user code).
Note that The BootROM itself is not writable, so you cannot alter the stage 0 unless you find a way to hack it (it is not a great idea though, the stage 0 do a minimal amount of work and make the board usable).

An example taken from that manual

// A simple BIF file example.
the_ROM_image:
 {
 [init]init_data.int
 [bootloader]myDesign.elf
 Partition1.bit
 Partition1.rbt
 Partition2.elf
}

And the manual explicitly says that ELF is a supported file format (at least I hope it is that ELF).

So you could use GCC to generate an ARM ELF and than bootgen to make a boot image (of course no C Runtime).
Binary files are supported too, so any ARM assembler will do.
This should avoid any SDK initialization code, leaving only the stage 0 being executed before your code.

The Zynq 7000 Technical Reference Manual describes the BootROM header format in detail.
It also explain the various hardware components and the architectural decisions made, including the boot process and the various bare metal options.
So you can even get rid of bootgen and make your own tool.

The BootROM header seems to have a field for defining the Interrupt Table when in XIP mode, however, as said, it is the BootROM the first code executed so you don't start from the ARM reset vector.

I'm not familiar with the SDK but I'm sure that if you snoop around the SDK bin folder you'll find a lot of the usual GNU tools for the ARM toolchain (pretty much like it happens for the Android NDK).
XILINX states, in one of its document (alas I don't remember which one) that they used the standard GNU tools with slight augmentations.

As for avoiding XILINX libraries you can try reading their source if available or disassembling their binaries.
With the help of the Technical reference manual you should be able to avoid them in the first place.

XILINX does a great job describing its board on the two documents linked (a shorter one is here), reading both will explain a lot of things going on under the hood.

Usually vendors reuse existing tools so, unless XILINX developed their own, you should find the command line tools used by the IDE familiar.
And you may even start liking the Vivado SDK after knowing how it works in depth!

Margaret Bloom
  • 41,768
  • 5
  • 78
  • 124
  • Thanks so much for the info. I've dug around both of those documents pretty extensively, and it does a great job explaining the architecture and the "what", but they don't have much information on "how" (most notably, the "how" to get the binary onto the darn thing) to do anything outside the SDK environment. – asmvolatile Jan 19 '17 at 22:59
  • could you please clarify what you mean by "no C runtime" in your statement: "So you could use GCC to generate an ARM ELF and than bootgen to make a boot image (of course no C Runtime)." – asmvolatile Jan 19 '17 at 23:04
  • @Brett the C runtime (e.g. `printf` et al) is tied to a specific architecture. Unless you have the C lib for the ZyBo, you cannot use them. – Margaret Bloom Jan 20 '17 at 06:58
  • ok I see what you mean, and I already know that. Not looking for that, just a way to get executable assembly instructions into program memory, and then initialize the PS to begin running it – asmvolatile Jan 22 '17 at 22:53
3

When I was looking for a way to develop software without using the Xilinx SDK, I found this repository. Author wrote the code in assembly to initialize SoC Zynq 7000, so that made it possible to run the compiled C code on it. However, the author still used the toolchain from the Xilinx SDK.

I created a new repository based on his development and got rid of the Xilinx SDK dependency in favor of arm-none-eabi-gcc and arm-none-eabi-newlib. OpenOCD is used for running software on this device. Here is a git repository with instructions on how to run example on Digilent Zybo Z7-10 without the Xilinx SDK: https://github.com/3ap/zybo-z7-baremetal

Sergey Nazaryev
  • 31
  • 1
2

In general yes, absolutely. But it depends primarily on available documentation for the part. There is no reason why you cant use say gnu or llvm tools to build the arm binaries, replacing the sdks required information about what you are talking to. If this is just a core wrapped by your logic, then you still need their tools to make the logic most likely and place it in the part (And you control what the address and peripherals are so you can write code to talk to your own logic, so you document for yourself), but the arm binary, in theory you can make with any tools, and hopefully their tools dont prevent you from using those binaries.

old_timer
  • 69,149
  • 8
  • 89
  • 168
  • Ok thats exactly what I suspected. Thankfully, I'm not even interested in any interaction with the FPGA logic right now, I just want to be able to assemble, link, and execute a simple assembly language binary on one of the CPUs. This would be a trivial task on say, a cortex-M3, but I'm struggling to get my mind around how to deal with the much more extensive bring-up required by the zynq. – asmvolatile Jan 19 '17 at 23:01
  • No doubt that Xilinx has "integrated" a collection of tools so that the output of their tool "seemlessly" integrates into the fpga image download or whatever. I have heard of but not researched the zynq platform, but thinking more no reason why you couldnt implement someting in the fpga that allows you to poke the program into ram then release reset on the arm. basically as you are understanding on some cortex-m based mcu that chip company has already built an interface or few to download programs into the flash – old_timer Jan 20 '17 at 00:02
  • no doubt xilinx has something here too but within their sandbox. so you have to see if you can figure out their sandbox and replace a component's output or build your own interface to the arm and use that. if lucky perhaps you have direct access to the SWD signals then you can use an stlink or whatever easy to come by openocd supported debugger. – old_timer Jan 20 '17 at 00:03