Obervations from playing around with a Beaglebone Black

I've toyed around with a Beaglebone Black for some days, evaluating its usefulness as a living room box. (Long story short: It's unusable for that, because it can drive only up to 720p due to pixel clock limits, lack of hardware video decoding support and lack of practical [1] 3D acceleration).

(Long-term note: This describes the state of things around 2016-06-28. In some months, this is hopefully only historically relevant, and might be shortened.)

Nevertheless, I've learned some things:

Serial Debugging is easy to connect once you have a 3.3V USB UART -- the USB UART's GND goes to J1, RX goes to J5 and TX goes to J4, where J1..6 is the pin header next to the socket bar between USB host and 5V, and only J1 is labelled.

Except for debugging, it is not really required, though; for most of what is described on the rest of this page, one can do without.
The beaglebone by default executes the U-Boot loader stored on the internal flash memory (eMMC); pressing the boot select button S2 during powerup (reset doesn't count) alters the boot sequence to skip that. This first stage of the booting process is goverened by a program in ROM that I haven't seen anyone try to manipulate yet. (Also, why should one -- it behaves sanely and not touching it makes the device unbrickable for all I can tell).
- When trying to boot from an MMC device (either the builtin eMMC called mmc0 or the microSD card called mmc1; eMMC and SD cards are rather exchangable as far as the CPU is concerned), the startup code (SPL/MLO (see later), U-Boot, U-Boot config) may either reside on the first and FAT formated partition, or at some fixed offsets between the partition table and the first partition. (So if you wind up with arguments in the kernel cmdline you fail to find in the mounted image, have a look at the intermediate space with a hex editor).
- Failing that (eg. because no microSD card is inserted and S2 was pressed), the ROM fires up an Ethernet interface via the USB gadget side (ie. when the mini-USB port is connected to a PC, a new USB network card appears there) and asks for the SPL/MLO via bootp.
The Alexander Holler's boot explaination image visualises this well.

Both the MMC and the USB networking boot flow take an intermediate step (the secondary program loader, SPL; file name MLO) before loading full U-Boot (file name u-boot.img or similar). The SPL is actually a U-Boot itself, just stripped down to run from on-board RAM; it then initializes the rest of the RAM and loads the fully configured U-Boot (with debug prompt and device support for everything else) to continue.
It is possible to do the entire flashing without possession of a microSD card, but it's not a widespread way of operation and thus you might encounter some bugs.

The following workflow shows how to flash the provided Debian image right into eMMC.
- Obtain a copy of the compressed image file from the latest-images page.
- Get a copy of the spl, uboot and fit files from the BBBlfs bin/ directory. (There's a copy inside the image at partition 1 in /opt/source/BBBlfs, that should work as well and can be extracted using kpartx and loop mounting). Rename fit to itb because that's the file name needed later.
- Prepare a DHCP server for the incoming USB connections. I generally find it practical to have a device independent Ethernet setting which I call "I am a WiFi adapter" in NetworkManager, which is configured to have IPv4 "Shared to other computers" -- setting that to "automatically connect to this network when it is available" for the time of playing around is one of the easiest ways to get a DHCP server running.
- Tell the server to ship the required images by creating a /etc/NetworkManager/dnsmasq-shared.d/spl-uboot-fit.conf file, which modern NetworkManager versions include to every started DHCP server, or include the sniplet into your dnsmasq config if you start it manually:
```
bootp-dynamic
enable-tftp
tftp-root=/where/you/stored/last/steps/files
dhcp-vendorclass=set:want-spl,AM335x ROM
dhcp-vendorclass=set:want-uboot,AM335x U-Boot SPL
dhcp-boot=tag:want-spl,/spl
dhcp-boot=tag:want-uboot,/uboot
```
  This will serve the right file at the right time.
- Wire up the BeagleBone's mini-USB to your workstation and keep S2 pressed while plugging in. You should see NetworkManager take the interface up and set it to "I am a WiFi adapter" (or manually do that if you didn't configure autoconnect).
  
  If the connection fails to come up / disappears, check your NetworkManager log files (eg. at /var/log/daemon.log); chances are that dnsmasq does not come up because it can't access the TFTP root path. If it does come up, it should disappear again soon afterwards, and you should see a line like
```
dnsmasq-tftp[...]: sent /some/path/bin/spl to 10.42.0.x
```
  which indikates that the first stage loader asked as expected and got its response. Following that, a new USB network interface should appear, and you should see the same line just with uboot instead of spl. (Without autoconnect, you'd have to nudge NetworkManager again).
- Due to what I consider a bug in BBBlfs, we need to take a detour (see bug details on the why, this is just the how of the workaround):
```
sudo /etc/init.d/network-manager stop
sudo ip address add dev enp0s20u1c2 192.168.1.9/24
sudo dnsmasq --no-daemon --port=0 --conf-dir=/etc/NetworkManager/dnsmasq-shared.d
```
  Once that too shows a "sent" line, end dnsmasq with Ctrl-C; you can start NetworkManager again. (There's a timeout of guesstimated one minute in this step, after which the cycle starts from the beginning. If you don't get a "sent" line from the dnsmasq, check whether you properly renamed the fit file.)
- You should now see a new block device (/dev/sdc for me) appear, which represents the eMMC flash memory on the BeagleBone. If you have a serial console attached, you are dropped in a linux root shell on the BeagleBone. (What is running there is actually "just" a linux kernel with a g_ether module configured to expose /dev/mmcblk0).
  
  With that, you can flash images onto eMMC (follow the steps further) or mount and modify existing installations (eg. change the root password you were sure not to forget and have no clue about a year later).
- You can now flash the image using sudo dd if=bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img of=/dev/sdX -- and double-check whether you're writing to the correct sd-whatever device, dd is short for "disk destroyer".
- The current images have a (uboot config?) bug that results in the wrong root= argument being passed to the kernel. This can be circumvented by telling U-Boot to use disk UUIDs instead of device names [2]:
  
  Mount /dev/sdc1 (current bone Debian images have exactly one partition) and edit its /boot/uEnv.txt. There should be a commented-out line uuid=; remove the comment mark (#) and append the UUID of the partition obtained by the blkid /dev/sdc1 command.
  
  Unmount the disk, wait until the LEDs on the bone only flicker regularly, and then power-cycle it. The device should now boot into a full Debian that can be used from an HDMI attached monitor and USB mouse / keyboard.

[1]	There is only a non-free driver for the SGX/PowerVR builtin 3D accelerator, but that means I'd need to wait for vendor provided drivers for each kernel update the device would see during its regular lifetime and then still not retain full kernel support.

[2]

The images' bug tracker requires administrator approval for login, until then here's what it'll say:

The U-Boot config shipped before the Debian images' first partition currently uses U-Boot's MMC numbers to construct an oldroot /dev/mmcblk${mmcdev}p${mmcpart} name. When the image is flashed directly into eMMC and not onto an SD card, the kernel boots into the initrd, but lacking presence of an SD card, the MMC block device of mmcdev=1 gets assigned the device name /dev/mmcblk0; consequently, booting gets to a halt when the initrd's scripts complain that root was not found. (I've only observed the symptom and pieced together the MMC number explanation from the U-Boot environment variables, I didn't step through them precisely).

Until or unless the oldroot mechanism can be fixed to work independent of SD card presence (maybe /dev/disk/by-path is more stable?), the easiest workaround would be to always set the uuid in /boot/uEnv.txt to reflect the disk's UUID; then, the oldroot mechanism doesn't get used.

Tags:	blog-chrysn