world leader in high performance signal processing
Trace: » release-creation

Making a U-Boot Release

This page covers the release process for the Blackfin Das U-Boot project. It is mostly an internal checklist for developers, but other people may find it interesting.


You will need:

  • A Linux system capable of compiling U-Boot
  • The Blackfin GNU Toolchain (matching release version)
  • Some hardware to test
  • GIT SCM installed

Step by Step


Install the Blackfin GNU Toolchain. Make sure you install the version that matches the release you are making for U-Boot. So if you're making a 2010R1 release, use the 2010R1 toolchain release.


Every major release is branched from GIT trunk. Every single release is then tagged from that branch.


First clone the GIT tree (replace the URL with whatever you need to access things).

git clone ssh://$
cd u-boot


Now you're ready to actually create the release branch from trunk, check it out, and then push it back to the remote git repo:

git checkout -b 2010R1 trunk
git push origin 2010R1

You should update the localversion-adi file to match the version you will be tagging and commit it.


The branch is a step closer to the release sources, but we don't use it directly for an actual release. You have to tag the specific release:

git tag 2010R1-RC1 2010R1
git push origin 2010R1-RC1

If you want, you could also annotate the tag with -a (add a short message to the tag), and additionally GPG sign it with -s. We don't require either.


In the checked out repo, you now run the BUILD-RELEASE script. This will take care of creating the source tarball and building all the release images from that.


You will now have a bunch of files in the ../RELEASE/ directory. All of them will be uploaded to the webserver for release.


Once the packages have been created, they need to be posted to the website for people to access.


Upload the RPMs and SRPMs via anonymous ftp to and place them in the /u-boot/ directory.


Start with the toolchain FRS admin page.

Click Add Release and fill out the form like so:

Field Contents
Release Name Something like 2010R1-RC1
Release Notes URL to the release notes in the wiki like
Changes Any changes to the last RC release in this series (if you feel like it)
Released Do not check
Development Status Use alpha or beta as appropriate
Project Upload Files Check all the relevant files to add to the release

Once we've settled on an RC for release, we will (at a later point in time), edit that release and check the Released box and change the Development Status to Mature.