The company I work for develops a product that requires embedded Linux for which we use, as many other, Buildroot.
In any case, I would like to get the project under source control using Git, as it is our tool for source control for all the other projects the company has. The problem is that I don't know which files should I keep in source control (as keeping the whole buildroot
directory seems overkilling).
There are two main methods to add a custom package into buildroot. The first method includes adding a package directly into the source tree and is described here. The second involves the use of an external package tree. A reference to using the second method is provided at the end of this article.
Buildroot is a set of Makefiles and patches that simplifies and automates the process of building a complete and bootable Linux environment for an embedded system, while using cross-compilation to allow building for multiple target platforms on a single Linux-based development system.
I've tackling this same issue by working with git submodules
and buildroot br-external
feature.
In this sense, you only need to start an empty repository and import a buildroot release as a submodule of it.
mkdir myrepo; cd myrepo
git init
touch README; git add README; git commit -m "Initial commit"
git submodule add -b <preferred release/tag/branch> git://git.buildroot.net/buildroot
git submodule update --init
Then you can create a br-external
directory and populate it similar as buildroot's own package/configs/board directories as explained in BR2_EXTERNAL
documentation1.
mkdir br-external
# below command assumes you have all structures ready somewhere else
cp -fva .../configs .../package .../board br-external
touch br-external/{Config.in,external.mk}
(edit Config.in and external.mk)
git add br-external
After doing so, you only need to run buildroot defconfig step passing the absolute path to your br-external directory, like this.
make BR2_EXTERNAL=$PWD/br-external -C buildroot <boardname>_defconfig
Your BR2_EXTERNAL locations gets cached for further invocations.
The nicest parts of this is that you only need to versionate what's inside br-external and buildroot builds up the configuration menu in a way that all your custom stuff gets properly separated ("User provided options" menu entry).
Also, if you decide to bump-up buildroot release to a newer one, the only trouble is to upgrade the submodule and commit it. Perfect for configuration management.
cd buildroot
git pull origin latest-release
cd ..
git add buildroot
git commit -m 'buildroot latest-release upgrade'
I've recently tackled the same problem in our organisation, and I find this an interesting topic. I'll describe our partial solution here:
Manage which buildroot version you use
EDIT: Recent experience has emphasized this point for me.
Buildroot writes a different config files for each version of Buildroot. To be able to share these you need to specify to everyone involved which version of Buildroot your repository uses.
Building out-of-tree
I strongly recommend to build out of tree: http://buildroot.org/downloads/manual/manual.html#_building_out_of_tree
$ cd ~/platform/proj-arm; make O=$PWD -C path/to/buildroot
Add configuration files and target overlay to git
Add the .config file and sub-configuration files to the git repository. My repo contains the following:
.config
README.md
linux.config
build/busybox-1.22.1/.config
libdc1394.patch
opencv_2.3.1a.patch
target-overlay/README~
target-overlay/etc/dropbear/dropbear_ecdsa_host_key
target-overlay/etc/dropbear/dropbear_rsa_host_key
target-overlay/etc/fstab
target-overlay/etc/httpd.conf
target-overlay/etc/init.d/S51mount_html
target-overlay/etc/init.d/S52new_ip_address
target-overlay/etc/init.d/S53httpd
target-overlay/etc/network/interfaces
target-overlay/etc/shadow
target-overlay/etc/sshd_config
target-overlay/lib/firmware/rtl_nic/rtl8168g-2.fw
target-overlay/root/.ssh/authorized_keys
Save your changes to buildroot as patches
Whenever you change stuff in the buildroot repository, branch out for that feature, and create a patch for it. Keep the patch in your repository, and use the README.md file to explain to others how to apply it to the buildroot tree.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With