First Stage Bootloader
information technology and software
First Stage Bootloader (GSC-TOPS-230)
Provides functionality to read the software images from flash memory, using redundant copies and recovery mechanisms to produce valid images
Overview
Software often has two main parts. One part is the main operating system (OS) image, which contains an OS kernel and run-time environment. The other part is the ram filesystem image, which contains application libraries. Both parts must be read from flash memory into the correct locations in DDR memory for the software to be fully operational. The system will store several copies of each file in flash memory, reducing the probability that radiation events will render a given file to be unreadable from flash memory. Previous bootloaders could read the main OS image from flash memory, read redundant copies of images, and synchronize flash memory usage between two processors sharing the same flash memory bank. However, previous bootloaders supported reading only one image from flash memory. They also do not support restarting watchdog timers, meaning the watchdog timer must be off during the boot process. The First Stage Bootloader improves on previous bootloader versions.
The Technology
The First Stage Bootloader reads software images from flash memory, utilizing redundant copies of the images, and launches the operating system. This bootloader finds a valid copy of the OS image and the ram filesystem image in flash memory. If none of the copies are fully valid, the bootloader attempts to construct a fully valid image by validating the images in small sections and piecing together validated sections from multiple copies.
Periodically, throughout this process, the First Stage Bootloader restarts the watchdog timer.
The First Stage Bootloader reads a boot table from a default location in flash memory. This boot table describes where to find the OS image and its supporting ram filesystem image in flash. It uses header information and a checksum to validate the table. If the table is corrupt, it reads the next copy until it finds a valid table. There can be many copies of the table in flash, and all will be read if necessary. The First Stage Bootloader reads the ram filesystem image into memory and validates its contents. Similar to the boot table, if one copy of the image is corrupt, it will read the remaining copies until it finds one with a valid header. If it doesn't find a valid copy, it will break the image down into smaller portions. For each section, it checks each copy until it finds a valid copy of the section and copies the valid section into a new copy of the image. The First Stage Bootloader reads the OS image and interprets it. If anything in the image is corrupt, it reads the remaining copies until it finds a fully valid copy. If no copy is fully valid, it will use individual valid records from multiple copies to create a fully valid image.
Benefits
- Increases software reliability
- Improves update speed
- Facilitates recovery of corrupted software images
Applications
- Automotive manufacturing
- IoT software
- Embedded space systems
Technology Details
information technology and software
GSC-TOPS-230
GSC-17931-1
Similar Results
SpaceCube v2.0 Processor with DDR2 Memory Upgrade
This new version of the card assembly will feature a total of eight 4x DDR2 SDRAM memories per Xilinx FPGA. A dedicated regulator was included to compensate for the lower operating voltage of DDR2 in comparison to the older DDR memory. The DDR2 memories are grouped in pairs with shared address/command/control lines. By sharing those lines, the number of Xilinx I/Os for the DDR2 interfaces could be reduced. These improvements extend the life and design of the processor and provide even greater memory throughput to support the next generation of instruments.
SpaceCube Demonstration Platform
The HST SM4 SpaceCube flight spare was modified to create an experiment called the SpaceCube Demonstration Platform (SC DP) for use on the MISSE7 Space Station payload (in collaboration with NRL). It is designed to serve as an on-orbit platform for demonstrating advanced fault tolerance technologies.
With the use of Xilinx commercial Virtex4 FX60 FPGAs, the fault tolerant framework allows the system to recover from radiation upsets that occur in the rad-soft parts (Virtex4 FPGA logic, embedded PPCs in Virtex4 FPGAs, SDRAM and Flash), the C&DH system that runs simultaneously on both Virtex4 FPGAs that uses a robust telemetry packet structure, checksums, and the rad-hard service FPGA to validate incoming telemetry. The ability to be reconfigured from the ground while in orbit is a novel benefit, as well as is the onboard compression capabilities that allow compressed files from the ground to be uploaded to the SpaceCube.
Space Link Extension Return Channel Frames (SLE-RCF) Software Library
The Space Link Extension Return Channel Frames (SLE-RCF) software library helps to monitor the health and safety of spacecraft by enabling space agency ground support and mission control centers to develop standardized and interoperable mission control applications for space telemetry data. The software library eliminates the need for missions to implement custom data communication designs to communicate with any ground station. The two main tasks accomplished via the SLE-RCF software library are processing user requests and receiving data from ground stations and ground support assets.
The software library contains three layers:
-SLE (Space Link Extension) for the abstract workings of the protocol
-DEL (Decoding and Encoding Layer) to decode and encode the abstract messages used by the SLE layer
-TML (Transport Mapping Layer) to transfer the encoded messages via some underlying transport layer protocol, such as as the transmission control protocol (TCP)
The library accepts configuration or SLE-RCF directives from the user and responds accordingly. Incoming data, both telemetry frames and status messages, are processed and the appropriate callback routines are triggered by the library.
A Method For Developing And Maintaining Evolving Systems With Software Product Lines
The idea of a software product line has been developed that views software products that are substantially similar, or which have substantially similar content, as being different products in a line of products that the organization develops. For example, flight software for different missions can be viewed as a line of products that fulfills this purpose, with many of the products having similarities, or in extreme cases being very similar with a few specializations.
This method expands this view further and sees an evolving system, one that will likely run for a long period of time, and which must have corrections, enhancements and changes made to it over a period of time, as essentially exhibiting a product line. More specifically, different versions or releases of the system are viewed as different 'products' that are substantially similar. This method opens a new field of developing a complex system that is likely to involve many interacting components for development as a product line, which can be developed with state-of-the-art software engineering techniques.
Unique Datapath Architecture Yields Real-Time Computing
The DLC platform is composed of three key components: a NASA-designed field programmable gate array (FPGA) board, a NASA-designed multiprocessor on-a-chip (MPSoC) board, and a proprietary datapath that links the boards to available inputs and outputs to enable high-bandwidth data collection and processing.
The inertial measurement unit (IMU), camera, Navigation Doppler Lidar (NDL), and Hazard Detection Lidar (HDL) navigation sensors (depicted in the diagram below) are connected to the DLC’s FPGA board. The datapath on this board consists of high-speed serial interfaces for each sensor, which accept the sensor data as input and converts the output to an AXI stream format. The sensor streams are multiplexed into an AXI stream which is then formatted for input to a XAUI high speed serial interface. This interface sends the data to the MPSoC Board, where it is converted back from the XAUI format to a combined AXI stream, and demultiplexed back into individual sensor AXI streams. These AXI streams are then inputted into respective DMA interfaces that provide an interface to the DDRAM on the MPSoC board. This architecture enables real-time high-bandwidth data collection and processing by preserving the MPSoC’s full ability.
This sensor datapath architecture may have other potential applications in aerospace and defense, transportation (e.g., autonomous driving), medical, research, and automation/control markets where it could serve as a key component in a high-performance computing platform and/or critical embedded system for integrating, processing, and analyzing large volumes of data in real-time.
