How to get a buildroot project under source control

Question

The company I work with is developing a product that requires embedded Linux, for which we use, like so many others, Buildroot .

In any case, I would like to get the project under source control using Git, as this is our source control tool for all other projects that the company has. The problem is that I don’t know which files should be stored in the source control (since saving the entire buildroot directory seems redundant).

Answer 1

Recently, I dealt with the same problem in our organization, and I consider this interesting topic. I will describe our partial solution here:

Controlling which version of buildroot you are using

EDIT: Recent experience has highlighted this point for me.

Buildroot writes different configuration files for each version of Buildroot. To be able to share them, you need to tell everyone who uses the version of Buildroot that your repository uses.

• You can enable Buildroot as a submodule of git in your repo. It’s good if your company has only one Buildroot project.
• Indicate in the README file which version to use, or write a special check for it.

Creating an external tree

I highly recommend building from a 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 subconfig files to the git repository. My repository 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 changes to buildroot as patches

Whenever you change material in the buildroot repository, open this function and create a patch for it. Save the patch to your repository and use the README.md file to explain to others how to apply it to the buildroot tree.

Answer 2

You have two main options.

• The easiest way is to clone the buildroot repository (it’s not very big) and create your own branch based on the release tag. This makes it easy for you to make changes to buildroot, but it’s difficult to create global tags and branches (i.e., give the same buildroot tag and native code). However, if you want to combine it with a repository of your own code (so that everything can be marked together), you must use the w20> submodules or add a subtree (none of them are very convenient), or you need to save them as a separate repository and Use a second integration solution.
• You can base your product on tarroot buildroot and write a build script that loads tarball, extracts it, configures it (* make xxx_defconfig * is called) and builds it. The recently added BR2_EXTERNAL mechanism (which will be released in 2014.02) will make it easier to keep your own add-ons outside of the buildroot tree. However, if you need to change something in the main infrastructure, you need to apply corrections to the loaded tarball, which is inconvenient.

Of course, it is not recommended to extract the tarroot buildroot into your repository and import it this way, because it makes it difficult to update the buildroot tree or even apply patches up. If you want it in your own repository, use git subtree merging to at least keep upstream history.

The third option is to use the repo tool for Android to combine git buildroot, linux repositories, native code, and other packages you have changed. This combines the best of two parameters that I have given (it is easy to modify and maintain global tags / branches). But I never tried this myself, so I can’t promise that it will work well.

Answer 3

I deal with the same problem while working with the git submodules and buildroot br-external functions.

In this sense, you only need to start an empty repository and import release buildroot as its submodule.

 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 

You can then create the br-external directory and fill it in the same way as buildroot your own package directories / configs / board, as described in the BR2_EXTERNAL documentation 1 .

 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 that, you just need to run steproot defconfig, passing the absolute path to your br-external directory, for example.

 make BR2_EXTERNAL=$PWD/br-external -C buildroot <boardname>_defconfig 

Your BR2_EXTERNAL locations are cached for subsequent calls.

The best part is that you only need to update what inside br-external and buildroot creates the configuration menu so that all your user materials are correctly separated (menu item "User Preferences").

In addition, if you decide to break the buildroot release into a newer one, the only problem is updating the submodule and fixing it. Ideal for configuration management.

 cd buildroot git pull origin latest-release cd .. git add buildroot git commit -m 'buildroot latest-release upgrade'