Creating your own Linux for the BAV335x

Why would you want to go throught the exercice of creating your own linux distribution when you could just download one from Ubuntu or Debian? Well it really is a question for you to answer so, consider this; a bootable linux system consists of a boot loader, a kernel, a device tree, an init process of sorts, and a fairly large collection of utilities. When you download a distribution, you are installing a collection of utilities, each of which have a version number associated with it. And when you download a distribution, you usually get the latest version that the distribution has to offer at that point in time. So, if you install a distribution today, and again in 6 months, you will get a different set of version numbers for the utilities. If, like us, you are in the business of distributing a finished product, this may not be desirable. How do you know that a newer version of some common library will behave with your application which was written and tested on another version of that library. Performing QA would be a never ending task and how would you run successful technichal support with so many variances. This is just food for thought, as stated previously, we do not endorse one method over another, it's purely a matter of choice.

At Birdland Audio, we decided to compile our own distribution so we get to chose which version of what utilities are used in the root file system of our finished products. If this sounds like something you might want to do, we recommend to use buildroot. It's a bit rough, and because it is designed to support lots of configurations (from MMU-less processor running uClibc to full fledged desktop class SoCs), you will most likely run into a few snags. None of which are a big problem if you have a good understanding of Linux. None of it is all that complicated, it's more a matter of how much time you are willing to spend on it. What we offer below, is a small collection of scripts and fixes to clean up some of the quirks left behind by buildroot (eg, SysV files left behind when you select systemd, or missing mount points breaking systemd, etc...)

The code shared in this page is provided as a courtesy to hopefully help speed up development using Linux on the BAV335x. Most of the code is provided by the efforts of the buildroot and linux community and we do not take any responsibility about any of the code written by us or not. No free technical support will be provided regarding any of the information on this page.

Birdland Audio shall not in any event be liable for any direct, indirect, punitive, special, incidental, or consequential damages, including, without limitation, lost revenues, or lost profits, arising out of or in any way connected with the use or misuse of the information, or lack of information on Birdland Audio's Web site, or from any information, documents, services, software, or other material obtained here.

NOTE: In the sample command lines throughtout this text we assume you are familiar with the standard convetions where square brakets indicate [optional text] and angled brackets indicate <text you will need to replace> with the correct text depending on your development environment and/or preferences.

1.0 Initial Preparation

The first step is to create a directory in your home directory to hold all the development (may be any name of your chosing). We'll call it bbdev
$ cd ~ $ mkdir bbdev
and create another directory inside to hold the packages (must be named package-sources unless you reconfigure)
$ cd bbdev $ mkdir package-sources

2.0 Downloading the buildroot sources

Clone the buildroot branch with support for the BAV335x. Note that this branch is created from the official master branch of buildroot. Every once in a while, we check out newer stable versions of master and merge, though we offer no guarantee as to how often this gets done. At the time of this writing, we are supporting the 2016.11 tag and the Linux Kernel 4.4.
$ git clone -b bav335x $ cd buildroot-bav335x $ git checkout bav335x -b your-branch-name ?>
Create a directory where you want to build your first product. You can name this directory whatever you want. One of the nice things about Buildroot is its ability to support many build directory sets (one for each product), each with its own config, from the same set of sources*.
$ mkdir myfirst-product-rootfs
Do a initial one-time setup to prepare the directory. This will setup all appropriate defaults to create a working rootfs for the BAV335x.
$ cd myfirst-product-rootfs $ make O=$PWD -C ../buildroot-bav335x bav335x_sysd44_defconfig

3.0 Building the root file system from scratch

You're ready to build! Buildroot will now go and download all the source tarballs for all the selected packages to be included in the root file system (ex: sources for vim, less, etc..). This configuration will first downloads the sources to the directory names "package-source" created in step 1.0 (subsequent builds will use the sournces in this directory. This behavior can be changed in menuconfig.)

Buildroot will also download the Linux Kernel 4.4. For convenience, we also host a tarball of the Kenel with Robert Nelson's patches for the Sitara MCU on BBB, with a Device Tree and defconfigs for the BAV335x.

You will want to run menuconfig and change "Kernel/Device Tree Source file names" to the DT name specific to your hardware if you have one. Of course, this pre-supposes that you modified the KERNEL to add your custom dts/dtsi files (they reside in KERNEL/arch/arm/boot/dts).

$ make
Go do something else! This may take a while. When its finished, the kernel and rootfs will be in the images directory. At this point, it is useful to go into the images directory and create two mount points for future usage so you can mount your micro-SD card and transfer data to it.
$ cd images $ mkdir mnt.card $ mkdir mnt.rootfs

4.0 Copy system boot to the micro-SD card

If you don't already have a u-boot bootable micro-SD card, you can follow the instructions in Preparing the micro-SD card for the first time to make one. The next step is to copy the device-tree and kernel zImage to the DOS partition and, the Linux root filesystem just built by buildroot, to the second linux ext4 partition. Before proceeding, make sure to understand the device names for your micro-SD. The system device name will vary depending on the Linux distribution you are using for your desktop.

You will need to replace <YOURCARD_PARTITION1> and, <YOURCARD_PARTITION2> with the appropriate names for the first and second partition of your micro-SD card respectively

For most Systems the card will be /dev/sdX where X is either b, c .. z.
On other systems the card will be /dev/mmcblkN where N would be 0, 1 or some other number.
Use lsblk to list all block devices and determine which one is your micro-SD.

If you do not understand what this means, you should seek help from somebody who does as this is very important and incorrect naming could result in total data loss on your computer.

Also, replace birdland-bav335b.dtb with the dtb for your hardware and don't forget to edit uEnv.txt in the bootable DOS partition to reflect that (ie: replace the line containing fdtfile=birdland-bav335b.dtb with fdtfile=<your-dtb-name.dtb>

$ sudo mount <YOURCARD_PARTITION1> mnt.card $ cd mnt.card $ sudo mkdir dtbs $ sudo cp -v ../birdland-bav335b.dtb dtbs $ sudo cp -v ../zImage . $ sudo umount mnt.card

5.0 Transfering the rootfs you built to the card

From the images directory (~/myfirst-product-rootfs/images) - where we already created the two mount points card.mnt and rootfs.mnt, we mount both the micro-SD card 2nd parition and the rootfs we built to transfer the root file system over. I recommend using rsync based on file size and md5 signature (ignoring file dates as they change during build) which turns out to be much faster after the second time around.

Replace <YOURCARD_PARTITION2> with the appropriate name for the second partition of your μSD card (eg:/dev/sdb2 or /dev/mmcblk0p2)

$ cd ~/bbdev/myfirst-product-rootfs/images $ sudo mount <YOURCARD_PARTITION2> mnt.card $ sudo mount -o loop rootfs.ext4 mnt.rootfs $ sudo rsync -avxP --delete --size-only mnt.rootfs/ mnt.card/ $ sudo umount mnt.card $ sudo umount mnt.rootfs

6.0 Try it

The micro-SD should be ready! Insert it into the BAV335x card slot and try it out. If you're using the BAV335x Evaluation Board, you can connect the USB connector to your computer and use a terminal program (eg. minicom) to monitor the console boot. By default buildroot/Linus will set the serial console to 115200 8N1 (8 bits, No parity, 1 stop bit) unless you changed it.

Of ourse at this point, you can create your own branch and add specifics to your product development. Something like:

$ cd ~/bbdev/buildroot-bav335x $ git checkout bav335x -b my-branch $ git remote add myserver $ git push myserver my-branch

Build root is very versatile and one of the most important steps when building a product the configuration used to compile the target image. Of course, it is strongly encouraged at this point to visit the official Buildroot website and familiarize yourself with it's build procedure and the way it handles packages as you may want to create packages specific to your applications.

Birdland's branch of buildroot has a few interesting features to help you with packages and configurations.

Configuration Save

The bav335x branch includes a postscript which, at the end of the build, saves a version of the configuration used to build the target image, into the target. The file is saved as an archive under /etc/br-conf.tgz containing single file like:
Notice how the file not only include the configurtion used but also, encoded in its name is the branch and the commit ID used. This is especially useful as you continue development and advancing the head of your branch. You can always checkout the ID encoded in a finished product and rebuild that exact same target image.

Simple Pre-installed Packages

The bav335x branch also includes a very easy way to add files or pre-compiled packages to the target image. This can be especially useful if you wanted to have a set of files such as audio files, or website, copied to the target image post build. to learn more about this feature, read the README file under