embeddedsw: Xilinx standalone software for BSPs, drivers and firmware

What the tree actually contains

The embeddedsw repository is described as the repo for standalone software, and the README splits it into a small number of top-level directories with distinct jobs.

`lib` contains the bsp, software apps and software services. `XilinxProcessorIPLib/drivers` contains all the drivers, with named entries such as avbuf and zdma visible in the listing. `ThirdParty` holds software from third parties like a light weight IP stack. `mcap/linux` is the software for using the MCAP interface on Ultra Scale boards to program a second level bitstream. `doc/ChangeLog` holds change log information for releases, and `license.txt` contains information about the various licences and copyrights.

The convention inside is the part that makes a tree this large navigable. Every driver, sw_apps and sw_services has one or more of four sub-directories, and they are the same four everywhere. `data` holds the tcl, mdd, testapp tcl or header files used in Vitis. `doc` holds the documentation of the source code in pdf or html form. `examples` illustrates different use cases for the driver. `src` is the driver interface code implementing the functionality of the IP.

So when you are looking for the implementation of a driver, `src` is the answer, and when you are looking for how to use it, `examples` is. That uniformity is what saves time in a tree of this size.

BSP, software services and the third-party stack

Under `lib`, the three groups are the board support packages, the software applications and the software services, and the README includes the note that all the software services are libraries and utilize drivers.

The standalone BSP directory is organised by architecture. It has an `arm` branch containing `common`, `ARMv8`, `cortexa9` and `cortexr5`, plus a `microblaze` branch, a `common` directory at the top level and a `profile` directory. In other words, the low-level startup and hardware abstraction code is split by processor family, which is the arrangement you would expect and the one that lets a single tree serve Zynq, ZynqMP, Versal and MicroBlaze.

The software services listed are xilffs, xilflash, xilfpga, xilisf, xilmfs, xilpm, xilrsa, xilsecure and xilskey. Reading the prefixes tells you what they are: a file system, a flash driver, FPGA configuration, an in-system programming interface, a memory file system, power management, and the security and signing primitives. They all sit on top of the drivers rather than talking to hardware directly.

The third-party tree is the interesting part for anyone doing anything beyond a single board. It contains a `bsp` with `freertos10_xilinx` and its own data, examples and src, and a `sw_services` directory holding libmetal, lwip141, lwip202 and openamp. Two generations of the lwIP TCP/IP stack are carried side by side, which is what you would expect when supporting products that span several years. libmetal and openamp sit alongside the two lwIP stacks in that third-party services list.

The FreeRTOS BSP inside ThirdParty carries its own `License` and `Source` subdirectories, which is the first sign that the licensing here is per component rather than uniform.

Building the firmware images from the tree

There is no package to install here. The firmware images are built from the source in the tree, and the README routes you to per-application instructions rather than giving one generic procedure.

The pattern is consistent across all four boot images. FSBL, the First Stage Boot Loader, has three directories: `data` with the files for Vitis, `src` with the FSBL source files, and `misc` with miscellaneous files required to compile FSBL. The README says to refer to the steps in the Readme.txt in the relevant `misc` directory, and it names the specific boards supported for each family. For Zynq, the builds supported are zc702, zc706 and zed, and for ZynqMP they are the zcu102 and zcu102-es2 boards. The zynq variant also contains the `ps7_init_gpl.[c/h]` files with the GPL header in the respective board directories.

The other three follow the same shape. PMUFW, the platform management firmware, is built following the steps in the Readme.txt in `lib/sw_apps/zynqmp_pmufw/misc/`. The Versal PLM, platform loader and manager, is built from the instructions in `lib/sw_apps/versal_plm/misc/`. The Versal PSMFW is built from `lib/sw_apps/versal_psmfw/misc/`.

The reason for the per-board split is not tidiness. A bootloader is tightly bound to the PS configuration of a specific board, and the initialisation sequence for a zcu102 is not the initialisation sequence for a zed. So the build instructions are per board because the artefacts genuinely differ, and the Readme.txt file in each misc directory is the authoritative source for that particular image.

The `scripts/` directory at the repository root and the `cmake/` directory next to it are the shared build machinery that the per-application instructions call into.

Licensing that changes from directory to directory

The licence situation is the most consequential thing to understand about this repository before you ship anything built from it.

The repository-level licence is recorded as a custom one that GitHub cannot classify, which points you at the LICENSE file, and the README's own directory listing shows a `LICENSES/` directory at the root alongside a `license.txt` that contains information about the various licences and copyrights.

That phrasing is the whole point. There is no single licence for embeddedsw. Different sub-components carry different terms, and the tree is arranged so that each one is visible. The `LICENSES/` directory is a per-component licence record, and the GPL headers in the files themselves, such as the `ps7_init_gpl.[c/h]` pair in the zynq FSBL board directories, are there because those specific files are GPL while their neighbours are not.

The practical consequence is that you cannot treat embeddedsw as a single-licence dependency. If you are building a boot image for a board that ships, the GPL files in that image carry GPL obligations, and the mix of licences means the obligations differ per file. The correct move is to read `license.txt` and the `LICENSES/` entries for the specific components you are including, rather than assuming the umbrella answer.

There is also a `ThirdParty` tree with its own licence handling, since libmetal, lwIP and OpenAMP each come with their own upstream terms and the FreeRTOS BSP even carries a dedicated `License` directory. If your product is closed source, this is where the work is.

What kind of project this is

The repository metadata gives some useful signals about the shape of the thing. The primary language is recorded as HTML rather than C, which reflects that the documentation volume in `doc/` is as large as the code, and the licence is the custom one already discussed. The default branch is master, there are no GitHub releases, and the last push was on 2026-09-09 with the repository not archived.

The absence of releases is a design choice rather than an omission, and it follows from the structure. This is a source tree that Vitis consumes, not a library you version-pin. The `data/` directories hold the tcl and mdd files that the Vitis tooling reads, and the `src` directories hold the code that the same tooling compiles. A release would have to be a coordinated snapshot of many independent components, and the tooling is the versioning mechanism instead.

That also means the answer to which version to use is not in this repository.

For a reader who has not worked with Xilinx tooling, the practical summary is this. The BSP holds the startup code, the exception vectors and the hardware abstraction for a processor family. The drivers hold the interface code for each piece of IP, and each has its own data, docs, examples and source. The software services are the libraries built on those drivers. The applications are the boot firmware images, and they are built per board. And the third-party tree supplies the real-time OS, the TCP/IP stack, the hardware abstraction layer and the inter-processor communication library that tie the multi-processor parts together.

Editorial conclusion

embeddedsw fits an embedded developer working with Xilinx or AMD Zynq, ZynqMP or Versal silicon who needs the drivers, board support packages and firmware that sit under a Vitis project, and who is comfortable reading per-board instructions in the tree. It does not fit a general Linux or RTOS developer, since the code here is bare-metal and board-specific, and it is not a place to look for a tidy install. Before building anything, read the README.txt in the misc directory of the specific application you need, check the board list in that file, and consult license.txt in the repository root, because the licence differs per component.

Frequently asked questions

Official sources

1. Issues
2. README
3. Xilinx/embeddedsw on GitHub