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.
Tip
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 http://ynezz.ibawizard.net/beagleboard/wheezy/.
The command to download the file is as follows:
$ wget http://ynezz.ibawizard.net/beagleboard/wheezy/debian-7.6-console-armhf-2014-08-13.tar.xz
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.
The command to build the microSD is as follows:
# ./setup_sdcard.sh --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.
Tip
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:
# ./setup_sdcard.sh --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 ----------------------------- setup_sdcard.sh script complete ----------------------------- The default user:password for this image: debian:temppwd -----------------------------
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
Tip
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:
debian Password: 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. debian@BeagleBone:~$
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.
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.
Tip
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.
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
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:192.168.7.1 Bcast:192.168.7.3 Mask:255.255.255.252 inet6 addr: fe80::7aa5:4ff:feca:cb00/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 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 '192.168.7.2 (192.168.7.2)' 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 '192.168.7.2' (ECDSA) to the list of known hosts. Debian GNU/Linux 7 BeagleBoard.org BeagleBone Debian Image 2014-04-23 Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian Last login: Wed Apr 23 20:20:26 2014 root@BeagleBone:~#
Ok, everything is working correctly!
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
Tip
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 BeagleBoard.org BeagleBone Debian Image 2014-04-23 Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian 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 BeagleBoard.org BeagleBone Debian Image 2014-04-23 Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian Hello World!
Tip
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 http://www.openssh.com/manual.html.