BEAGLEBONE BLACK: BASE OPERATING SYSTEM

One of the challenges with these low cost boards running open software is the understanding and installation of the operating system and related audio applications (such as MPD). Although RuneAudio and Volumio are solutions aimed at simplifying the installation process and are specifically geared toward audio, It is still beneficial to understand the s/w installation process “from scratch”.

As I only have a BBB on hand (I have (Rev B) [link]), my experiences are limited to this particular board.

INSTALLING S/W ON BBB

Every BBB comes loaded with the Angstrom operating system from the factory. After installing the network-over-USB drivers on the PC and powering the board with the included USB cable, you can access the board either through a browser or through a terminal application. The board is “fully operational” but it can’t just plat a music track. Configuration of the operating system is required. In addition a more functional music player is also required.

There are many ways of installing and setting up the s/w. And there are all pretty similar. Here are a two notable guides for installing the operating system and the music player application MPD.

But every situation and environment is a bit different and thus I shall also share my experiences :-)

INSTALLING THE BASE OS: DEBIAN

The first thing to determine is which OS? We know BBB comes with Angstrom but there are many other versions available. It is a good idea to limit the choices to the “officially supported” choices to minimize potential incompatibilities problems. The current “official” images can be found here: [link].

As of today, there are only two “official releases” of the operating system fully customized for the BBB board: Angstrom and Debian. From reading the forums, Debian provides more support for audio/multimedia applications than Angstrom. At least it seems Debian is easier to configure. There are also plans to have Debian pre-installed on the boards [link]

As of March 5, 2014, BeagleBoard.org is providing customized Debian images on the Latest Images Page and making plans to include those images on production BeagleBone Black boards on the on-board eMMC.

—

My project was so slow to develop as I had to research every little change I needed for angstrom and then node was too beta to use. I found debian7 on elinux and gave it shot (running from SD). and I gotta say that this has revived my interest in the BBB and now able to spend time on my project and not tuning the OS.

I love that its light weight (no GUI) and fits onto plentiful 2gb cards, the install is vanilla which allows me to install what I need easily with out services clashing. Once I found out about optargs in uenv.txt I was flying. With killer documentation, setup scripts and adafruits python mod installed out of the box – this will just the best!

SD or eMMC?

BBB allows booting either from the internal eMMC (the on-board NAND storage) or from the MicroSD card. The default mode is to boot from the eMMC storage. Pressing the boot-button during power-on allows booting from the MicroSD card. (See the “Booting” section below for more details).

The installation images are different for SD-boot and eMMC-boot. The images that are intended to be installed in the eMMC are called “eMMC-flasher” images. Included is a script that would copy/install the operating system onto the eMMC storage right after booting. Read more about this format here [link].

Booting from the internal eMMC, has the additional advantage that the SD card can then be used to store music tracks.

INSTALLING DEBIAN ON THE eMMC

Download the eMMC flasher version: BBB-eMMC-flasher-debian-7.4-2014-03-04-2gb.img [link]. The official Debian image was made available just a few days ago.

The 4 USR LEDs flashing while the OS is installed in the eMMC storage (step 4 above)

When the installation is complete, the 4 USR LEDs will be lit solid. This installation process took about 13.5 minutes with a Class 10 MicroSD card.

BOOTING

After removing the uSD card, BBB will boot off the eMMC when you power cycle the board.

Earlier I thought that with the OS installed in the eMMC storage, every time you power the board, it will boot from the eMMC regardless of whether you have a uSD card in the card slot or not. This is not the case. BBB will boot off the eMMC only if the inserted uSD card is NOT a bootable card. Both the regular image and the eMMC flasher image are bootable images.

If you leave the uSD card (with the eMMC flasher image) inserted and power on the board, the board will boot off the uSD and will start flashing the eMMC (again). Then you will have to wait until the end of the flashing process. Stopping the flashing process in the middle will obviously corrupt the installation.

The requirement to press the boot button when booting from the uSD card (as indicated in the documentation) may only be required when you first power the board as shipped from the factory.

CHECKING YOUR INSTALLATION

Check the installation by removing the MicroSD card (so it will boot from the eMMC) and connecting the board to a computer with the provided USB cable. The Debian Installation behaves the same as the original Angstrom installation: Upon boot, the board will show up as a storage device:

This is a very good way to check if the installation was successful. The board must quickly show up as storage when connected to a computer through the USB cable. As it turned out in my case, the majority of the installations are successful but not 100%.

The static IP address remains the same: 192.168.7.2. It is a static address specified in /etc/networks/interfaces

This address is only accessible by the computer to which BBB is connected through the USB cable (and the USB-Network drivers are installed). It is not visible anywhere else because it is configured to connect through “usb 0″ as shown above.

Doing a free space inventory on the file system (typing “df” in the command line) we find that the s/w occupies 79% of the available space. The s/w takes up 1.27 GB

The official image found here [link] is dated 03/04/14 and kernel version 3.8.13-bone41

(Type “uname -r” to get the kernel version).

After flashing this version in the eMMC, we find the following:

Notice that the s/w occupies 24% in comparison. The s/w occupies 389 KB. I am not sure what is the difference between this version and the “official” version (aside from having more features). However, it is probably better to use the later versions as these releases are still beta releases and bugs are continuously being fixed. Also, I couldn’t get the network (ethernet) to work in this version.

REMOVING “UNNECESSARY” S/W

According to this discussion [link] the eMMC is almost full due to everyone’s out-of-the-box requirements. Things that can be deleted are:

These are the savings after each removal. In total, Free space in the eMMC was increased by 567MB.

Notice that after removing libopencv* free space got reduced. Apparently the first time you use apt-get, some files are created (e.g. to hold the package list, etc). In another occasion when installing a package under 1M, free space was reduced from the factory 344MB to 274MB, a net loss of 60MB. Removing libopencv* right after resulted in a net gain of 26 MB.

Note also that since I don’t know much about Linux/Unix, I am not 100% sure these would not cause problems, but I checked the functionality of those packages and they seem to be safe for removal. So do at your own risk :-)

On a side note, configuring Linux/Unix as a beginner can kill a lot of time without accomplish much. In addition, although there is a lot of information in the internet, it is all over the place and covering lots and lots of different configurations. A desktop environment behaves different from an embedded environment. It is best to look for information that closely matches your environment (for example posts about Rasberry Pi will resemble the BBB environment, but posts about Debian running on a laptop may not apply). Further, there are different ways and applications to accomplish the same thing. Some work (for me) and some don’t work.

I guess the wise thing is do is to take advantage of the work from the people at RuneAudio and Volumio. RuneAudio even says that the OS is built to include only the essential components which beats my approach of slimming down an installation.

In the meantime, it is still good to have some understanding on the internal behavior of the operating system. Enjoy hacking :-)

Update (3/21/14)

I’ve used the following sequence to remove packages and recorded how much free space is left. Using autoremove removes other packages that are part of the main installation, packages that are subsequently removed may result in very little space savings because the dependent packages may have already been removed with autoremove.

In addition:

Removed the packages in the installation uSD so that every time I flash the image to the eMMC, the removed packages are not copied over.

Modified /etc/network/interfaces and /etc/resolv.conf in the uSD and this is copied over during the flashing

Installed cifs-utils in order to support mounting of share drive

Modified /etc/fstab but a new one is generated during the flashing, so it is replaced by a new one. Editing the /etc/fstab is necessary after every flashing to the eMMC or create a newfile with the new fstab entries and append to fstab file with the command: cat etc/newfile>>/etc/fstab

Share this:

Related

Great info here once again, I will do some fine tuning based on the article.

Couple of items:
I have installed Archlinux on the BBB from here http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black tho its not a “pretty” install.
I have found that the BBB seems to remember its been booted off the SD card and after the first boot (or so?) holding down the boot button there is no need to hold the button as long as the SD card is in the slot. I know thats not how its documented but seems to work for me.

Thanks for sharing. You are right about the boot sequence. If you have a bootable SD card, it will boot of the SD card. I guess I tested it with non-bootable SD-cards in the slot, in such case it would boot from the eMMC. I’ll correct the post…