MicroZed Chronicles: Software Repositories & Modifying Drivers

Our MicroBlaze, Zynq and Zynq MPSoC solutions are increasingly software defined.

Adam Taylor
5 years ago

Our MicroBlaze, Zynq and Zynq MPSoC solutions are increasingly software defined.

We use the application software running in the processor system (PS) to implement algorithms, manage data transfer within the device, implement communication links, and configure IP in the programmable logic dynamically.

This raises several challenges, as during development we need to:

  • Create custom software drivers and reuse them across projects (Xilinx SDK workspaces)
  • Create custom board support packages (BSP) and board definitions
  • Create new software libraries to be used across projects
  • Modify existing Xilinx drivers and libraries for the application

SDK repositories allow us to do all of the above, if we use them correctly.

We open the repository dialog by selecting:

Xilinx -> Repositories

Within this dialog, there are three repositories, the installation repository, and global and local repositories.

While we cannot modify the installation repository, we can add new local and global repositories. However, before we add any new repositories, we should first understand the scope of these two repositories:

  • Local repositories are only available within the current SDK workspace
  • Global repositories are available across SDK workspaces

For example, we may use a local repository for changes we make to a Xilinx library or driver. Changes to it maybe important for the applications in the workspace for a particular solution, although we would not wish to apply the changes to every development.

If, however, we have custom drivers created for proprietary intellectual property (IP) or custom libraries we may wish to use these across several applications and hence workspaces. As such a global repository should be used, in fact the image above demonstrates this as it includes the location the Arm DesignStart Libraries on my system.

To work correctly, repositories are prioritized. This enables higher priority repositories to override identical components at a lower priority. In order of priority, the repositories are:

  • Local repository — highest priority
  • Global repository — medium priority
  • Installation repository — lowest priority

Let’s take a look a how we can use repositories if we need to make a change to a Xilinx driver provided with the BSP.

When we create a board support package for our Zynq / Zynq MPSoC design, one of the first things we do after we have imported the hardware definition is to create a board support package (BSP). This BSP contains a number of drivers which support the configuration of the hardware.

If we wish to examine the source code, we can look under the BSP libsrc directory. Under this directory we will see the source code for each of the drivers included in the BSP.

However if we make changes to these source files, for example to adjust a driver they are not included in the next build. Any changes are lost, this is because SDK is working with the compiled library Xillib.a which is created when the BSP is created or regenerated.

The correct way to create a modified driver is to use a copy of the driver in a repository.

To use a repository, the first thing we must do is create it and organize it correctly.

A correctly formatted repository contains the following folders:

  • BSP — used to hold software platforms and BSPs
  • sw_apps — used to hold applications
  • sw_services — used to hold libraries
  • drivers — used to hold drivers

To create a modification to a driver or library, we need to copy the original component from the Xilinx library into the correct repository directory (SW_Services or drivers). If you are wondering where to find the original driver on your system, the installation repository gives you the path.

For this example, I will only create a modified AXI IIC controller, by copying the AXI controller under my new repository driver folder.

Under the data directory, you will find the MDD file which contains the information on the driver. I opened this file using a text editor and changed the name from IIC to IIC_MOD — that way we will know our changes take effect.

We are also free at this point to modify the source and header files as is necessary for the driver.

Once we are finished with our modification, we can then recreate the BSP source or create a new BSP, and the new modified driver will be available for use.

You can confirm this by looking at the drivers in the BSP settings.

Modifying the drivers and libraries in this manner means that we still have the original source for other projects which do not require the change.

It is pretty rare that you need to make modifications, but occasionally there is a need to do so if you have device with unique properties or behaviors.

Now we know the best way to do this!

See My FPGA / SoC Projects: Adam Taylor on Hackster.io

Get the Code: ATaylorCEngFIET (Adam Taylor)

Access the MicroZed Chronicles Archives with over 270 articles on the Zynq / Zynq MpSoC updated weekly at MicroZed Chronicles.

Adam Taylor
Adam Taylor is an expert in design and development of embedded systems and FPGA’s for several end applications (Space, Defense, Automotive)
Latest articles
Sponsored articles
Related articles
Latest articles
Read more
Related articles