AMD maintains a branch of the Linux kernel at GitHub - Xilinx/linux-xlnx: The official Linux kernel from Xilinx.

For technical and business reasons this “vendor kernel” is required and is managed differently than the “mainline kernel”. This page will attempt to explain how AMD handles branches, and the intended purpose of those branches.

Table of Contents

Background

AMD is an FPGA/Adaptative Computing hardware vendor. Many of AMD’s Adaptive Computing products include a “processing system” which is a cluster of “hardened” CPU’s intended to work with the adaptive fabric. Like most processor vendors, AMD provides software tooling to help it’s customers avoid duplicating work that is common.

These products include a proprietary development environment, bare metal drivers, RTOS support layers, and many tools to support open-source software. One of the most common open-source tools is Linux. AMD contributes as directly as it can to the Open-Source Community, and specifically the Linux Kernel, but there are pieces of code that AMD simply cannot get “upstream” (for both technical and business reasons). For these pieces of code, AMD maintains its own “fork” and maintains copies of certain Kernel release branches where other members of the Linux Community can get that code.

Operating System Vendors

AMD is not an Operating System Vendor (OSV) and does not provide guarantees about when and how it’s branch of the kernel will receive security patches or bug fixes. AMD therefore recommends that customers using its hardware that need these kinds of guarantees work with an OSV.

Branch overview

Development processes in the open source community occur more often than AMD provides development updates. As a result, AMD only maintains certain branch copies of certain versions of the Linux Kernel. This is intended to provide some stability to our customers while also ensuring that we and our customers can stay up to date on the latest, most feature rich, secure Linux Kernels. With that goal in mind, AMD “uplifts” the branch on which it bases all of its patches to the Linux Kernel once per year for the “<year>.1” release and uses that same kernel for the “<year>.2” release.

Examples

Release choice

When considering which branch to “uplift” to, AMD picks a release from the upstream source (for example 5.15 or 6.6) some time before it needs to do its own software release. This is so that internal developers working on support for new hardware have a “target” to work against. Once this branch is chosen, and throughout the AMD lifetime of that branch, a number of “sub” branches will be created.

LTS kernels

The base kernel for a year is picked in late December and will always be the latest LTS kernel picked by Greg KH at that time.

Yocto alignment

AMD does not give preference to or defer to any particular build tool when choosing kernel versions. Specifically, for Yocto Linux, the AMD 2024.2 Yocto is “scarthgap”, which happens to use the 6.6 branch of the Linux Kernel, and AMD happens to have chosen 6.6 as our base kernel for 2024. However, while “scarthgap” will remain on 6.6 until 6.6 leaves support, AMD will be upgrading its kernel for the 2025.1 release to a more modern LTS kernel and AMD’s Yocto layers will use the more modern LTS kernel.

Per kernel version branches

In the below sections, <version> means the base kernel version chosen by AMD for that release, (for example, 5.15, 6.1 etc.) and <AMD release> means the release identifier for AMD (For example, 2022.1, 2024.2 etc.)

master

This branch uses a “merge” strategy. Once a year when AMD chooses a new <version> to upgrade its kernel to, AMD merges in the latest commit from that kernel.

This creates a “merge” commit every time AMD updates kernels.

Open

xlnx_rebase_<version>

This branch is intended to be used by AMD’s customers and partners who need maintain kernels with AMD patches applied. It takes a base kernel version branch (i.e. x.y.0 NOT x.y.z) and applies all AMD patches to it. It is the place that AMD goes when it has picked a new kernel and wants to move all prior work to a new kernel. To put it another way, the history of this branch is the “cleanest”. It is the upstream kernel with i’s history, and then all AMD's patches applied with no intermixing of upstream after that point. It does get any new development that AMD does.

Open

xlnx_rebase_<version>_LTS

This branch can be seen as AMD's “working branch” for a given kernel release from a customer perspective. It receives both internal updates to AMD specific hardware/patches AND semiannual pulls from the upstream repo for patch levels. It branches from and is therefore based on xlnx_rebase_<version>, but it diverges as soon as AMD pulls from the upstream repo.

Open

xlnx_rebase_<version>_LTS_<AMD release>_update

The xlnx_rebase_<version>_LTS_<AMD release>_update branch is used by AMD to provide critical bug and security fixes to recently released software. This support is short term for critical fixes. Longer term or SLA level support cannot be provided through this branch.

Open

Summary

Upstream cadence

The above branches all have different release cadences. Due to the need to work internally on yet to be announced AMD products, the xlnx_rebase_<version> and xlnx_rebase_<version>_LTS branches are “taken inside” the company and only pushed out a few times a year.

The xlnx_rebase_<version>_LTS_<AMD release>_update branch is updated whenever issues are fixed.

Examples

Example of a mutual patch and how it would be managed

As an example of why customers should carefully consider which branch to base their product off of and whether to use an OSV, consider the following situation.

A bug is found in the kernel, and some piece of code related to something AMD or one of its customers is doing is affected by the bug.

AMD investigates and creates a fix and commits it to xlnx_rebase_<version>, xlnx_rebase_<version>_LTS, xlnx_rebase_<version>_LTS_<AMD release -1>_update, and xlnx_rebase_<version>_LTS_<AMD release>_update.

If applicable, and if it has not already been solved in some way, AMD will submit the patch to the upstream Linux kernel.

Open

Another entity in the open source community also creates a fix for that bug and is able to add that fix to the mainline kernel.

Open

Each branch is going to have a different response:

xlnx_rebase_<version>

When AMD become aware that there is a fix for the bug “upstream” AMD will remove (from the history) it’s fix for this bug and the bug will continue to exist on this branch.

AMD will assume that anyone using this branch is using it to rebase onto another kernel that will receive the upstream fix.

xlnx_rebase_<version>_LTS

When AMD pulls from the next patch version of the upstream source, AMD will remove it’s fix, and the upstream fix will be implemented on this branch.

xlnx_rebase_<version>_LTS_<AMD™ release>_update

AMD will decide based on the nature of the fix and the state of this release whether to commit the upstream commit and remove the AMD fix or leave the AMD fix in place.

Open