CE Boot Architecture

CE Boot Architecture
The CE Boot framework consists of the components shown below in Figure 1. Thecore code calls the code in the boot scenario, which calls the boot driverfactory to instantiate boot drivers. The boot drivers communicate with thehardware to do the work (such as downloading the OS over Ethernet or reading itfrom persistent storage).
 
  Figure 1: CE Boot Framework Architecture

The CE Boot components shown in Figure 1 are: ·

Core：The core code controls the flow ofexecution, memory mapping between physical and virtual addresses, and memoryallocation. For more information, see Core Code.

Boot Scenario：The boot scenario consistsof code called by the core code to perform individual tasks, such as loadingthe OS into memory. For more information, see Boot Scenario Code.

Boot Driver Factory：The boot driver factory isa function that creates and initializes a boot driver and returns a handle toit. For more information on the boot driver factory, see Boot Driver FactoryCode.

Boot Drivers：The boot driver codestandardizes access to hardware devices by using only IOCTLs and adeinitialization function to communicate with them. For more information onboot drivers, see Boot Driver Code. (Note that the core CE Boot library can beused without any boot drivers.)

Notification and Logging：Notification functionsinteract with the user by providing information about events and by acceptingfeedback. Logging functions are typically used for debugging. For moreinformation on notification and logging, see Notification and Logging Code.

Download the OS image into persistentstorage and then into RAM
1. When the device is started, the boot loader is in BOOT_STATE_POWERON.
2. In BOOT_STATE_CONFIG, the boot loader loads the saved or default configurationboot settings, and the user can select choices from a boot menu.
3. In BOOT_STATE_DOWNLOAD, the boot loader downloads the image into persistentstorage, such as flash memory.
4. In BOOT_STATE_PRELOAD, the boot loader determines if it will start the UpdateLoader (ULDR). In this scenario, it doesn’t start it.
5. In BOOT_STATE_LOAD_OS, the boot loader loads the image from persistentstorage into RAM.
6. Finally, BOOT_STATE_RUN signals the successful end to the boot process.
Download the OS image directly into RAM
1. When the device is started, the boot loader is in BOOT_STATE_POWERON.
2. In BOOT_STATE_CONFIG, the boot loader loads the saved or defaultconfiguration boot settings, and the user can select choices from a menu.
3. In BOOT_STATE_DOWNLOAD, the boot loader loads the image into RAM.
4. Finally, BOOT_STATE_RUN signals the successful end to the boot process.
Load the OS image that is already inpersistent storage into RAM
1. When the device is started, the boot loader is in BOOT_STATE_POWERON.
2. In BOOT_STATE_CONFIG, the boot loader loads the saved or defaultconfiguration boot settings, and the user can select choices from a menu.
3. In BOOT_STATE_PRELOAD, the boot loader determines if it will start the ULDR.In this scenario, it doesn’t start it.
4. In BOOT_STATE_LOAD_OS, the boot loader loads the image from persistentstorage into RAM.
5. Finally, BOOT_STATE_RUN signals the successful end to the boot process.
Load a ULDR image from persistentstorage into RAM
1. When the device is started, the boot loader is in BOOT_STATE_POWERON.
2. In BOOT_STATE_CONFIG, the boot loader loads the saved or defaultconfiguration boot settings, and the user can select choices from a menu.
3. In BOOT_STATE_ULDR, the boot loader loads the ULDR image from persistentstorage into RAM.
4. Finally, BOOT_STATE_RUN signals the successful end to the boot process. Inthis case, the ULDR image is booted instead of the OS image.