Anuj Deshpande's Posts

In this blog post, I'll be covering how the BeagleBone Black boots up.

Types of boots on the BBB

The BeagleBone Black is very customizable. It's got 4 different methods of booting up.

eMMC boot
SD boot
Serial boot
USB boot

For getting ArduPilot on the BeagleBone Black, we will be using the eMMC boot option. It's the fastest of them all, and that's important for our use case.
(There are certain other methods of loading an image into the memory of the am335x processor, but that is out of scope here)

Boot sequence

The boot sequence is as follows : eMMC->microSD->USB port->serial and in the case that the boot button is pressed the sequence becomes microSD->USB port->serial.

Booting up

Following are the different bootloaders that are used in the eMMC boot option. It's the fastest of them all, and that's what we are looking for.

ROM Code

This is hard-coded in the am335x chip from TI. The ROM Code performs platform configuration and initialization as part of the public start-up procedure. A booting device list is genertated by this ROM code. The booting devices can either be memory booting devices or a peripheral interface connected to a host. The ROM code goes through this device list, and tries to look for a valid booting image. Take note that this is not the Linux kernel image. It looks for a much smaller image, which can be of 109Kb at max. This image is the MLO image that is stored on either the eMMC/SD.

This is one of the many things that this ROM code does. It also does some other stuff like configuration of the clocks for executing it's own as well as other codes, sets up the stack and configures the
watchdog timer. For more on this topic, read from the am335x TRM(Chapter 26 onwards)

SYSBOOT inputs for the boot device list

As stated above, the SYSBOOT pins, which are also the LCD_DATA pins, are located on the headers from P8:31 to P8:46. The pins are used to index the device table from which the list of devices is extracted.Any error that occurs in reading the value of these pins sends the ROM boot code into a loop, waiting for the watchdog to reset the system.

These pins can be used by software after ROM execution has completed. So, we can't have anything connected to these pins when the ROM code is executing.

MLO (aka x-loader)

As we discussed, the ROM boot code looks for a small image which is bootable in the boot devices list. It finds the MLO, either on the eMMC, SD card or any other peripheral device and then loads it up into the public RAM. This MLO file is not part of the ROM, it is located on the boot media that you are using. In normal cases, it will be the eMMC or the SD card. You can check out the binary version of this in boot/uboot directory.

root@beaglebone:/boot/uboot# ls -lah MLO-rwxr-xr-x 1 root root 103K Mar  4 23:37 MLO

The MLO is "secondary program loader". It will run and configure off-chip memory and then load the U Boot image. The MLO and the u-boot.img that it loads, both have to be located on a FAT filesystem.

The MLO is built when you build the U Boot bootloader. So the source code for this stage 1 is available to us with the U Boot source here

U Boot

The U Boot image is located in the boot/uboot directory on our BeagleBone Black

root@beaglebone:/boot/uboot# ls -lah u-boot.img-rwxr-xr-x 1 root root 358K Mar  4 23:37 u-boot.img

You will notice that it's bigger than the MLO that we saw in the previous section.

Das U Boot is the most commonly used bootloader on embedded systems. More about the project can be found here

If you connect a 3.3V USB-Serial cable to the BeagleBone Black, you will see the following on a screen session when the BBB boots up.

U-Boot SPL 2013.10-00016-ga0e6bc6 (Feb 25 2014 - 10:27:54)reading argsspl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2013.10-00016-ga0e6bc6 (Feb 25 2014 - 10:27:54)

I2C:   ready
DRAM:  512 MiB
WARNING: Caches not enabled
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
gpio: pin 53 (gpio 53) value is 1
Card did not respond to voltage select!
mmc0(part 0) is current device
Card did not respond to voltage select!
mmc1(part 0) is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 1
reading uEnv.txt
1417 bytes read in 6 ms (230.5 KiB/s)
Importing environment from mmc ...
gpio: pin 55 (gpio 55) value is 1
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
reading zImage
3711864 bytes read in 352 ms (10.1 MiB/s)
reading initrd.img
2870984 bytes read in 275 ms (10 MiB/s)
reading /dtbs/am335x-boneblack.dtb
24996 bytes read in 11 ms (2.2 MiB/s)
Kernel image @ 0x80300000 [ 0x000000 - 0x38a378 ]
## Flattened Device Tree blob at 815f0000
   Booting using the fdt blob at 0x815f0000
   Using Device Tree in place at 815f0000, end 815f91a3

Starting kernel ...

It loads the device tree, initializes pins as per the data structures
there and then loads the Linux kernel.

Uncompressing Linux... done, booting the kernel.[    0.378462] omap2_mbox_probe: platform not supported[    0.545588] tps65217-bl tps65217-bl: no platform data provided
[    0.609407] bone-capemgr bone_capemgr.9: slot #0: No cape found
[    0.646516] bone-capemgr bone_capemgr.9: slot #1: No cape found
[    0.683623] bone-capemgr bone_capemgr.9: slot #2: No cape found
[    0.720732] bone-capemgr bone_capemgr.9: slot #3: No cape found
[    0.736869] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#5:BB-BONELT-HDMI)
[    0.746454] bone-capemgr bone_capemgr.9: slot #6: Failed verification
[    0.753187] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[    0.769794] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed
[    0.832336] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8
[    0.844029] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22
[    0.851313] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
Loading, please wait...
Scanning for Btrfs filesystems
systemd-fsck[201]: rootfs: clean, 57884/111104 files, 295616/444160 blocks

Debian GNU/Linux 7 beaglebone ttyO0

default username:password is [debian:temppwd]

The IP Address for usb0 is: 192.168.7.2

All the above messages are generated from within the Linux that has
been booted up now.

This blog is in connection with the work that is being carried out at the PixHawk Fire project, which is basically ArduPilot on Linux(BeagleBone Black to start with).

References

Most of the above content has been taken from the am335x Technical Reference Manual.

Getting ArduPilot on the BeagleBone Black(and on Linux in general) involves taking care of a lot of operating system related functionalities which are may or may not be related to an autopilot. This is because Linux is used in a lot of different places, so it has a very generic toolset. Especially when it comes to embedded Linux, there are a lot of things that we could do without on an autopilot. In the following post, I'll be giving a brief overview of the device tree, and the choices that we are making and why.

How does the device tree work ?
A device tree is something which loads device/board specific information at boot. The kernel doesn't include any information about the specific features and requirements of a particular board. It only includes a framework to load the required details when it boots.
These details include information like
- CPU frequency
- Pin modes of the pins (Usually a single pin can be used in different ways as per the mode it is set in)
- Other such things
  For example, take a look at the device tree written by panto that comes with the official BeagleBone Black images.
What are capes ? BeagleBone Black is a prototyping board. That means different people use it in different ways. It's more of a lego brick than a castle you build using it ;) For building applications using the BBB, one puts a cape on top of it. Depending on what one want's to do, one could use a Replicape, which is a cape for 3D printers, or one could use the Audio cape or the Relay cape. There is one for almost every kind of application and loads more are being developed everyday.
The PixHawk Fire being developed by Philip Rowse at 3DR is a cape too.
What is capemgr ?
So a devicetree loads certain pins in certain values at boot. A particular cape may depend on certain other pins too. To load the same from userspace, after the BBB has booted up, we use the capemgr.
Each cape has it's own device tree overlay, which consists of the pins that particular board uses. These overlaysare dynamically loaded from the userspace.
This means that using capemgr, one can manipulate pin modes at runtime.
So why not use capemgr It is higly risky for pin modes to be manipulated at runtime for an autopilot. You wouldn't want a pin connected to your barometer lose it's functionality in flight. No need to elaborate the consequences of such a thing happening, either accidently or maliciously.
Loading our own device tree Since we won't be using the capemgr, which was made for loading pins required by capes, we need something to make use of the device tree which loads up at boot. All the pins that are required by will be present in this DT. A script will check that all the pins are loaded as per our requirements and will not allow the autopilot to start if there is something amiss.
Compatibility with other other capes Our approach will break compatibility for all the present capes. It means we won't be able to use BBB as an autopilot and in a 3D printer at the same time, but such scenarios are rare. We will miss out on some relevant capes like LCD cape, etc. But that's not a deal breaker.
Future vision The future vision for Debian, device tree and Linux in general is that we will have our own image in binary available for download, along with instructions on how to build it. We will be having quite a few initialisation scripts that ensure that the Linux has booted up to a robust system fit enough for something as serious as an autopilot.
We have this in place at the moment, on the wiki. We will be adding a lot more documentation as we progress.

In the next post, I'll be covering how to make changes to U Boot to load the device tree of our choice.

Happy flying :)

PS I am one of the 3 students (along with Victor and Sid) who are working with 3DR for BeaglePilot/PXF.