winec7 启动架构

CE Boot Architecture
The CE Boot framework consists of the components shown below in Figure 1. The core code calls the code in the boot scenario, which calls the boot driver factory to instantiate boot drivers. The boot drivers communicate with the hardware to do the work (such as downloading the OS over Ethernet or reading it from persistent storage).

               Figure 1: CE Boot Framework Architecture

The CE Boot components shown in Figure 1 are: 

Core：The core code controls the flow of execution, memory mapping between physical and virtual addresses, and memory allocation. For more information, see Core Code. Boot Scenario：The boot scenario consists of code called by the core code to perform individual tasks, such as loading the OS into memory. For more information, see Boot Scenario Code.

Boot Driver Factory：The boot driver factory is a function that creates and initializes a boot driver and returns a handle to it. For more information on the boot driver factory, see Boot Driver Factory Code.

Boot Drivers：The boot driver code standardizes access to hardware devices by using only IOCTLs and a deinitialization function to communicate with them. For more information on boot drivers, see Boot Driver Code. (Note that the core CE Boot library can be used without any boot drivers.)

Notification and Logging：Notification functions interact with the user by providing information about events and by accepting feedback. Logging functions are typically used for debugging. For more information on notification and logging, see Notification and Logging Code.

 

Download the OS image into persistent storage 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 configuration boot settings, and the user can select choices from a boot menu.
3. In BOOT_STATE_DOWNLOAD, the boot loader downloads the image into persistent storage, such as flash memory.
CE Boot Framework
4. In BOOT_STATE_PRELOAD, the boot loader determines if it will start the Update Loader (ULDR). In this scenario, it doesn’t start it.
5. In BOOT_STATE_LOAD_OS, the boot loader loads the image from persistent storage 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 default configuration 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 in persistent 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 default configuration 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 persistent storage into RAM.
5. Finally, BOOT_STATE_RUN signals the successful end to the boot process.
Load a ULDR image from persistent 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 default configuration boot settings, and the user can select choices from a menu.
3. In BOOT_STATE_ULDR, the boot loader loads the ULDR image from persistent storage into RAM.
4. Finally, BOOT_STATE_RUN signals the successful end to the boot process. In this case, the ULDR image is booted instead of the OS image.