Difference between revisions of "BeagleBone Black"

From Klaus' wiki
Jump to: navigation, search
(First Boot)
(Add a WiFi adapter)
Line 3: Line 3:
 
At [[BBB First Boot]] you can read about the first boot of the BeagleBone Black
 
At [[BBB First Boot]] you can read about the first boot of the BeagleBone Black
  
=Add a WiFi adapter=
+
Adding a WiFi adapter [[BBB WiFi]]
 
+
=Yocto Project=
If you are going to add a WiFi adapter you should search eBay or Alibaba for a Realtek RTL8188CUS or similar adapter. They will usually work right out of the box without any external power.
+
 
+
Plug in the adapter into the USB interface.
+
 
+
Issue
+
<source lang=bash>
+
]$ lsusb
+
</source>
+
 
+
expect a result like this
+
root@beaglebone:~# lsusb
+
Bus 001 Device 002: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
+
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+
Next issue
+
<source lang=bash>
+
root@beaglebone:~# ifconfig -a
+
</source>
+
expect something like this output
+
eth0      Link encap:Ethernet  HWaddr 1c:ba:8c:e7:40:03 
+
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+
          collisions:0 txqueuelen:1000
+
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
          Interrupt:40
+
+
lo        Link encap:Local Loopback 
+
          inet addr:127.0.0.1  Mask:255.0.0.0
+
          inet6 addr: ::1/128 Scope:Host
+
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
+
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
+
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+
          collisions:0 txqueuelen:0
+
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
+
usb0      Link encap:Ethernet  HWaddr f6:7f:36:73:b5:93 
+
          inet addr:192.168.7.2  Bcast:192.168.7.3  Mask:255.255.255.252
+
          inet6 addr: fe80::f47f:36ff:fe73:b593/64 Scope:Link
+
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
+
          RX packets:774 errors:0 dropped:0 overruns:0 frame:0
+
          TX packets:540 errors:0 dropped:0 overruns:0 carrier:0
+
          collisions:0 txqueuelen:1000
+
          RX bytes:62696 (61.2 KiB)  TX bytes:94951 (92.7 KiB)
+
+
wlan0    Link encap:Ethernet  HWaddr 00:13:ef:20:06:33 
+
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
+
          RX packets:0 errors:0 dropped:5 overruns:0 frame:0
+
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
+
          collisions:0 txqueuelen:1000
+
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
+
 
+
From this we can see that the WiFi adapter was recognised by the Linux OS and given the device name '''wlan0'''.
+
 
+
In order to have the wiFi to auto connect at boot time issue
+
<source lang=bash>
+
root@beaglebone:~# vi /etc/network/interfaces
+
</source>
+
In this file uncomment the lines following the #WiFi example
+
 
+
auto wlan0
+
iface wlan0 inet dhcp
+
    wpa-ssid "YourSSID"
+
    wpa-psk  "YourVerySecretPassword"
+
 
+
save the file and execute this command
+
<source lang=bash>
+
]$ ifconfig wlan0 up
+
</source>
+
This will start the wlano, but nothing is output for your information.
+
 
+
Issue
+
<source lang=bash>
+
]$ ifup wlan0
+
</source>
+
This will give you an output like the one shown below
+
ioctl[SIOCSIWAP]: Operation not permitted
+
ioctl[SIOCSIWENCODEEXT]: Invalid argument
+
ioctl[SIOCSIWENCODEEXT]: Invalid argument
+
Internet Systems Consortium DHCP Client 4.2.2
+
Copyright 2004-2011 Internet Systems Consortium.
+
All rights reserved.
+
For info, please visit https://www.isc.org/software/dhcp/
+
+
Listening on LPF/wlan0/00:NN:NN:NN:NN:NN
+
Sending on  LPF/wlan0/00:NN:NN:NN:NN:NN
+
Sending on  Socket/fallback
+
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
+
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 12
+
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
+
DHCPOFFER from 192.168.10.1
+
DHCPACK from 192.168.10.1
+
bound to 192.168.10.110 -- renewal in 35998 seconds.
+
 
+
You have got a new IP address for the WiFi interface. Note it, most accesspoints re-issue the same IP address if the device reconnects frequently - otherwise it may be an idea to consult the accesspoint to see if it is possible to configure that a specific MAC addresse is connected to a specific IP addresse often it is possible.
+
 
+
Now in order to check if the WiFi comes up automagically after a reboot perform a reboot of the system.
+
 
+
Sometime my BBB does not get an IP address. After digging into the log files I found that the driver does not always get the device ready for DHCP'ing in time.
+
 
+
I stumbled upon this on [https://learn.adafruit.com/setting-up-wifi-with-beaglebone-black/configuration AdaFruit].
+
 
+
<source lang=bash>
+
]$ apt-get update && apt-get install git
+
]$ git clone https://github.com/adafruit/wifi-reset.git
+
]$ cd wifi-reset
+
]$ chmod +x install.sh
+
]$ ./install.sh
+
</source>
+
 
+
after installing this the BBB always come up on WiFi - but sometimes it takes minutes to get everything registered and running.
+
 
+
Sometimes this is enough, so I improved the wifi-reset.sh script and run it every five minutes from cron. So now the waiting time is no more than five minutes.
+
 
+
The improved script look like this
+
<source lang=bash>
+
#!/bin/bash
+
# Bring all wifi interfaces down.
+
# Identify wifi interfaces as rows from standard output of iwconfig (NOT standard
+
# error, those are non-wifi interfaces) which start without whitespace.
+
ASSOC=`iwconfig wlan0|grep -o "Not-Associated"`
+
while [ ! -z ${ASSOC} ]; do
+
        echo "Running wlan setup"
+
        iwconfig 2> /dev/null | grep -o '^[[:alnum:]]\+' | while read x; do ifdown $x; done
+
        # Bring all wifi interfaces up.
+
        iwconfig 2> /dev/null | grep -o '^[[:alnum:]]\+' | while read x; do ifup $x; done
+
        sleep 30
+
        ASSOC=`iwconfig wlan0|grep -o "Not-Associated"`
+
done
+
</source>
+
the script looks for the phrase "Not-Associated" in the output from iwconfig. If there is no association with an accesspoint we will reset all the wlans and after that enable them once again. The script will loop every thirty seconds  until we get an association with an accesspoint.
+
 
+
In cron add this line
+
#m h dom mon dow user  command
+
/5  *    * * *  root  /opt/wifi-reset/wifi-reset.sh
+
which will cause cron to execute the script every five minutes. It can probably run more often if needed but this works for me and i OK.
+
 
+
==Yocto Project==
+
 
+
 
The Yocto Project, see the [http://yoctoproject.org/ home page] for further details, can create a distribution for the BBB.
 
The Yocto Project, see the [http://yoctoproject.org/ home page] for further details, can create a distribution for the BBB.
  
 
For instructions on how to build a personal Yocto Project Distribution see [[Yocto Project Build Instructions]].
 
For instructions on how to build a personal Yocto Project Distribution see [[Yocto Project Build Instructions]].
  
===Creating the boot SD===
+
==Creating the boot SD==
  
 
There are several methods to create a bootable SD card.
 
There are several methods to create a bootable SD card.

Revision as of 07:40, 2 May 2015

Find below my experiences with the BeagleBone Black (BBB) revision 3.

At BBB First Boot you can read about the first boot of the BeagleBone Black

Adding a WiFi adapter BBB WiFi

Yocto Project

The Yocto Project, see the home page for further details, can create a distribution for the BBB.

For instructions on how to build a personal Yocto Project Distribution see Yocto Project Build Instructions.

Creating the boot SD

There are several methods to create a bootable SD card.

The easiest way is to use a graphical interface, e.g. gparted

Gparted.png

Create two partitions, one size 40, or more, megabytes for u-boot and one for the rest of the SD card - here 7+ GB.

Label the boot partition boot and the other partition root.

The boot partition shall be a primary partition of type FAT32 while the rest is a ext3 or ext4 file system. Format the partitions to the designated file system types and set the boot flag for the boot partition.

Alternative method

Here is an alternative method only using the console if no graphical environment is available:

 
$ export DISK=/dev/sdc
$ umount ${DISK}1
 #<<<Note the addition of the '1'
$ sudo dd if=/dev/zero of=${DISK} bs=512 count=20
$ sudo sfdisk --in-order --Linux --unit M ${DISK} <<-__EOF__
1,12,0xE,*
,,,-
__EOF__
$ sudo mkfs.vfat -F 16 ${DISK}1 -n boot
$ sudo mkfs.ext4 ${DISK}2 -L rootfs

Here's whats happening:

  • Provided that the newly inserted SD card is /dev/sdc - could be another e.g. sdb depending on the disks in the PC - tell the rest of the script where the device is located (the DISK variable)
  • unmount if automount mounted it
  • dd is a very effective utility to create files and much more - here zeros is copied from /dev/zero (if=/dev/zero) to the disk (of=${DISK} i.e. /dev/sdc) with 512 bytes block size (bs=512) for 20 blocks (count=20)
  • Next rather than calling the fdisk the sfdisk partition table manipulating program is used with a HERE script (the part from __EOF__ to __EOF__)
  • With the partition the next is to make a file system with mkfs both vfat and ext4 file systems and at the same time labelling the partitions

Transfer binaries to the SD card

Mount the two SD card partitions. On some Linuxes it is easily done by removing the SD card and reinsert it and automount will automagically mount the disk partitions.

From the Yocto Project distribution copy the MLO and the u-boot.img files to the boot partition.

In order to populate the root file system to the root partition untar the compressed root file system that bitbake produced.

$ cd <the mounted root partition>
$ sudo tar xf <path to poky>/beaglebone/tmp/deploy/images/beaglebone/core-image-sato-beaglebone.tar.bz2 .
$ sync

This is what is happening:

  • First change to the root partition on the SD card (on Fedora it is typically mounted /run/media/<username>/root)
  • Then untar the compressed root file system from where bitbake built it (here it is the graphical core-image-sato distribution)
  • Finally issue sync to let the kernel write everything to the SD card - when sync returns unmount the SD card.

Windows and Mac users

You will have to figure out from the descriptions above how to format and create the filesystems on the SD card and how to copy the files to the card.

Booting the BBB with Yocto Project

Insert the SD card into the slot for it on the BBB. Press and hold the button on top of the board near the SD card in order to boot from the SD (otherwise the BBB will boot from the built in eMMC). Apply power through the USB connector.

Monitor the boot process

Only if the u-boot causes problems a serial connection may be helpful, otherwise it is usually enough to wait until the USB interface becomes available in the boot process.

So if the u-boot messages should not be monitored, just connect the USB cable to the PC and start the favourite serial communication program, e.g. CuteCom, Putty or screen. Wait until the tty USB device becomes available. The USB interface will become available when the system is near the end of the boot process - and at that time the u-boot messages are long gone.

If, for some reason, the board won't boot, a serial cable need to be connected to the board. Get a PL2303 cable - or build one your self...

Connect the serial cable to the port to J1 as shown below.

RPI Serial.png

PL2303 USB to serial cable

 Board       Wire    Function
 Pin 1.....Black.....Ground

 Pin 4.....Green.....Receive

 Pin 5.....White....Transmit
 (Where pin 1 is the one near the white dot)

Serial2BBB.png

Connecting the pl2303 cable to the BeagleBone Black

Stop u-boot

Using a serial interface it is possible to monitor the boot process.

Here the command

$ screen /dev/ttyUSB0 115200

is used to connect to the serial line (use Ctrl-a+k to kill the window). Putty or CuteCom can show the same.

Immediately after applying power and e-boot presents it self on the serial interface, hit any key on the keyboard to stop the boot process.

This is a typical output from the early boot process:

U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)

I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

Net:   <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0 
U-Boot#

Here the u-boot has stopped and are awaiting a command.

Enabling the DS18B20 thermometer

The version of Debian that my board was supplied with uses the Flattened Device Tree in order to ease the access to GPIO's and other hardware. This are so for the most modern Linux distributions for the ARM processors. The reason for this is mainly because Linus Thorvalds did not want to include the large amount of device drivers for the ARM processor family in the kernel. Se more about the Flattened Device Tree (FDT) on this site.

From this site I was inspired to set-up the correct dts file enabling the usage of GPIO pin 2 for the 1Wire interface.

Create a file name DS1820-00A0.dts with this content

/dts-v1/;
/plugin/;
 
/ {
    compatible = "ti,beaglebone", "ti,beaglebone-black";
    part-number = "DS1820";
    version = "00A0";
 
    exclusive-use = "P9.12";
 
    fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
             ds1820_pins: pinmux_ds1820_pins {
                 pinctrl-single,pins =  <0x78 0x37>;
             };
        };
    };
 
    fragment@1 {
        target = <&ocp>;
        __overlay__ {
            onewire@0 {
                status          = "okay";
                compatible      = "w1-gpio";
                pinctrl-names   = "default";
                pinctrl-0       = <&ds1820_pins>;
                gpios           = <&gpio2 28 0>;
            };
        };
    };
};

Compile the specification into a dtbo binary file

dtc -O dtb -o /lib/firmware/DS1820-00A0.dtbo -b 0 -@ DS1820-00A0.dts

Finally in order to enable this part of the device tree perform at every boot this command

echo DS1820 > /sys/devices/bone_capemgr.*/slots

The thermometer should now show up in the /sys/bus/w1/devices folder

drwxr-xr-x 2 root root 0 Jan  1  2000 .
drwxr-xr-x 4 root root 0 Jan  1  2000 ..
lrwxrwxrwx 1 root root 0 Feb 21 10:49 28-000005a7ce64 -> ../../../devices/w1_bus_master1/28-000005a7ce64
lrwxrwxrwx 1 root root 0 Feb 21 10:49 w1_bus_master1 -> ../../../devices/w1_bus_master1

the 28-00000nnnnnnn is the thermometer - they are all uniquely identified, so the n's will vary.

Test with Python

To check that the thermometer work correct prepare this short test program in a file named test.py where you of course will adjust the thermometer ID to suit your set-up:

import time
 
w1="/sys/bus/w1/devices/28-000005a7ce64/w1_slave"
 
while True:
    raw = open(w1, "r").read()
    print "Temperature is "+str(float(raw.split("t=")[-1])/1000)+" degrees"
    time.sleep(1)

Execute the program

python test.py

you should get something similar to this

root@klaus-BBB:~/ds18b20# python test.py 
Temperature is 24.0 degrees
Temperature is 24.0 degrees
Temperature is 24.062 degrees
Temperature is 24.062 degrees
^CTraceback (most recent call last):
  File "test.py", line 8, in <module>
    time.sleep(1)
KeyboardInterrupt
root@klaus-BBB:~/ds18b20#

Test using Bonescript

This source first locates the attached thermometer and then uses it for temperature reading.

This code is only able to handle one thermometer at a time, or in fact only one 1-wire device at at time.

// 
// Interface for the thermometer
// Author   : Klaus Kolle
// Date     : 2015 02 22
// Revision : 0.0.3
 
var b = require('bonescript');
var f = require('fs');
 
//console.log('Hello, Thermostate.');
 
var temperature;
 
// Read from the 1-wire thermometer
// The 28-00000nnnnnnn will change depending of the device connected
// 
var oneWireDir;
 
locateThermometer();
 
function locateThermometer()
{
  var initialDir = '/sys/bus/w1/devices/';
  var regExpr = '28-00000';
  var dir = [];
  var i;
  // Get all files and directories in the dir
  var dirs = f.readdirSync(initialDir);
  // Did we gat anything - if not the cape manager is probably not initialised
  // with the dtbo compiled device tree
  if (dirs.length > 0)
  {
    for (i = 0; i < dirs.length; i++)
    {
      // Only select the directories matching the pattern
      if(dirs[i].match(regExpr))
      {
        dir.push (dirs[i]);
      }
    }
    // Currently the code only accepts one thermometer
    oneWireDir = initialDir + dir + "/w1_slave";
  }
}
 
function readTemp() 
{
  // Callback function for the timer
  b.readTextFile(oneWireDir, printTemp);
}
 
// The 1-wire returs this when reading the device
// klaus@klaus-BBB:~$ cat /sys/bus/w1/devices/28-000005a7ce64/w1_slave 
// a5 01 4b 46 7f ff 0b 10 f7 : crc=f7 YES
// a5 01 4b 46 7f ff 0b 10 f7 t=26312
// Therefore a split is needed. We need the string after the second =
 
function printTemp(x) 
{
  // We receive the data i x
  if (x.data != '')
  {
    var stringToSplit = x.data;
    // Split at = - three resulting strings are returned
    var arrayOfStrings = stringToSplit.split('=');
    // We are only interesd in the last
    temperature = (arrayOfStrings[2]) / 1000;
    console.log("Temp: " + temperature);
  }
}
 
setInterval(readTemp, 5000);

Expect a readout like this

Temp: 24.687
Temp: 24.75
Temp: 24.75
Temp: 24.687
Temp: 24.75
Temp: 24.75
Temp: 24.75
Temp: 24.687

Development on a PC host and remote debugging

A few things are needed in order to set-up development of programs, that shall execute on an ARM platform. You'll need a cross compiler - a compiler that can generate ARM executable code while the compiler is executed on the PC platform, which is typically a Intel X86_64 architecture.

Cross Compiler

The Fedora package system does not contain a suitable compiler for the ARMv7 processor.

Luckily Linaro, does maintain a toolchain suitable for us. At this point you can find the newest binaries for your operating system. Go up the directory structure to discover if a newer compiler has been released.

The following is suited for Fedora Linux and other Linux'es as they are rather generic.

]$ cd ~/Downloads
$] wget http://releases.linaro.org/14.11/components/toolchain/binaries/arm-linux-gnueabihf/gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.tar.xz

which will download the newest version on the time of writing this.

I keep downloaded tools in the /opt directory rather than in the /usr/local or other places in the /usr tree.

]$ cd /opt
]$ mkdir toolchains
]$ cd toolchains
]$ tar Jxvf ~/Downloads/gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.tar.xz
]$ ln -s gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf/ gnueabihf
]$ file gnueabihf/bin/arm-linux-gnueabihf-gcc

These commands will create a toolchains directory in /opt and unpack the downloaded binaries into a structure. A symbolic link gnueabihf is created. This link can later be changed if a newer version of the compiler and libraries are downloaded.

The last command is just for ensuring that you've got the correct package downloaded. Expect something like this:

[klaus@klaus-x230 bin]$ file arm-linux-gnueabihf-gcc
arm-linux-gnueabihf-gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter 
/lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=71722376ff3af9eee5caf7bdfa2ecc350db0a590, not stripped
[klaus@klaus-x230 bin]$ 

Develop a Cross Compiled Program

Start Eclipse and create a new project:

RemoteDebugging.png

Notice the settings for the Cross GCC

On one of the next dialogues you have to specify what the prefix for the cross compiler tools are and where they resides.

RemoteDebugging1.png

In the project create a new C source file and fill in some "Hello World" stuff.

Save and compile (Ctrl+S, Ctrl+B).

In a console go to <path to your project>/Debug

]$ file <your binary (project name)>

Expect something like this:

[klaus@klaus-x230 Debug]$ file TestRemoteDBG 
TestRemoteDBG: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, 
interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.16, BuildID[sha1]=e8baff7637d637533f3730021407ffdc6d4c314e, not stripped
[klaus@klaus-x230 Debug]$ 

This tells us that the compiler has produced ARM executable code.

Remote Debugging

In order to be able to debug remote the remote board needs a suitable gdbserver. There is one already onboard - or it can be downloaded using apt-get, but that one does not operate correct with the toolchain downloaded previously.

But luckily there is a suitable gdbserver included with the gnueabihf tools.

]$ scp /opt/gnueabihf/bin/gdbserver <username>@<your BBB IP>:~/

If you set-up password-less login over SSH (see this page for details) your life will be much easier.

You can test your newly developed ARM program on your BBB.

]$ scp <path to your project>/Debug/<yourbinary> <username>@<Your BBB IP address>:~

Log on to your BBB and try

]$ ./<yourbinary>

and inspect the output.

Next thing is to set up remote debugging.

In Eclipse select the Run menu and select Debug Configurations

RemoteDebugging2.png

First mark the C/C++ Remote debugging and then click on the new button to the upper left corner of the dialogue.

You'll get a dialogue like this:

RemoteDebugging3.png

Press the New button to the right of the Connection line.

This will open a dialogue for setting up the connection to the BBB. We'll use SSH.

RemoteDebugging4.png

You can use the local IP address or any other configured for the BBB.

RemoteDebugging5.png

Returning to the main Debug Configuration dialogue you'll see that the Connection now has been filled in with the details you just provided.

RemoteDebugging6.png

Next you'll have to specify the complete path of your program to execute on the BBB. The program will be sent over the SSH connection before launching the gdbserver - so any changes made on the development host will be reflected on the binary on the BBB.

Here I just placed the binary in my home directory, but it could be anywhere suitable.

RemoteDebugging7.png

Next thing to do is to click on the Debugger tab in the top of the dialogue. In this part of the settings you'll have to specify a complete path and name of the debugger - in this case we'll use the Linaro supplied residing in /opt/toolchains/gnueabihf

RemoteDebugging8.png

Also click on the Shared libraries tab and click Add and navigate to /opt/toolchains/gnueabihf/libc/lib and add that. This will remove some error messages during debugging.

RemoteDebugging16.png

Adjust the path to the gdbserver on the BBB.

RemoteDebugging15.png

You are now ready to debug. Press the Debug button.

RemoteDebugging9.png

You're asked a password for your login on the BBB.

RemoteDebugging10.png

And the you're told what system you're debugging.

RemoteDebugging11.png

And finally the debugger launches the program that has been transfered to the remote BBB and the gdbserver is launched with the program a a parameter and you can debug you application just like any other application.

This set-up has been heavily inspired by this site and the video by D. Molloy at YouTube.

Installing a new official Debian image on a SD card

Download from the BeagleBoard.org site or elsewhere a fresh image suitable for the BBB.

You will typically get a file named like this

bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz

Date and version number may vary.

In your download directory execute this command

]$ xz -dk bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz

this will unpack the image into a file like this

bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img

Locate your SD card

Have a 4GB SD ready and inserted into your computer. Execute

]$ ll /dev/sd*

or

]$ ll /dev/mmcblk*

the way your computer interface to the SD card will either see it as a disk drive and name it /dev/sdN, where N is the next free letter - e.g. you have one disk already installed in your computer it is most likely sda[09], the next disk the system recognises will be sdb.

On my laptop when I use the SD slot directly in the laptop the system sees the SD card as a new mmc block device, hence the mmcblk name.

Another way to determine the name of the freshly inserted SD card is to execute

]$ ls -lart /dev

this will list the content of /dev in reverse order with the newest at the end of the list, i.e. at the bottom of your console.

Removing the SD card and rerunning the command will give you the final evidence to what the name is, since it is now missing in the list.

If the SD card i preformatted, which most are, you will see two - or more - devices like this

]$ ll /dev/mmcblk*
brw-rw----. 1 root disk 179, 0 May  1 13:15 /dev/mmcblk0
brw-rw----. 1 root disk 179, 1 May  1 13:15 /dev/mmcblk0p1
]$

The mmcblk0 is the main block device and the mmcblk0p1 is the first partition on the disk.

Transferring the image to the SD card

In order to transfer the disk image to the SD card first ensure that it is not mounted, e.g. by removing the card and re-insert it into the reader slot or by running a umount command (RTFM umount).

Next issue this command

]$ sudo dd if=bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img of=/dev/mmcblk0 bs=1M

The dd command is a versatile utility that takes an input file (if) and an output file (of) and copies the input file to the output file (/dev/mmcblk0) in 1 mega bytes blocks (BS=1M). Expect 10 to 20 minutes before the command returns depending on the speed of your card reader and the SD card. Note here, that we use the main block interface file mmcblk0 not the mmcblk0p1 or the sdb not the sdb1.

When finished you will get a report like this

3700+0 records in
3700+0 records out
3879731200 bytes (3.9 GB) copied, 557.971 s, 7.0 MB/s

and your SD is ready to run in the BBB.

Starting the new image on BBB

Remove the SD card from your computer and insert it into the BBB.

Find the user button located just above the SD card slot.

Press and hold the button while applying power to the device. When the device starts to boot (blinking leds) release the user button.

If you have previously connected your BBB using the

]$ ssh root@192.168.7.2

you will probably get a message like this

]$ ssh root@192.168.7.2
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
80:98:39:60:af:8e:db:14:47:9f:76:6a:88:89:12:e3.
Please contact your system administrator.
Add correct host key in /home/klaus/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/klaus/.ssh/known_hosts:49
ECDSA host key for 192.168.7.2 has changed and you have requested strict checking.
Host key verification failed.

which tells us that in the ~/.ssh/known_hosts file we keep a fingerprint of hosts that we have previously accepted to be legal computers to connect to. You have to edit the ~/.ssh/known_hosts file and remode the line(s) beginning with 192.168.7.2 and then try to connect once again.

First time you connect to your new image you will be prompted to verify the fingerprint of the connecion. Do that by typing yes.

Determine the version of your new image by issuing this command

root@beaglebone:~# uname -a
Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015 armv7l GNU/Linux
root@beaglebone:~#

This is at the time of wirting the latest official supported image, but not necessarily the newest - you may find newer images floating around the Internet. The following device driver development will take outspring in the version.

Developing a device driver for the BBB

This section is heavily inspired by Derek Molloy's fine writing about device driver development.