Book Image

BeagleBone Essentials

By : Rodolfo Giometti
Book Image

BeagleBone Essentials

By: Rodolfo Giometti

Overview of this book

Table of Contents (18 chapters)
BeagleBone Essentials
About the Author
About the Reviewers

(Re)Installing Debian

The on-board system is a complete ready-to-use Debian distribution; however, it may happen that we may need another image (maybe during some developing stages) or just for backup purposes (just in case, the default image is corrupted for some reason). So, it's important to see how we can install an alternate image on our board.

There are many ways to install a Debian OS on our BeagleBone Black. I'm going to use the simplest and quickest one using a prebuild image to be put on a microSD. This solution has the advantage that by simply removing the microSD from the system, the board will boot with the original default image.


A similar procedure may be used to install a different OS too.

Note that the microSD should be a class 10 and have at least 4 GB storage space.

The first step is to download the image to a working directory on the host machine. We have several resources on the Internet, but I chose the one at

The command to download the file is as follows:

$ wget

By the time you read this, new versions could be available or the current one could be missing. Then, you should verify the available versions in case of errors while downloading the rootfs image used earlier. Next, unzip it, and then enter the newly created directory:

$ tar xf debian-7.6-console-armhf-2014-08-13.tar.xz
$ cd debian-7.6-console-armhf-2014-08-13

We are now ready to build our microSD.


This is a very important step! Follow the steps carefully or you may damage your host system.

The command to build the microSD is as follows:

# ./ --mmc /dev/sdX --dtb BeagleBone

Here the /dev/sdX device must be chosen carefully. The best way to do so is using the tail command on the host in order to watch the kernel messages while we insert the microSD into our host PC:

$ tail -f /var/log/kern.log

In this situation, an usual kernel activity should be something like this:

usb 2-1.1: new high-speed USB device number 18 using ehci-pci
usb 2-1.1: New USB device found, idVendor=058f, idProduct=6387
usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.1: Product: Miss Storage
usb 2-1.1: Manufacturer: Generic
usb 2-1.1: SerialNumber: 9B4B5BCC
usb-storage 2-1.1:1.0: USB Mass Storage device detected
scsi13 : usb-storage 2-1.1:1.0
scsi 13:0:0:0: Direct-Access     Generic  FIash Disk       8.07 PQ: 0 ANSI: 2
sd 13:0:0:0: Attached scsi generic sg3 type 0
sd 13:0:0:0: [sdd] 15663104 512-byte logical blocks: (8.01 GB/7.46 GiB)
sd 13:0:0:0: [sdd] Write Protect is off
sd 13:0:0:0: [sdd] Mode Sense: 03 00 00 00
sd 13:0:0:0: [sdd] No Caching mode page found
sd 13:0:0:0: [sdd] Assuming drive cache: write through
sd 13:0:0:0: [sdd] No Caching mode page found
sd 13:0:0:0: [sdd] Assuming drive cache: write through
 sdd: sdd1
sd 13:0:0:0: [sdd] No Caching mode page found
sd 13:0:0:0: [sdd] Assuming drive cache: write through
sd 13:0:0:0: [sdd] Attached SCSI removable disk
FAT-fs (sdd1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

If we take a look at the preceding messages, it is quite clear that on my PC, the device used is /dev/sdd. In fact, these lines tell me that the newly attached SCSI device (the microSD) has been assigned to the sdd device.


Depending on our system configuration, we may discover that the right device to use is /dev/sdb, /dev/sdc, and so on or even a device named as /dev/mmcblk0. In this last case, our host PC is using a MMC device instead of a USB adapter to manage the SD or microSD slot of the PC. In this special situation, the kernel messages look like:

mmc0: cannot verify signal voltage switch
mmc0: new ultra high speed SDR50 SDHC card at address 0007
mmcblk0: mmc0:0007 SD4GB 3.70 GiB
mmcblk0: p1

Once the right device has been discovered, we can proceed with the microSD creation:

# ./ --mmc /dev/sdd --dtb BeagleBone

The system will display a complete disk configuration asking for user confirmation; if we are sure about what we are doing, we've simply to answer yes and go on. At the end, we should see something like this:

Debug: image has: v3.16.0-armv7-x4
Debug: image has: v3.16.0-armv7-lpae-x2
Debug: image has: v3.8.13-bone63
Debug: using: v3.8.13-bone63
Finished populating rootfs Partition
----------------------------- script complete
The default user:password for this image:

Well, now we can remove the microSD from the host PC and put it in our BeagleBone Black. If everything has been done correctly, then after we reboot, we can log in to our new Debian system in the same way as we did during our first login earlier:

$ minicom -o -D /dev/ttyACM0


Note that this time, we have to wait a bit longer that the normal boot due to some configuration issues of this Debian image, which can delay the booting time. This fact will be more clear in the following chapter, where we will be able to see the serial console messages.

Then, as reported, at the end of the microSD creation stage, we must supply the debian user with the temppwd password (don't worry if no login prompt is displayed), as shown in the following code:

Last login: Wed Apr 23 20:21:01 UTC 2014 on ttyGS0
Linux BeagleBone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

The virtual machine

As stated at the beginning of this book, as a host system, I'm using a normal PC running Ubuntu 14.04 LTS distribution. Those who may wish to use another GNU/Linux-based OS can use most of the commands I'm going to use in the next chapter without any modifications (or with just a few differences, these can be replaced with a little effort). However, those who still insist on using a Windows- or Mac OS-based host system may have some troubles in following what I do, that's why I decided to write this little section/tutorial to help these people to install a GNU/Linux host system on their computers.

The trick to do our job is quite simple: we should use a virtual machine! Here, it is not so important to know which visualization system is used (my preference is for VirtualBox), the important thing is to install a GNU/Linux-based OS.

I will skip the instructions on how to install a new OS on a virtual machine since this is not the purpose of this book and because this operation is quite simple.

Setting up the host

Ok, now that our new GNU/Linux OS is running on our new virtual machine, we need to make some adjustments in order to use it as a real host PC.


All the commands are for Ubuntu 14.04 LTS. You should use the proper commands if you decide to install a different GNU/Linux distribution.

First of all, let's check the networking settings; we should verify that our system can access the Internet so that we can install all the needed tools.

The serial connection

To check whether we can get connected to our BeagleBone via the emulated serial port, as we did during our first login, we need to install the minicom tool:

bbb@bbb-VirtualBox:~$ sudo apt-get install minicom

After the installation is completed, verify that the virtual machine is connected to the USB host port, where the BeagleBone Black is connected by checking the kernel messages as done earlier:

cdc_acm 1-1:1.2: ttyACM0: USB ACM device

You should verify that the USB device corresponding to the BeagleBone Black is connected to the virtual machine. This action depends on the virtual machine implementation used, and it implies some actions taken by the user. For example, VirtualBox allows you to choose the serial port from a menu, otherwise it stays connected to the host. Great! The serial port is accessible, so let's use the minicom command:

bbb@bbb-VirtualBox:~$ sudo minicom -o -D /dev/ttyACM0


Note that on Ubuntu, an unprivileged user may need the sudo command to get access to the /dev/ttyACM0 device.

Also, we should verify that the serial connection settings are set, as during our first login, this is 115200,8N1, without both hardware and software flow controls.

The Ethernet connection

Now let's check the Ethernet connection emulated via the USB cable. Using the ifconfig command, we can check whether the Ethernet devices are up and running on both the host and target systems. On the host, we have the following:

bbb@bbb-VirtualBox:~$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 78:a5:04:ca:cb:00  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::7aa5:4ff:feca:cb00/64 Scope:Link
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:53 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:580 (580.0 B)  TX bytes:11465 (11.4 KB)

Depending on the virtual machine configuration, the Ethernet device ethX may vary, so we can use the ifconfig command without any arguments in order to get a list of all the networking devices present on the system. So, recalling what we did before, we should get connected to the target using the ssh command from the host system:

bbb@bbb-VirtualBox:~$ ssh [email protected]
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is b1:a9:84:39:71:99:a3:af:9e:ba:26:d5:e6:77:03:08.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
Debian GNU/Linux 7 BeagleBone Debian Image 2014-04-23

Last login: Wed Apr 23 20:20:26 2014

Ok, everything is working correctly!

The developing tools

In the end, the only tool that we need on the host is the C cross-compiler suite.

It can be installed using the following command on the newly created virtual machine:

$ sudo apt-get install gcc-arm-linux-gnueabihf make

Now we can try to compile the previous Hello World C example program on our new virtualized host PC:

$ make CC=arm-linux-gnueabihf-gcc CFLAGS="-Wall -O2" cross-helloworld
arm-linux-gnueabihf-gcc -Wall -O2    cross-helloworld.c   -o cross-helloworld


Note that now I've renamed the preceding Hello World program to cross-helloworld.c and the command line is quite different from before. The options of the make command are needed to select the cross-compiler and to use special compilation flags.

Now we can check whether the cross-compiler did its job correctly using the file command as follows:

bbb@bbb-VirtualBox:~$ file cross-helloworld
cross-helloworld: ELF 32-bit LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=5ea2036028d983438e38fc2df1a21d24d8fd7e59, not stripped

Yes, our cross-compiler is a good guy, but to be completely sure, we should test the code on our BeagleBone Black by copying the binary to it:

bbb@bbb-VirtualBox:~$ scp cross-helloworld [email protected]:
Debian GNU/Linux 7 BeagleBone Debian Image 2014-04-23

cross-helloworld                              100% 8357     8.2KB/s   00:00    

We will then execute it on the target:

bbb@bbb-VirtualBox:~$ ssh [email protected] ./cross-helloworld
Debian GNU/Linux 7 BeagleBone Debian Image 2014-04-23

Hello World!


In the last command, we used ssh to execute the cross-helloworld binary file on the remote machine to display the result on the local machine.

You can read more about this feature in the ssh user manual at