Efi OS loader

OS loader is a special type of EFI image. It is responsible for entering the system from the firmware environment into the OS environment. It has to complete the following important steps:

1. the OS loader must determine where the file is called, so that the OS loader can obtain other files from the same location.

2. the OS loader must determine where the OS is stored in the system, which is exactly the location of oskernerl. Bin.

3. OS loader must establish a memory ing map for physical memory resources to make the OS Kernel know the memory space to be managed next.

4. OS has the option to store the startup path and startup options in the form of environment variables on a non-volatile storage device, such as storing the S3 or S4 environment variables on a non-volatile storage device. OS loader may need to use these environment variables, and it may also need to pass some environment variables to OS kernel.

5. The next step is to call exitbootservices (). At this time, the OS loader will hand over the control to the OS kernel.

6. Finally, after calling exitbootservices (), the EFI boot services call will no longer be available. This means that the OS kernel has control over the system and it will only call the EFI runtime services.

The following code snippets describe the entire process.

• Device path and OS loader Image Information

Call handleprotocol () to obtain the loader_image_protocol interface from imagehandle and pass it to the OS loader application. Step 2: Call handleprotocol () to obtain the device_path_protocol interface of the device handle of the OS loader image. These two calls send the device path, file path, and other image information of the OS loader image to the OS.
Loader itself.

BS->HandleProtocol(ImageHandle, &LoadedImageProtocol, LoadedImage);

// Obtain the loader_image_protocol interface.

BS->HandleProtocol(LoadedImage->DeviceHandle, &DevicePathProtocol, &DevicePath);

// Obtain the device_path_protocol interface of the device handle of the OS loader image.

 

// The device path exists in devicepath.

// The file path exists in loadedimage-> filepath, which is the path of the OS loader image and stores oskernel. Bin.

• Access the file (oskernel. Bin) in the device path of the OS loader)

The next step is how to open the oskernel. binfile with the OS loader image in the same directory. Call handleprotocol () to obtain the file_system_protocol interface of the device handle obtained from the previous step. Then the disk volume can be opened. The final variable curdir becomes a file handle in the partition where the OS loader is located.

BS->HandleProtocol(LoadedImage->DeviceHandle, &FileSystemProtocol, &Vol);Vol->OpenVolume(Vol, &RootFs);CurDir = RootFs;

The next step is oskernel in the same directory as the OS loader image. binfile creates a file path. Once this path is set up, the handle file curdir can be used for oskernel. bind the file to open (), close (), read (), write (). Then the Code creates the file path, opens the file, and reads the file to the allocated buffer, and close the file.

Strcpy (filename, devicepathtostr (loadedimage-> filepath); for (I = strlen (filename), I> = 0 & filename [I]! = '\'; I --); filename [I] = 0; strcat (filename, l "\ oskernel. bin'); // create the file path curdir-> open (curdir, & filehandle, filename, fei_file_mode_read, 0); size = 0x00100000; BS-> allocatepool (efiloaderdata, size, & oskernelbuffer); filehandle-> Read (filehandle, & size, oskernelbuffer); filehandle-> close (filehandle );

• Search for OS partitions

For each partition of the system, the Fei sample Environment implements a block_io_protocol instance. OS loader can search for system partitions by searching for all block_io devices. The following code uses liblocatehandle () to obtain the block_io device handle list. These handles retrieve the first block of each block_io device. Handleprotocol () is used to obtain the device_path_protocol and block_io_protocol instances of each block_io device. The variable blkio is a block_io device handle that uses the block_io_protocol interface. readblocks () can be used to read the first block of the device.

Nohandles = 0; handlebuffer = NULL; liblocatehandle (byprotocol, & blockioprotocol, null, & nohandles, & handlebuffer); // obtain the block_io device handle list for (I = 0, I <nohandles; I ++) {BS-> handleprotocol (handlebuffer [I], & devicepathprotocol, & devicepath); BS-> handleprotocol (handlebuffer [I], & blockioprotocol, & blkio); // handleprotocol used to obtain device_path_protocol and block_io_protocol instance block = allocatepool (blkio-> blocksize); mediaid = blkio-mediaid; blkio-> readblocks (blkio, mediaid, (efi_lba) 0, blkio-> blocksize, block); // read the first block of the block_io Device

}

• Obtain the current system configuration information

It is obtained through systemtable and passed to OS loader image as a function parameter. System table is used to inform the OS loader of available firmware platform services and access to industry standard tables, such as ACPI and smbios.

• Obtain the current memory ing table

When the loader is running, the memory is managed by the platform firmware. The platform firmware has allocated the memory (boot services memory) to the firmware ), it also divides other memory resources that need to be kept to the OS Runtime ). Until OS loader gives the final control to OS kernel and calls exitbootservices (), the Fei platform firmware is in charge of memory allocation.

MemoryMap=LibMemoryMap(&NoEntries, &MapKey, &DescriptorSize, &DecriptorVersion);

• Get Environment Variables

Getnextvariablename (& variablenamesize, variablename, & vendorguid );

• Transition to OS Kernel

When exitbootservices () is called, OS loader must prepare for the transition to OS kernel. OS loader must hand over the system table to OS kernel so that OS kernel can conveniently call runtime services.