As detailed in Microcontroller Tips, when you turn on your personal computer, what you see is some lines of text scrolling on the screen before the actual operating system logo shows up. This is the boot loading sequence where the hardware incrementally fetches the minimum software stack to prepare the processing system to execute higher level software. In other words the bootloader is the first piece of software executed when the processing system is powered up or reset and is actually in charge of deploying upper level software and branching to it, which includes the Operating System or Application Software.

As far as the embedded domain is concerned embedded boot loaders, usually part of a Board Support Package, serve the exact same purpose than for regular home computers, but however must prove compliance to additional specific requirements with respect to availability, reliability, safety and security, and are generally smaller in size and complexity sacrifying versatility for the sake of simplicity.

For the space domain, such constraints translate at software level into application of development processes following the ECSS standard, i.e. ECSS-Q-ST-80C and ECSS-Q-ST-40 standards. Interested readers more familiar with other domains applying ISO 26262, IEC 61508 or DO-178 can refer to Machrouh, Joseph et al. “A cross-domain comparison of software development assurance standards.” (2012) for some insights on those ECSS standards.

The NG-Ultra System on Chip (SoC) boot procedure is split into the following main layers:

1. The first boot loading step is BL0 (for BootLoader level 0). It is a small application hard coded into the SoC internal ROM that fetches a binary executable (called BL1 for Bootloader level 1) from either local boot FLASH memory or remotely from SpaceWire bus.
2. This BL1 then initializes main hardware components, loads the eFPGA matrix configuration, loads and branches to a later applicative stage.
3. An additional BL2 stage or the final application dependent software then starts, finalizes hardware configuration and can deploy itself on all the available processor cores.

While BL0 was developed in the scope of DAHLIA H2020 project, and is hard coded in the SoC eROM, BL1 is developed in the scope of HERMES project and is field loadable. HERMES project inherited from the generic BL1 specification and hardware components drivers (such as DDR controller, flash controller) jointly developed by AIRBUSDefence and Space and THALES Alenia Space in the scope of CNES R&T study R-S19/BS-0004-061, and in close collaboration with NanoXplore so as to be integrated in their SDK/BSP package.

One of the main principles followed in the BL1 specification and design has been to keep things simple and focus only on those functions that are deemed mandatory and common to any mission scope. BL1 is expected to be either reused as is to branch to a custom BL2 or Application Software, or customized and modified according to mission needs by the final customer.

The common functionalities of the BL1 mapped to the NG-ULTRA SoC encompasses:

• Initialization of the master CPU#0 registers, caches and exceptions at most privileged level
• Initialization of mandatory hardware resources such as Clocks PLLs, DDR controller, Flash controller, SpaceWire controller, TCM memories
• Initialization of Memory Protection Unit allowing access to local Tightly Coupled Memories, embedded RAM, and external DDR
• Management of a load list whether stored in Flash or remotely received from SpaceWire

following a custom protocol, describing a set of application software to be deployed to memory, as well as bitstream to be programmed in eFPGA matrix.

• Management of integrity of deployed software and proper eFPGA matrix programming
• Management of basic redundancy for software components stored in Flash (either through TMR or through sequential accesses to multiple hardware flash components).
• Generation of a BL1 boot report made available for next-stage software

A detailed example of power up sequence from boot flash covering BL0 to BL2 stagesis detailed hereafter and illustrated in Figure 2.

• Power on reset, initial state
  • Core 0 is running, configured to boot from eROM mapped @ address 0
  • Core 1,2,3 in halt mode, configured to boot from TCM at address 0 when halt released by Core#0
• Core 0 runs BL0 from eROM, data and boot report in TCM C
  • BL0 loads BL1 in TCM A from NOR boot or from SpaceWire
  • BL0 checks integrity/authentication of BL1 image and if OK jumps to TCM A in arm mode

• Core 0 runs BL1 from TCM A , data and boot report in TCM C
  • BL1 wipes Core#0 TCM B and eRAM and initializes eRAM and DDR ECC, and preserves TCM C content
  • BL1 loads Bitstream from Flash Boot to eFPGA and checks eFPGA loading is OK
  • BL1 loads a BL2 software from NOR boot Flash to eRAM, DDR, or TCMs and if integrity OK jumps to the defined entry point

• Core 0 runs BL2 from DDR/eRAM/TCM
  • BL2 has access to mission specific external NAND Flash and can deploy final Application Software to eRAM/DDR/TCMs, release secondary cores, etc.

The BL1 development activities performed jointly by AIRBUS Defence and Space and THALES Alenia Space follow a standard ECSS development process. AIRBUS Defence and Space mainly leads the descending part of the V cycle from design, actual code development and up to unitary and integration testing, while THALES Alenia Space is in charge of validation activities.

A comprehensive datapack will be generated during this project, and will be composed of a consolidated version of mandatory documents paving the road toward ECSS level B qualification (SRS, SUITP/SUITR, SVTS, SValP/SValR and SUM). This deliverable will contain the BL1 source code as well as testing tool suite implementation, covering unitary, integration and validation source code exclusively using open source software tooling (gcc compiler, gcov for coverage, google test suite).

The overall time line of the development and the actors is given hereafter in Figure 3.