Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to get a buildroot project under source control

Tags:

git

buildroot

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).

like image 560
Tormato Avatar asked Jan 08 '14 21:01

Tormato


People also ask

How do I enable Buildroot packages?

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.

What is a Buildroot package?

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.


2 Answers

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'
like image 191
milton Avatar answered Oct 02 '22 23:10

milton


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.

  1. You could include Buildroot as a git submodule in your repo. Ok, if your company only has one Buildroot project.
  2. Specify in the README file which version to use, or write a custom check for it.

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.

like image 33
Trygve Avatar answered Oct 02 '22 22:10

Trygve