Jump to content

Recommended Posts

Posted

Foreward: Not sure if this better fits in board bring up, but I can't post there, so feel free to move if appropriate.

 

I'm looking into the feasibility of using the Armbian build system to generate OS images for the Avnet MicroZed board. This board is based on the Xilinx Zynq 7000 platform, which is a SoC made up of a dual core 500 MHz CPU, and a Artix-7 generation FPGA. The CPU is nothing to write home about, but the FPGA opens up an interesting array of possibilities. Just in case you need an ARM board with 100+ GPIO, over two dozen serial ports, or your own function generator. Really, you're limited only by pin count, FPGA fabric usage, and what you can manage in Vivado. Xilinx also has an active presence on GitHub, and branches for kernels as new as 5.12, so sees active support.

 

The big rub, is that the Zynq CPU boots off a VFAT partition, that contains a file named "boot.bin". This boot file combines the first stage bootloader (FSBL) and u-boot, and needs to execute a C application to assemble this file. The application is recently open sourced, and previously existing open source software also exists. But I'm not sure how best to integrate that with the build system, or identify that the platform u-boot package depends on this extra package.

Posted
6 hours ago, tparys said:

Just in case you need an ARM board with 100+ GPIO


Would come handy sometimes. For the next version of our test gears perhaps.
 

https://www.armbian.com/olimex-lime-2-emmc/

160 :D
 

6 hours ago, tparys said:

The big rub, is that the Zynq CPU boots off a VFAT partition, that contains a file named "boot.bin". This boot file combines the first stage bootloader (FSBL) and u-boot, and needs to execute a C application to assemble this file. The application is recently open sourced, and previously existing open source software also exists. But I'm not sure how best to integrate that with the build system, or identify that the platform u-boot package depends on this extra package.


FAT is not a problem. https://github.com/armbian/build/blob/master/config/boards/odroidc1.csc#L7-L8 Build system can support weird boot processes - this way:

https://github.com/armbian/build/blob/master/config/sources/families/mvebu64.conf
https://github.com/armbian/build/blob/master/config/sources/families/include/meson64_common.inc

 

Posted

Alright, spent some more time digging at this, and have the build system generating viable boot images. Also moved my stuff to a microzed-cleanup branch to merge a bunch of smaller dumb commits.

 

I ended up settling on adding bootgen as one of the tools compiled by the build system by adding a extra function compile_xilinx_bootgen() in lib/compilation.sh, and a precompiled FSBL as a separate repo "xilinx-fsbl-blobs". Both get setup in do_default() in lib/main.sh.

 

The boot.bin file gets created by uboot_custom_postprocess() in config/sources/families/zynq.conf, and gets dropped directly in /boot by the debian installation. I've marked it as a "config file" for now as the FSBL does change with Vivado project design, and don't want to clobber a user FSBL with the prepackaged one. Users who don't touch that file get it updated automatically. Probably want a better solution, but this should work for now.

 

Cpufreq, GPIOs, Ethernet, LEDs, ZRAM all seem to be working.


USB regulator might be off. I've seen that in previous DTB versions.

 

PMOD connector hasn't been configured for anything, so that's dead/off for now.

Posted

https://drive.google.com/drive/folders/1YWMDbbx0p4dLPO3Mr3921vNay8l-_vHo?usp=sharing

 

This is a topic to discuss CSC Armbian support on the Avnet MicroZed board, and adding a similarly supported SoC family for the Xilinx Zynq. In terms of "interesting boards", the Zynq is a combination ARM/FPGA SoC that pairs a dual core Cortex A9 @ 667 MHz with a Artix-7 family FPGA fabric. In terms of performance, the A9's are nothing to write home about, but the FPGA fabric opens some rather interesting possibilities for those determined enough to use them.

 

For the unfamiliar, an FPGA (Field Programmable Gate Array) is a sort of reconfigurable logic. It allows one to have dynamic hardware components instead of static pieces selected by the board manufacturer. Want 100+ GPIO? Sure. A dozen serial ports? Alright. 37 I2C buses? You might need to share some interrupts, but I'm not aware of a specific reason that shouldn't work. Really, you're limited by pin count, FPGA fabric usage, and what you can express in Xilinx Vivado.

 

Be aware, if editing Device Trees puts you off, this is not the board for you. You will need to do substantially more to get anything significant working. If you do not have a copy of Vivado installed, you will not get far. Interested users should start with Xilinx/Avnet documentation or HERE.

 

Current development status:

  • MicroZed (7020) booting up, appears to be working fine
  • CPU Frequency Scaling (333 or 667 MHz )
  • FPGA bitstream loading (See below gotchas)
  • Onboard Gigabit Ethernet
  • USB (See below gotchas)
  • GPIO, including board heartbeat LED

Things that aren't working:

  • DTB Overlays (seems to freeze board when enabled in u-boot config)
  • PMOD connector (Didn't enable it in the Vivado, Design, FSBL, DTB, etc..)

Current gotchas:

  1. Zynq u-boot doesn't work like other boards. u-boot and the Zynq FSBL (First Stage Bootloader) get baked together into a file called "boot.bin" via a Xilinx program called "bootgen". This is not currently in the image, so are not able to modify this file on-board.
  2. The MicroZed 7010 and 7020 are different boards. The CPU is compatible, but the 7020 has a larger FPGA and access to more pins (eg - Bank 13 on the MicroZed schematics)
  3. One of the jobs of the FSBL is to configure the Zynq MIO (Multipurpose I/O). To a limited extent, this re-configures which CPU pins go where on the PMOD connector, sets pull-up or pull-down resistors, and does other things. I think it's possible to skip the FSBL entirely and go directly to u-boot, but am unsure how that's supposed to work in a general sense.
  4. The Avnet preset for the MicroZed board specifies the correct reset pin for the USB PHY, but Vivado is not currently using/respecting it. If you make a new design, and do not check that the USB0 reset is enabled on MIO7, and build your own FSBL, the onboard USB port will not be usable.

 

 

  • Igor pinned this topic
  • Igor unpinned this topic

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines