[back]
Putting The Wandboard To Work
modified: 2015-04-16 11:32:57

1. Selection of Distribution
2. Booting
1. Selection of Distribution

My first choice was the selection of the distribution that I wanted to use. I decided on Ubuntu since I am a little familar with it, and also I know that it comes with a decent package manager that is based on precompiled binaries which means that I will have to spend less time managing dependencies by hand and juggling libraries, and if needed I can resort to hand compiling something.

2. Booting

The wandboard site, [http://wandboard.org/downloads], comes with some prebuilt images. These are designed to be flashed onto a micro sd-card. The wandboard boots from this sd-card as its primary storage medium. The wandboard's ROM contains code that boots the board, but beyond that I was a little unsure. So I decided to first get the image and take a quick peek.

I downloaded the image and first took a look to see if it had a partition table using the command fdisk <image>.img and it showed two partitions. The first was an ext4 and the second was swap. So I first mounted the image using a loopback device with losetup /dev/loop0 <image>.img then I used kpartx -av /dev/loop0 to create two loopback partitions under /dev/mapper/. It creates a /dev/mapper/loop0p1, but it failed of course creating a partition to represent the swap, which I assumed would happen, and that is fine.

I mounted /dev/mapper/loop0p1 and I took a look. I found no /boot directory on the root partition. I did find what appeared to be a kernel under /root. I decided to get a better understanding of the boot process.

To get a better understanding I started searching for documentation. I found a development package on the wandboard website at the same place that I downloaded the Ubuntu image. If you extract this and look under the doc directory you will find a wand-dev.pdf which details the booting process. It appears that the Wandboard has a ROM which serves as the booting code for the system. It first looks for an SD card, which it will find. Then on this card it looks for a bootloader at byte offset 1024 on the card.

If I take a look at the partition table for my image it will show that the first partition starts at sector 16384 and that each sector is 512 bytes. This means that 8,388,608 bytes are before the first partition. Also, the partition table should resides at byte offset zero of the disk. To check this read from mounted image with dd if=/dev/loop0 of=tmp count=1, which will read one sector and write it to a file called tmp. Then dumping the file in hex we can see that the last two bytes are 0x55 and 0xaa which are the signature bytes for the partition table.

At byte offset 1024 we can also find the boot loader that the ROM executes. We can grab that using the options bs=1k skip=1 count=1. The documentation states that this is the SPL binary. The SPL stands for Secondary Program Loader. This SPL is supposed to load u-boot binary which is located 69KB into the device. We can also grab that and take a look and indeed there is a header present for U-BOOT. This program then expects a kernel 1MB into the device.

At [https://dev.openwrt.org/browser/trunk/tools/mkimage/src/image.h?rev=7306] you can find the description of the U-BOOT image header. If we check the magic bytes we can indeed see that both the image at 69KB and the one at 1MB have this header. The one at the 1MB is the actual linux kernel. I was unable to use mkimage to dump the header for the 69K and 1MB image, as it would report that the image data was corrupt. The image at 1K however was dumable and readable by mkimage.

I now have a good understanding of the boot process, or at least a decent one. This should prove useful if I ever have booting trouble. From this point the kernel boots and mounts the root filesystem.