Testing PL GPIO Access on the Ultra96-V2 and Findings
Background
Before this experiment, we conducted a series of tests using the preloaded BSP SD card on the Ultra96-V2 to evaluate how well it supported direct GPIO control through Linux.
-
Testing PS GPIOs (MIO)
- We controlled an LED placed on pin 23 of the J5 LS header, which is mapped to MIO36 of the Processing System (PS).
- Using the Linux sysfs interface, we successfully turned the LED on and off using terminal commands.
-
Controlling the LED via a Web Interface
- We confirmed that the BSP SD card included all necessary Python3 libraries, such as Flask, mraa, and others.
- Using Flask, we built a simple web application that allowed LED control via a browser.
-
Extending the Experiment to PL GPIOs
- The logical next step was to test whether a similar approach could be used for PL GPIOs (Programmable Logic GPIOs).
- Specifically, we wanted to control an LED placed on pin 3 of the J5 LS header, which corresponds to HD_GPIO_0 in Bank 26 of the PL.
- The goal was to see if the preloaded BSP SD card already contained support for PL GPIOs or if modifications were needed.
Tests Performed
-
Checking Available GPIOs in Linux
- We listed the available GPIO chips using
ls /sys/class/gpio/
and identified severalgpiochip
entries. gpiochip331
contained 174 GPIOs, which aligned with the PS MIO pins.gpiochip510
was also detected but contained only 2 GPIOs, which did not match the expected number of Bank 26 GPIOs.
- We listed the available GPIO chips using
-
Verifying PL GPIO Mapping
We checked the device tree for AXI GPIO assignments using: grep -r "axi_gpio" /proc/device-tree/ This returned nothing, indicating that no AXI GPIOs were defined in the device tree.
We searched for references to Bank 26 GPIOs using: grep -r "bank26" /proc/device-tree/ and grep -r "hd_gpio" /proc/device-tree/ These also returned no results, confirming that the current system configuration does not expose PL GPIOs.
-
Testing GPIO Control with Existing Mapped GPIOs
- We attempted to export and toggle gpio510 and gpio511, but they did not control the LED.
- We repeated the process with gpio367, mapped to MIO37, but this was also unrelated to the PL.
-
Reviewing ZynqMP Architecture and Understanding Why PL GPIOs Were Missing
- According to Xilinx documentation, MIO GPIOs are part of the PS and are mapped under
zynqmp_gpio
(which we confirmed viagpiochip331
). - PL GPIOs, however, require an AXI GPIO block to be instantiated in Vivado and connected to the PS through EMIO (Extended Multiplexed I/O).
- Since no AXI GPIO nodes appeared in the device tree, the default bitstream does not include the necessary AXI GPIO mapping.
- According to Xilinx documentation, MIO GPIOs are part of the PS and are mapped under
Findings and Why They Matter:
- The preloaded BSP SD card fully supports PS GPIOs (MIO), but it does not expose PL GPIOs (HD_GPIO_x, Bank 26).
- The absence of AXI GPIO entries in the device tree confirms that no AXI GPIO block exists in the current bitstream.
- The BSP image does include Python3 libraries and frameworks (such as Flask and mraa), meaning that once PL GPIOs are available, they can be controlled the same way as MIO GPIOs.
- Without an AXI GPIO block in the Vivado design, the PL GPIOs cannot be accessed through Linux.
Discussion: Did We Miss Anything? Validating Our Approach for PL GPIO Access just unpacking our Ultra96-V2 withouth a new .bit file
Based on our testing and findings, it appears that the current bitstream does not provide access to PL GPIOs. The lack of AXI GPIO entries in the device tree and the inability to export PL GPIOs via /sys/class/gpio/
strongly suggest that the PL GPIOs were not mapped in Vivado.
Our next logical step is to modify the Vivado design by adding an AXI GPIO block that maps Bank 26 GPIOs (HD_GPIO_x) to the PS via EMIO. Once this updated bitstream is generated, we plan to:
- Load it dynamically onto the Ultra96 using
fpgautil
, ensuring only the PL is reprogrammed while keeping the PS unchanged. - Check if a new
gpiochip
(e.g., gpiochip512) appears in/sys/class/gpio/
, indicating that Linux has recognized the new AXI GPIO block. - Export and control the new GPIOs via standard Linux commands to confirm that PL GPIO access is now working.
Once this process is validated, we should be able to apply the same Linux command-line, shell script, and web-based control methods that were successfully used for MIO GPIOs.
Open Questions for the Community
- Does our approach seem correct, or is there a more efficient way to enable PL GPIO access in Linux?
- Is adding an AXI GPIO block in Vivado the best approach, or should we be considering another method, such as modifying the existing device tree to expose EMIO GPIOs directly?
- When using
fpgautil
to load the.bit
file dynamically, are there any risks of conflicts with the preloaded BSP configuration? - Has anyone successfully controlled PL GPIOs on Ultra96-V2 without modifying the default bitstream? If so, how was it achieved?