Revision Control of your Embedded Linux System
Using Yocto you’ll need to juggle several repositories at once. You’ll have your ‘poky’ repository (typically you’ll get this from https://git.yoctoproject.org/git/poky), then you’ll have your OpenEmbedded layer (usually retrieved from https://github.com/openembedded/meta-openembedded).
In addition, you’ll also have your chip specific layers, and then you’ll probably have your own project specific layer. So you may have anywhere up to 10 or possibly more repositories to handle.
Crafting ‘repo’ manifests
Earlier in this series, a short introduction to the tool named ‘repo’ was given. This tool allows multiple git repositories to be handled together as a cohesive whole. At its heart is the idea of a manifest, which is simply a list of git repositories and commit IDs (or tags or branches), and how to arrange them on your local filesystem.
Each manifest file is written in XML, so you would have your first line as typical XML version boilerplate:
The entirety of the rest of the file should be held in a root element called “manifest”, so your next line would be
And the last line will always be
Inside this root note you will enter all your remote servers in the form:
And you will enter all your repositories in the form:
The final fetch URL will be a combination of the “remote-url” and the “project-name”.
Below is an example of a manifest.xml
<! — remotes →
<! — upstream OE layers →
<! — SoC vendor layers →
<! — SoM vendor layers →
<! — Project specific layers →
There are a few things to notice here. First is that I’ve got not only the SoC (system-on-chip) layers here (from NXP), but I’ve also added the SoM (system-on-module) layers as well (in this case from Variscite). You may or may not be using a SoM in your design, but if you are it generally means an extra layer or two.
The other thing to notice is that for the project specific layer, I’ve given ‘master’ as the revision. This means that ‘repo’ will checkout the master branch on that repository. This makes sense for development as we will probably be adding to that repository as we go whereas the other ones will be static.
The revisions chosen for all the other repositories should match in Yocto version, they should have been designed for a specific use case. As many of these as possible should be copied out of a manifest XML file for a reference design, if one exists.
Basic repo usage
You need to create a repository to hold your manifest file (I know another repository) is the last thing you need. But this can be on your local machine if you wish, at least to begin with.
Once this is done, you should find a folder in which you wish to keep all your sources, and run the following
repo init -u -m -b
This sets up the current directory as the working directory for this repo manifest, now you can run
repo sync
which will fetch all the repositories into the local directory. If you want to see if everything is as it should be (no changes in the repositories and branches with respect to their upstream brothers) you can run
repo status
and if you want to update everything to the manifest discarding all changes you can run
repo sync –d
these tools should give you enough get going with repo and Embedded Linux development.
And that concludes our series on How to Survive Embedded Linux.
We hope it’s been of use to you. There are occasions where it’s worth getting programming specialists to look into Embedded Linux issues for you.
At ByteSnap, we have several man-years of experience working on Linux BSP design, across a wide range of technologies and issues, which allows us to be adept at solving Linux conundrums.
We can also provide off-site specially tailored training on all matters Linux BSP — so get in touch to see how we can help with your Linux development project.
Also published on Medium.
How can ByteSnap help you today?
From start-ups to blue chips, ByteSnap’s embedded systems developers are enabling companies to stay a step ahead by providing them with bespoke solutions. Maintain your competitive edge – contact us today and find out how we can optimise your product development!
