BBB Setup
The BBB comes with an image installed, but you'll want to flash a Debian image customized by Robert C. Nelson.
For a guide for creating a flash image on windows look here
- Download the latest flasher image. From that link, choose the most recent image.
daniel@daniel-u ~$ wget http://rcn-ee.net/deb/flasher/wheezy/BBB-eMMC-flasher-debian-7.3-2014-01-24-2gb.img.xz # Image may change
--2014-02-11 20:03:22-- http://rcn-ee.net/deb/flasher/wheezy/BBB-eMMC-flasher-debian-7.3-2014-01-24-2gb.img.xz
Resolving rcn-ee.net (rcn-ee.net)... 69.163.128.251
Connecting to rcn-ee.net (rcn-ee.net)|69.163.128.251|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 172707532 (165M) [text/plain]
Saving to: `BBB-eMMC-flasher-debian-7.3-2014-01-24-2gb.img.xz'
100%[==============================================================================================>] 172,707,532 5.85M/s in 64s
2014-02-11 20:04:27 (2.58 MB/s) - `BBB-eMMC-flasher-debian-7.3-2014-01-24-2gb.img.xz.1' saved [172707532/172707532]
- Plug a MicroSD card into your computer.
- Decompress the image.
daniel@daniel-u ~$ unxz -k BBB-eMMC-flasher-debian-7.3-2014-01-24-2gb.img.xz # Name may change
daniel@daniel-u ~$ ls -rclh | tail -n 1
-rw-rw-r-- 1 daniel daniel 1.7G Feb 11 20:09 BBB-eMMC-flasher-debian-7.3-2014-01-24-2gb.img
- Find the SD card.
daniel@daniel-u ~$ sudo fdisk -l
<...snip'd my other disks...>
Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
255 heads, 63 sectors/track, 1936 cylinders, total 31116288 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 31116287 15554048 c W95 FAT32 (LBA)
Note that you're looking for the disk, not the partition. So, in our case, the disk is /dev/mmcblk0 and the partition is /dev/mmcblk0p1. You can use the size given by fdisk to be sure that you're not choosing one of your drives (like the one that stores your OS!).
- Copy the image bitwise onto the SD card. Be careful with the output file name. This can wipe out your hard drive.
Note that BBB-eMMC-flasher-debian-7.3-2014-01-24-2gb.img is in my current working directory.
# Don't fuck this up. It can wipe out your HDD.
daniel@daniel-u ~$ sudo dd bs=1M if=BBB-eMMC-flasher-debian-7.3-2014-01-24-2gb.img of=/dev/mmcblk0
1700+0 records in
1700+0 records out
1782579200 bytes (1.8 GB) copied, 248.878 s, 7.2 MB/s
-
Wait 10 minutes or so until the image is copied onto the SD card.
-
Once you have the image on the SD card, remove the MicroSD card from its SD adapter and plug it into the BBB.
Now plug the BBB into your laptop using a MiniUSB cable, which will power the BBB.
- Wait 10 minutes or so until all 4 LEDs turn on and stay solid-on. The Debian image has now been flashed to the bone. Note that on the bone that's currently attached to the bot, the second LED from the outside (or second from the reset button, if that makes more sense), is burned out.
The bone should should accept SSH connections after a few minutes of boot time (even while the image is being copied from the SD to the BBB). It will appear as a network interface with network IP address 192.168.7.1.
daniel@daniel-u ~$ ifconfig
<...snip'd other interfaces...>
eth5 Link encap:Ethernet HWaddr 90:59:af:56:d2:b3
inet addr:192.168.7.1 Bcast:192.168.7.3 Mask:255.255.255.252
inet6 addr: fe80::9259:afff:fe56:d2b3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:40 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6493 (6.4 KB) TX bytes:10569 (10.5 KB)
<...snip'd other interfaces...>
Once this interface shows up, you can SSH into the bone and actually see the rsync process running (which is what's copying the SD image onto the bone's storage). If you get a scary looking warning about a man in the middle attack, run ssh-keygen -R 192.168.7.2 to clear it up. The root user's default password is root.
daniel@daniel-u ~$ ssh root@192.168.7.2
The authenticity of host '192.168.7.2 (192.168.7.2)' can't be established.
ECDSA key fingerprint is 75:82:ae:4f:44:37:e5:bb:c6:0f:8d:a8:cd:f3:7c:d7.
+--[ECDSA 256]---+
| . |
| . o |
| o = o |
| o o + . |
| S . |
| o o + |
| . . . * . .|
| o +.o o. E|
| o ooo... |
+-----------------+
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.
root@192.168.7.2's password:
Linux arm 3.8.13-bone37 #1 SMP Thu Jan 23 00:56:41 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.
root@arm:~# ps -ely | grep rsync
S 0 3260 2235 1 80 0 1292 1635 - ? 00:00:05 rsync
S 0 3261 3260 0 80 0 748 1445 - ? 00:00:00 rsync
D 0 3262 3261 8 80 0 996 1609 - ? 00:00:21 rsync
Once the LEDs stay solid-on, use your SSH connection to properly shutdown the bone (we don't know if this is necessary, but it seems like a reasonable idea).
root@arm:~# shutdown -hP now
Broadcast message from root@arm (pts/0) (Fri Jan 24 22:33:06 2014):
The system is going down for system halt NOW!
root@arm:~# Connection to 192.168.7.2 closed by remote host.
Connection to 192.168.7.2 closed.
daniel@daniel-u ~$
- At this point, you have Debian installed on the BBB's internal storage. Congrats!
Remove the MicroSD card from the bone.
Unplug the bone and the plug it back into your laptop, to power it and start it booting.
Note that during one setup, after doing this I had only a power light and no heartbeat lights. Unplugging the bone and plugging it back in yet again solved the problem.
- SSH into the BBB to confirm your new image:
daniel@daniel-u ~$ ssh root@192.168.7.2
Host key fingerprint is 75:82:ae:4f:44:37:e5:bb:c6:0f:8d:a8:cd:f3:7c:d7
+--[ECDSA 256]---+
| . |
| . o |
| o = o |
| o o + . |
| S . |
| o o + |
| . . . * . .|
| o +.o o. E|
| o ooo... |
+-----------------+
root@192.168.7.2's password:
Linux arm 3.8.13-bone37 #1 SMP Thu Jan 23 00:56:41 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.
Last login: Fri Jan 24 22:24:52 2014 from daniel-u.local
You may get this crazy-looking but no-big-deal warning:
daniel@daniel-u ~$ 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
75:82:ae:4f:44:37:e5:bb:c6:0f:8d:a8:cd:f3:7c:d7.
Please contact your system administrator.
Add correct host key in /home/daniel/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/daniel/.ssh/known_hosts:22
remove with: ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R 192.168.7.2
ECDSA host key for 192.168.7.2 has changed and you have requested strict checking.
Host key verification failed.
Fix it with the following command, which may even be helpfully provided in the warning message.
daniel@daniel-u ~$ ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R 192.168.7.2
/home/daniel/.ssh/known_hosts updated.
Original contents retained as /home/daniel/.ssh/known_hosts.old
Now that you're SSH'd in, confirm your Linux kernel. You'll see a newer version here, but the boneXX part should be similar.
root@arm:~# uname -r
3.8.13-bone37
At this point, you need to get network access.
You'll need to adjust these steps for the names of the network interfaces on your laptop. The two interfaces you care about are the one that's giving you Internet access and the USB one that's connected to the BBB. In my case, wlan0 is connected to the Internet and eth5 is the USB interface that's connected to the BBB. You can tell by the IP addresses of the interfaces - the BBB always uses the network 192.168.7.0/24 (eth5), and NCSU's wireless currently uses a subset of 10.0.0.0/8 (wlan0).
daniel@daniel-u ~$ ifconfig
eth0 Link encap:Ethernet HWaddr f0:de:f1:4f:c6:cf
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:20 Memory:f4b00000-f4b20000
eth5 Link encap:Ethernet HWaddr 90:59:af:56:d2:b3
inet addr:192.168.7.1 Bcast:192.168.7.3 Mask:255.255.255.252
inet6 addr: fe80::9259:afff:fe56:d2b3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:129 errors:0 dropped:0 overruns:0 frame:0
TX packets:164 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17248 (17.2 KB) TX bytes:28515 (28.5 KB)
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:6453 errors:0 dropped:0 overruns:0 frame:0
TX packets:6453 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:899133 (899.1 KB) TX bytes:899133 (899.1 KB)
wlan0 Link encap:Ethernet HWaddr 00:24:d7:a6:89:b4
inet addr:10.139.65.167 Bcast:10.139.71.255 Mask:255.255.248.0
inet6 addr: fe80::224:d7ff:fea6:89b4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2581896 errors:0 dropped:0 overruns:0 frame:0
TX packets:1124068 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3500943560 (3.5 GB) TX bytes:236877086 (236.8 MB)
In the following commands, replace wlan0 with the interface on your system that's connected to the Internet and eth5 with the interface that's connected to the bone. Note that in one install, these didn't work with a fairly standard Fedora 20 install, but did after booting back into Ubuntu 12.04. There's likely a little more work that needs to be done to these rules for them work in Fedora, but no one has looked into it.
[EDIT : After looking into the Fedora 20 install]: So to get this working in Fedora, go to the Firewall Settings page (search for firewall and it should show up). After getting to this page, click on the Interfaces tab. Once there you should see a couple of menu options including public and trusted. Under the public settings you should see your internet connection interface (wlan0 in this case) and the interface connected to the bone (eth5 in this case). Now move eth5 from the public list, to the trusted list (Make sure its in the trusted list before you quit.) After these steps it should work.
daniel@daniel-u ~$ sudo -i # You need to be root for all of these commands
[sudo] password for daniel:
root@daniel-u ~$ echo 1 > /proc/sys/net/ipv4/ip_forward
root@daniel-u ~$ iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
root@daniel-u ~$ iptables -A FORWARD -i wlan0 -o eth5 -m state --state RELATED,ESTABLISHED -j ACCEPT
root@daniel-u ~$ iptables -A FORWARD -i eth5 -o wlan0 -j ACCEPT
Now on the bone, issue the following commands.
root@arm:~# route add default gw 192.168.7.1
root@arm:~# echo "nameserver 8.8.8.8" > /etc/resolv.conf
You should now be able to ping IP addresses as well as domain names that require resolving from the bone.
root@arm:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=45 time=24.6 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=45 time=23.4 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 23.474/24.082/24.690/0.608 ms
root@arm:~# ping www.google.com
PING www.google.com (74.125.196.103) 56(84) bytes of data.
64 bytes from yk-in-f103.1e100.net (74.125.196.103): icmp_req=1 ttl=41 time=24.4 ms
64 bytes from yk-in-f103.1e100.net (74.125.196.103): icmp_req=2 ttl=41 time=23.6 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 23.670/24.066/24.462/0.396 ms
(execute the following commands while sshd into your beaglebone)
After plugging in your WNIC, type `ifconfig -a`.
wlan0 should show up on that list.
open the file that configures your wireless adapters.
```
vim /etc/network/interfaces
```
You will see a section of code that looks like this:
```
# WiFi Example
#auto wlan1
#iface wlan1 inet dhcp
#wireless-essid ncsu
#wireless-mode managed
```
Uncomment the lines after WIFI example and enter the information for the network you are trying to connect to.
Jeff scripted this amazingly well, so it's now remarkably easy.
To get the necessary files, pull the IEEERobotics/bot2014 repo to your local system.
Navigate to bot2014/setup/. There's a script there called setup_bone.sh, which basically sets up everything on a bone. The bone should have network access, as described in the previous section.
If the bone is connected to your laptop via USB, as is likely the case if you followed the above guide, you can run ./setup_bone.sh -u. To install additional packages, add the -a flag. If this bone is going to actually run the bot, add the -b flag.
[~bot/setup]$ ./setup_bone.sh -h
Help
-a Install additional packages: vim-nox ipython tmux screen nmap tree build-essential python-dev i2c-tools wireless-tools grc
-u Initiate install over USB
-b Perform bot-specific setup (networking, etc)
This step isn't required, but it's nice to do as it speeds up future logins.
If you don't already have an SSH key (public key ~/.ssh/id_rsa.pub and private key ~/.ssh/id_rsa), generate one with ssh-keygen. For this use, I suggest not using a password, as security really isn't a factor.
Once you have a key, use ssh-copy-id to add your public key info to the bot's ~/.ssh/authorized_keys file:
[~]$ ssh-copy-id root@192.168.7.2
Host key fingerprint is 90:88:f5:89:70:58:fe:82:48:a2:17:31:68:7a:55:2c
+--[ECDSA 256]---+
| .+o+o. |
|...OE+.o |
|+.o.+.= |
|=..o . . |
|o.o . . S |
| . . |
| |
| |
| |
+-----------------+
root@192.168.7.2's password:
Now try logging into the machine, with "ssh 'root@192.168.7.2'", and check in:
~/.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
You can now login without a password.