Contents


Introduction

A common problem with Single Board Computer (SBC) is that their official OS support sucks. Except the BeagleBones, Raspberry Pi(s) and the NVIDIA Jetson family there is hardly any SBC with well maintained software support. If new SBCs are released it is not uncommon that the software stack/operating system is close to End Of Life (EOL) already. Another thing I experienced multiple times that a full system update (apt-get update && apt-get dist-upgrade) broke something and a SBC did not boot anymore or was no longer functioning properly. Some may consider this less of an issue if they simply use them to fiddle around a bit to build their own personal projects. However, when it come to building products which are connected to the internet this is not acceptable. I’m well aware that the “S” in IOT stands for security… .. Further, personally I prefer to work with upstream software (even LTS upstream) instead of dealing with old versions with backports.

Speaking of the BeagleBone Black, then latest image is based on Debian 10 and timestamped as 2020-04-06. Considering that it was released in 2013, we could consider the software support to be somewhat good. However, as of writing this article (November 2022), Debian 11 is a year old already and Debian 10 reached its EOL a year ago. Since its availability and easy of building custom OS/firmware for it is quite straight forward it generally is a reasonable good choice for some IOT projects and even some edge device deployment cases for e.g. computer vision (yes, very limited but sometimes that is all that is needed).

Flashing the Original OS

In /boot/uEnv.txt (on the microSD) the following line needs to be uncommented to flash the eMMC on the BeagleBone Black.

#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

During the next boot, the image is flashed to the eMMC drive. It takes approx. 5-10 mins and when it is done the BeagleBone Black will simply shutdown and there are no indicator LEDs showing anything. The SBC is ready for reboot now. The microSD card needs to be removed as this flashing process would be repeated on every reboot.

Changing passwords and running apt update && apt dist-upgrade is highly recommended after the first boot.

While can’t update the software stack (the repos) to something newer without a high chance of crashing everything, we certainly can perform a kernel update to something modern.

cd /opt/scripts/
git pull
cd /
sudo /opt/scripts/tools/update_kernel.sh --bone-rt-kernel --lts-5_10

apt list --installed | grep "94-ti"

libpruio-modules-4.19.94-ti-r42/unknown,now 1buster armhf [installed]
linux-image-4.19.94-ti-r42/unknown,now 1buster armhf [installed]
rtl8723bu-modules-4.19.94-ti-r42/unknown,now 1buster armhf [installed]
rtl8821cu-modules-4.19.94-ti-r42/unknown,now 1buster armhf [installed]
seeed-modules-4.19.94-ti-r42/unknown,now 1buster armhf [installed]
ti-cmem-4.16.00.00-modules-4.19.94-ti-r42/unknown,now 1buster armhf [installed]

Despite the fact that kernel updates are installed using an upgrade script libpruio-modules seems to be the only kernel-specific module that seems to receive an upgrade automatically. The two rtl modules can be update to e.g. 5.10 the others (seeed-modules & ti-cmem) can’t. If they are needed, a workaround is required or continuation of the 4.19 kernel.

Building and Flashing a New Version of the Official OS

Unlike (probably) for most other vendors of SBCs, the build scripts for creating images to flash on the device are available and maintained! The image-builder comes with various predefined configs which specify what software packages are installed and what operating system is used. This makes it super easy to our own images with our own software stack for (mass/production) deployment without spending an awful lot of time to reverse engineer the build system for a specific SBC. This is extremely value as really slim and specific images can be build easily and tested automatically in a normal build environment. This factor provided image builder is the main reason why I personally consider this SBC well supported despite the fact that the official images are a bit outdated.

If a plain and simple debian image (docker or vm) is used to run the build script, then [m4,tree,git,kpartx,parted, dosfstools, util-linux, build-essential] need to be installed.

This build infrastructure is straight forward. The first step is to build a generic base image.

./RootStock-NG.sh -c bb.org-debian-bullseye-iot-generic-armhf

In a second step the generic base image is prepared with some BeagleBone Black specifics and an image suitable to flash on a microSD card is generated.
In ./deploy there is folder which contains base images generated and the important setup_sdcard.sh script is in there. For detailed documentation the source code should be read or having a look at beagleboard.org_stretch_image.sh should help.

Executing

sudo ./setup_sdcard.sh --img-4gb bbb_img --dtb beaglebone --distro-bootloader --enable-cape-universal -enable-bypass-bootup-scripts --img ./armhf-xxxxxx.tar --rootfs_label rootfs --hostname beaglebone

should do the job and we get a nice image to flash on the BeagleBone Black. Make sure that it boots in flash mode again as mentioned above and boot the device. Once it is finished flashing it is time to remove the microSD card and it can be used.

Flashing Custom Linux Distributions

There are various tutorials on using other Linux distributions such as Arch Linux ARM or Gentoo on the BeagleBone Black and it seems like they work pretty decent and are an excellent choice if even more customization is required. If a fully custom distribution is required might be a project dependent choice.

Flashing a BSD

It seems like FreeBSD and NetBSD provide support for the BeagleBone Black. I did not test it myself. PRUs might not work but it might be a decent choice for certain applications.