Engineers starting Linux on an AMD Zynq-7000, Zynq UltraScale+ MPSoC or Versal part usually weigh three build systems: the Yocto Project, AMD PetaLinux and Buildroot. The Yocto vs PetaLinux question is less of a contest than it looks, because PetaLinux runs Yocto underneath. Buildroot is the separate option. This guide compares the three on the points that matter for a Zynq product: how each takes in the hardware design from Vivado, how each is customised and rebuilt, licence compliance, and when to pick each.
What the Yocto Project is
The Yocto Project is a set of tools and metadata for building custom Linux distributions. Its build engine, BitBake, runs recipes from layers: OpenEmbedded-Core for the base system, a board support layer for the hardware, and your own layers for the product. Each recipe fetches, patches, configures, compiles and packages one component. The build produces a kernel, a bootloader, a root file system image and, on request, an SDK with a cross toolchain for application developers.
For AMD parts, the meta-xilinx layers supply the machine configurations, the AMD versions of the kernel and U-Boot, the boot firmware, and the support for taking in a Vivado hardware export.
What PetaLinux is, and how PetaLinux relates to Yocto
PetaLinux is AMD's command-line tool set for building embedded Linux for its SoCs. A PetaLinux project is a Yocto build: the petalinux-* commands generate the Yocto configuration and run BitBake. PetaLinux puts a menu-driven configuration and a fixed project layout over Yocto, with a meta-user layer for your own recipes and device tree changes.
That arrangement gets a first image running quickly. Work outside the menus means working in the Yocto files underneath them.
AMD's direction is toward plain Yocto. AMD presents the AMD Embedded Development Framework (EDF) as the Yocto Project-based successor to the PetaLinux flow. Read AMD's release notes for your tool version before starting a long-lived product on PetaLinux.
What Buildroot is, and Buildroot on Zynq
Buildroot is a set of Makefiles and Kconfig menus that builds a cross toolchain, a root file system, a kernel and a bootloader. One configuration file describes the whole image. There is no layer system and no package manager on the target. Customisation lives in a board directory or in a br2-external tree kept outside the Buildroot source.
Buildroot ships example configurations for AMD evaluation boards, among them the ZCU102 and the Kria KV260. It builds the AMD kernel, U-Boot and Trusted Firmware-A for Zynq UltraScale+, and uses a device tree that is already in the kernel source. It does not read a Vivado hardware export.
Hardware handoff: the XSA and device tree generation
Vivado exports the hardware design as an XSA file. It carries the bitstream, the processing system configuration and a description of the IP blocks with their addresses and interrupts. The AMD software flows start from it.
PetaLinux and Yocto with the meta-xilinx layers both import the XSA and generate a device tree from it. The generated tree covers the processing system and the IP in the programmable logic. Board details the XSA does not contain, such as Ethernet PHYs, I2C devices and flash partitions, go in a hand-written device tree file included on top.
Buildroot has no such step. A Buildroot project for a custom Zynq board keeps its own device tree source, generated with the AMD tools or written by hand. Each FPGA change that moves an address or an interrupt means updating that file.
Rebuilds and reproducibility
Yocto and PetaLinux keep a shared state cache, so a later build rebuilds only the recipes that changed.
Buildroot rebuilds a single package on request. Its manual says a change to the toolchain configuration generally needs a full rebuild, because Buildroot does not track which package installed which files. Its option for bit-identical builds is marked experimental.
Licence compliance tooling
Every Yocto recipe declares its licence and a checksum of the licence text. The build writes a licence manifest for each image, the archiver class collects the source you must provide, and the build can generate an SPDX software bill of materials. PetaLinux and EDF builds have all of this, because they are Yocto builds.
Buildroot's make legal-info writes a manifest of every package with its version and licence, the licence texts, and the source of the packages.
Yocto vs PetaLinux vs Buildroot side by side
| Aspect | Yocto with meta-xilinx or EDF | PetaLinux | Buildroot |
|---|---|---|---|
| Built on | BitBake and OpenEmbedded layers | Yocto, behind petalinux-* commands | Make and Kconfig |
| XSA import | Yes | Yes | No; device tree kept by hand |
| Customisation | Your own layers and recipes | Menus and meta-user | Board directory, br2-external tree |
| Rebuilds | Per recipe, from shared state | Per recipe, from shared state | Per package; full rebuild for toolchain changes |
| Licence tooling | Licence manifest, source archiver, SPDX | Same as Yocto | make legal-info |
| Pick this when | A product with a long life, several boards, regular updates or an SDK for an application team | Evaluation, prototypes and short projects | A small fixed-function image with a stable FPGA design and few packages |
Choosing a PetaLinux alternative
Teams looking for a PetaLinux alternative usually want one of two things. Some want the control over Yocto that PetaLinux puts behind its menus; plain Yocto with the meta-xilinx layers, or AMD EDF, gives them that and keeps the XSA flow. Others want a smaller, simpler build; Buildroot gives them that, and they take on the hardware handoff by hand.
We build with all three, and we move PetaLinux projects to the AMD Embedded Development Framework, as part of our complete embedded Linux system development. Whichever build system you choose, the boot chain it produces is the same; bringing up a custom Zynq UltraScale+ board walks through it from U-Boot to a login prompt.