After all necessary DXE drivers are executed and the DXE Foundation produces the EFI Boot Services and EFI Runtime Services, the DXE Dispatcher transfers the control to the BDS Architectural Protocol. The BDS Architectural Protocol establishes the console devices and then attempts booting to an operating system.

The BDS Architectural Protocol executes a variety of applications in the pre-boot environment. These applications may include setup, system configuration display, system diagnostics, OEM proprietary value-add applications, and the operating system boot loader.

Figure 17.4 shows an architectural view of the CSM under BDS. The BDS invokes the CSM if a traditional Option ROM is required, or a traditional boot option is found in the boot sequence, or the target operating system is legacy. The traditional Option ROM support is also required in an EFI environment when no EFI driver exists, that is, the device has no EFI driver but only a traditional Option ROM. In this case, the normal EFI binding of the device and driver fails. The BDS then binds the device with the traditional Option ROM via the EfiCompatibility module through the Legacy BIOS Protocol. The BDS then uses the Legacy BIOS Driver to dispatch and initialize the traditional Option ROM associated with the device.

Figure 17.4: Architectural View of CSM under BDS

During a legacy boot path in an EFI environment, the traditional Option ROM support is also required for the devices with an associated Option ROM even when both EFI driver and the...