Working with AMD open-source Adaptive SoC software repository branches

If you work with AMD Adaptive SoC’s and want to contribute, use tools with different versions than those you are using elsewhere (for example, using Vivado xxxx.y but using an open source software tool xxxx.y+-1), or dive into the open source code, it is important that you understand how AMD works with branches.

When you go to an AMD open-source repository on github.com, you will likely default to the “main” or “master” branch. You might notice that this branch is quite old. This is because internally AMD engineers work on release branches targeting the next release and only release code twice a year. This has to do with internal testing and release criteria to ensure that the open-source tools are compatible with the other software and hardware in the AMD Adaptive SoC ecosystem.

 When trying to check out an AMD open-source repository from GitHub, it is important that you look at/check out the appropriate branch/tag. Most often this will be the `rel_vYYYY.R` branch where YYYY is the current year and R is the release number, with release .1 usually coming out early in the second quarter, and release .2 usually coming out early in the fourth quarter.

It’s also important to recognize that you might want to use a tag, not a branch depending on your use case. Tags remain pointed to the same commit in git while branches are updated with critical fixes.

 Repositories like the Linux Kernel and U-Boot that are tied to and based on so called “upstream” repositories, will often have additional branches that change how AMD changes are merged/rebased with that upstream repository. See this page for further information.

Open