This is obsolete as of the move to Zynq-based RCEs

Principles

The Boot Loader is the executable that is first run after a processor reset. Its job is to set up the processor environment so that application code can be run, to load that application code into main memory, and to transfer control to it.

The DAT group currently manages three different platform configurations:

• RCE board, Virtex 4 / PowerPC 405, 32 MB flash, 128 MB main memory, 4 character multisegment LED display, 8 position rotary selector switch
• DPM 405, Virtex 4 / PowerPC 405, 32 MB flash, 128 MB main memory, 4 GB microSIM, I²C interface to 4 multicolor LEDs and user options
• DPM 440, Vertex 5 / PowerPC 440, 4 GB main memory, 4 GB microSIM, I²C interface to 4 multicolor LEDs and user options

Further, it is anticipated that a 3rd generation of DPMs will be created in the future, based on Xilinx ZYNQ devices that have ARM A9 processors.

Requirements

The DAT group has placed the following requirements on the boot loader:

• Fast execution to minimize boot up times
• Less than 4 KB footprint
• Display progress through the boot cycle
• Modularity that enables support of several processors and board architectures
• Instruction and data caches are enabled prior to executing the application
• Support for selection of multiple applications codes
• Prepare an execution environment that conforms to the EABI specification

Implementation

The initial implementation of the RCE made extensive use of the so-called DCR space to allow the processor to interact with its environment. The newer designs use a different method based on interactions with an I²C bus via the APU interface. The peripherals where this affects the the boot loader are:

• Flash memory
• Display
• Application selection
• Main memory subsystem

In order to support all versions of the RCE, these interfaces are abstract in the boot loader...
Similarly, the details of the processor are abstract...
However, the code is written in assembler...

User Interface

Stack
Heap
EABI convention
Linker script

Use of XMD to debug application code.
A DAT supplied binary application is used to commit an application to flash.

Software Storage

There are three types of flash memory currently associated with the RCE:

• "Platform flash" is flash memory that stores the Xilinx FPGA configuration
• "Configuration flash" is controlled by the PowerPC software, and contains executable images and data needed by the PowerPC.
• "Petacache flash" is the flash memory that lives on DIMM boards associated with the slice FX20s (used only for the Petacache application, currently)

Only the configuration flash is relevant for PowerPC software/data storage. The configuration flash is a 32MB Samsung chip. The file system supports 64 numbered files of which 16 may contain executable images. The remainder of the files may be used for storage of data. The executable loaded on board-reset and power-on is determined by a rotary selector switch on the front-panel (one for each of the two RCEs on a board). A different executable may be selected in software by writing to a DCR register. The configuration flash may be programmed as described in the Debug section.

Updates

The boot loader uses the bootstrap word in the BSI structure to determine what bootstrap image to load. The word is broken up into 3 fields:

The version number is that of the word's format. If the number of bits allocated to either the bootstrap or application numbers were ever to be changed, the version number would be bumped.

At run time, if the version number compiled into the code matches the value loaded into the BSI structure by the IPMI Controller, the boot loader can proceed to decode the bootstrap number. If it doesn't, the boot loader bug checks.

A version of the boot loader is installed in all of the instances of the COB based hardware we currently maintain. Since development is on-going, the values found in the the bootstrap BSI word are not treated the same way on all instances. The intent is to rectify this when things stabilize. This has implications for the bootstrap code.

In some instances, backward compatibility with the older petacache boards was sought. These older boards use a 16 position selector switch on the front panel to choose which combination of bootstrap and application to load. One bit is used for the bootstrap, and three bits are used for the application. The bootstrap code parses these four bits for both the bootstrap number and the application number, so to maintain backward compatibility, the newer hardware should load the same 4 bit value in both fields. This has led to the definition of the bootstrap value in the range of 0 to 7 to mean that the so-called prod bootstrap image is loaded, and the range of 8 to 15 to mean that the so-called rescue bootstrap image is loaded.

To be continued...

• Memory test
  • Coarse vs Fine
  • Too time consuming for 2 GB and greater
• Definition of bootstrap numbers for certain self tests
  • Memory test
  • SD test
  • UDI test
• Definition of bootstrap numbers for choices of core
  • prod
  • rescue
  • devel