Satellite Subsystems » Flight Computer » Software » Bootloader

The BLUEsat Universal Boot System
The bootloader is the piece of software that executes on a processor immediately after power up and reset. On the x86, it is actually the Basic Input/Output System (BIOS) which loads first, and carries out the Power On Self Test (POST) before searching for a boot sector on any available storage media. It is the bootloader's task to inspect itself and the satellite subsystems, prepare the flight computer (FC) for the kernel, load the kernel into memory and pass execution to it. The kernel is the core of the satellite's operating system (OS), which is the software that manages the resources of the satellite FC and delegates them to various programs that perform specialized tasks.

In space applications, we must ensure that we can regain control of the processor in any circumstance by rebooting the system, using various means, some of which are processor-independent. Being the software that is run straight after bootup/reset, the bootloader is a mission-critical piece of software and must be as fault tolerant as possible. On BLUEsat, it will perform the POST, testing (eventually) every subsystem and input or output. It will diagnose any problems in its memory or devices, map them out, and should be able to adapt itself to operate as best as possible with the available resources in the event of a failure. (NOTE, it is impossible to protect any system in space at this level from failure completely, and it can be expected that other systems in the satellite, interfaces, subsystems and components of the FC may well fail during the design lifetime and beyond. With the FC being the achillies heel of the satellite, it must be able to cope as well as conceivable in these situations to prolong the operational life of BLUEsat.)

Another goal for the bootloader that will fly on BLUEsat is to be as flexible as possible. We want to be able to upload new OS kernels or even new bootloaders, reliably and securely, to the FC -- at a stage where the OS has not yet come into the picture. This will provide the groundstation with the ability to control the processor's execution as early as possible, to minimise the impact of erroneous or corrupted code, or damaged FC subsystems. Once BLUEsat is orbiting the earth, we should always be able to coax our FC back to operation no matter what unforseen malfunction may occur. With the bootloader being as flexible as possible, that allows the computer engineers on the ground a lot of freedom to think of and implement fixes for problems that may arise, which may not otherwise be possible.

Until the manufacture of the first protoypes of the FC, the bootloader is being developed on a CSE pleb which is a portable computer system based around the SA-1100 using DRAM. Although BLUEsat will use SRAM (due to its superior radiation tolerance), the pleb is a very close match to the hardware environment of the BLUEsat FC. From the start of development, the bootloader will be runnable on either the pleb or the BLUEsat FC, simply by changing a single line in a header file. The pleb has additional integrated onboard circuitry (as well as add on boards), most of which are irrelevant to BLUEsat. The kernel loading parts of the bootloader should be complete, as should a working prototype of the BLUEsat FC, when development switches to the FC prototype. Various subsystem tests and diagnostics will be added in line with the development of those other subsystems. Fortunately, the pleb provides access to many of the SA-1100's I/O pins, so interfacing can begin independent of the FC prototype if required.

The BLUEsat Universal Boot System (BUBS) is being developed by me as a highly application specific piece of software in order to meet its objectives. This is in opposition to Catapult, which currently runs on the pleb, and is one of several bootloaders available for the SA-1100. Catapult was developed at CSE in UNSW, for the task of booting the pleb and running Linux on it. It's goals were completely different, with architecture independence and modularity being key. I have decided to embark on a highly specialized piece of software to power up BLUEsat, instead of extending Catapult, which is very poorly documented. Furthermore, Catapult was not designed to be as fault tolerant, nor written as deterministically as possible; the added complexity opens the doors wider to the impacts of software or hardware failure. For BLUEsat, at least at this point, it seems to make sense to keep the bootloader as simple, straightforward and traceable as possible. If our satellite should one day fail to boot up properly, all of us computer engineers can sit down and quickly pinpoint the location of/reason for the fault, before coming up with a fix.

The version of BUBS that flies with BLUEsat will be contained in a radiation hardened ROM, to prevent it from ever being corrupted. Although the ROM can not be altered after launch, BUBS has the ability to chain-load, or transfer control to a 2nd-stage bootloader, if the need ever arises. Futhermore all bootloader functionality is built with redundancy, to ensure that any problems or bugs can be circumvented by achieving the desired functionality through an alternate route.

	Author: Vaenthan Thiru © The Author, the BLUEsat project or UNSW. All rights reserved. Last Modified: August 28 2005 10:43:58.