Deploying to the ODROID-XU4

This page outlines the process of getting a sel4 image to run on the ODROID-XU4. The inital setup is quite long, however, once you can run an image, it is very straightforward to copy over a new sel4 application.

Initial Setup

To run our seL4/application image on the ODROID, we need to put it and the bootloader onto our micro SD card. Insert the card into your card reader, then identify the device path (e.g. something like /dev/sdd). You can run sudo fdisk -l, lsusb, and lsblk to find the correct device (make sure it is the right size and that the description makes sense. Also, try fdisk -l before and after plugging in the card reader and sd card to see which device is new). Make sure you correctly identify the device path on your machine. We will be flashing the device, if you use the wrong name you could end up wiping the wrong drive. I will use "/dev/###" in my examples.

Type sudo fdisk /dev/###. The first thing we want to do is clear out any existing partitions. Type d to delete a partition. Next, we need to change to a MBR/DOS style partition table if it is not already. To do this, type o. Our bootloader will be placed very close to the beginning of the drive. If we were using a GPT partition table (as was the default on my SD card), the bootloader would end up overwriting part of the partition table, which is obviously not ideal. Next we want to create a new partition. Type n. Type p for primary partition and 1 for partition number. The recommended starting location is probably fine but I used 3072. The partition should fill the rest of the SD card. Once the partition is created, type w to write all of that to the actual drive. Type sudo mkfs.vfat -F 32 /dev/###1 to create a FAT32 filesystem on our new partition (you'll need a dosfstools package for this command). Mount this partition, and copy our sel4/application image over.

Now to transfer the bootloader as well. We will use a fork of U-boot specifically for the ODROID-XU4. Type git clone https://github.com/hardkernel/u-boot.git -b odroidxu4-v2017.05 to download. This repository contains a prebuilt binary of U-boot. If you would like to build from source, refer to the "Building U-boot" section below. Enter the sd_fuse directory, and then type sudo ./sd_fushing.sh /dev/### to flash the bootloader to the SD card (it will be written to a specific location the ODROID-XU4 knows to look for, after the partition table and before the first partition).

We are done with the SD card, now we must set up the serial connection. Attach the serial cable to the ODROID UART port and your computer's USB. You will need a serial communication program such as minicom. Type sudo minicom -s to open the settings menu. Select "serial port setup". Change serial device to match the serial cable, it should be something like /dev/ttyUSB followed by a number. Make sure the baud rate is set to 115200 8N1 and that the Hardware Flow Control is disabled. Now exit the menu and minicom should start (if it doesn't, you can type sudo minicom).

Now we are ready to boot on the ODROID. Insert the SD card and power it up. You should see U-boot starting up from your minicom session. U-boot will attempt to autoboot and fail because we aren't abiding by its default expectations. In your minicom session, type setenv bootcmd 'fatload mmc 0 ${loadaddr} <sel4-image-name>; bootelf ${loadaddr}', where <sel4-image-name> is substituted for the actual name of the sel4 image that is on the FAT partition of our SD card. Pay attention to the single quotes, they must be included so that the semicolon isn't interpreted as the end of the setenv command. Now type saveenv followed by reset. The ODROID should now reset and launch the application.

Updating the image

Thankfully, after the initial setup is out of the way, it is much easier to work on the ODROID. Every time it is powered on, it will launch straight into our seL4 application (U-boot runs the commands stored in the bootcmd environment variable automatically on startup).

To update our seL4/application image, all you need to do is mount the FAT partition of our SD card, and copy over your new image. Since the name of the application is hardcoded into U-boot's default boot command now, either make sure your new image has the same name as the previous one, or you can edit the bootcmd environment variable to look for the new image. Our automatic booting should fail when you remove the previous image, but if it doesn't, you can type enter twice as U-boot is starting up to abort the automatic boot and stay in the U-boot menu.

Since U-boot now launches our application automatically, the serial connection isn't strictly necessary. However, at the moment it is our only I/O.

Building U-boot

While prebuilt binaries are provided in the ODROID-XU4 fork of U-boot, you may want to build your own, either because you are making changes, or you just want to be confident that the binaries you use are indeed a reflection of the public source code. If the latter is your motivation, note that we cannot actually compile every bit we flash to the sd card. Specifically, b1.bin and and tzsw.bin are provided as precompiled blobs. For more info on that, see ODROID-XU4 Boot Details.

First, configure the project for our board. From the top level of the U-boot directory, type make odroid-xu4_defconfig.

Next, we need to set some environment variables:

export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-

(I would have thought ARCH=arm would have been set in the config file, but I guess not).

Finally, build U-boot with make or make -j #. The resulting binary will be called u-boot-dtb.bin. Move it to the sd_fuse directory. You can now run sd_fusing.sh like normal to flash the sd card. The script is smart enough to use your u-boot-dtb.bin, assuming you don't change the name, and only uses the precompiled hardkernel version of uboot if it can't find any other version in the sd_fuse directory.

As a final note, if you had an older version of u-boot on that sd card before and want to check that you are really using the newer version, you can type version in uboot. It should print the date it was compiled.