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.
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).
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.
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>
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)
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.
5.0 Transfering the rootfs you built to the card
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:
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.
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:
brgit-origin/next-bav335x-0116f821c9e08630e320e7246bbd096fdcf0d56e.conf
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.
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
~/bbdev/buildroot-bav335x/board/birdland/bav335x/packages