The case for an EFI based bootloader on ARM
Jul 17, 2013
Let’s start off initially with what EFI or UEFI even is. EFI provides a firmware environment with core services and API programs can use for booting and additional services the operating system can use for maintaining platform data such as NVRAM variable storage. EFI’s boot services give the user ways to perform things that are normally done by hand in the bootloader stage, such as printing text to a console, or loading a file off of a volume. You can find the EFI Development Kit II source over here on Tianocore’s GitHub.
U-boot on ARM is very similar, but it doesn’t seem to provide a rich execution environment for programs. The data has to all be loaded in memory by the bootloader during core startup. This isn’t a very flexible design.
But what about XNU?
I made an EFI booter for ARM XNU because I want flexibility. Having a kernel simply loading off TFTP and using U-Boot’s/Linux’s ATAG functionality is nice for creating a core memory map, parsing command lines and also for sending ramdisks to the kernel, but it isn’t enough. The bootloader needs to be recompiled for each board to provide debug output over serial UART.
This gets annoying very quickly, as a new UART driver would need to be made every time a new board configuration is added.
Enter UEFI
UEFI provides core services such as Print, ZeroMem and so on. But, those are only the beginning. Enter the EFI boot services table.
typedef struct {
EFI_TABLE_HEADER Hdr;
EFI_RAISE_TPL RaiseTPL;
EFI_RESTORE_TPL RestoreTPL;
EFI_ALLOCATE_PAGES AllocatePages;
EFI_FREE_PAGES FreePages;
EFI_GET_MEMORY_MAP GetMemoryMap;
EFI_ALLOCATE_POOL AllocatePool;
EFI_FREE_POOL FreePool;
EFI_CREATE_EVENT CreateEvent;
EFI_SET_TIMER SetTimer;
EFI_WAIT_FOR_EVENT WaitForEvent;
EFI_SIGNAL_EVENT SignalEvent;
EFI_CLOSE_EVENT CloseEvent;
EFI_CHECK_EVENT CheckEvent;
EFI_INSTALL_PROTOCOL_INTERFACE InstallProtocolInterface;
EFI_REINSTALL_PROTOCOL_INTERFACE ReinstallProtocolInterface;
EFI_UNINSTALL_PROTOCOL_INTERFACE UninstallProtocolInterface;
EFI_HANDLE_PROTOCOL HandleProtocol;
VOID* Reserved;
EFI_REGISTER_PROTOCOL_NOTIFY RegisterProtocolNotify;
EFI_LOCATE_HANDLE LocateHandle;
EFI_LOCATE_DEVICE_PATH LocateDevicePath;
EFI_INSTALL_CONFIGURATION_TABLE InstallConfigurationTable;
EFI_IMAGE_LOAD LoadImage;
EFI_IMAGE_START StartImage;
EFI_EXIT Exit;
EFI_IMAGE_UNLOAD UnloadImage;
EFI_EXIT_BOOT_SERVICES ExitBootServices;
EFI_GET_NEXT_MONOTONIC_COUNT GetNextMonotonicCount;
EFI_STALL Stall;
EFI_SET_WATCHDOG_TIMER SetWatchdogTimer;
EFI_CONNECT_CONTROLLER ConnectController;
EFI_DISCONNECT_CONTROLLER DisconnectController;
EFI_OPEN_PROTOCOL OpenProtocol;
EFI_CLOSE_PROTOCOL CloseProtocol;
EFI_OPEN_PROTOCOL_INFORMATION OpenProtocolInformation;
EFI_PROTOCOLS_PER_HANDLE ProtocolsPerHandle;
EFI_LOCATE_HANDLE_BUFFER LocateHandleBuffer;
EFI_LOCATE_PROTOCOL LocateProtocol;
EFI_INSTALL_MULTIPLE_PROTOCOL_INTERFACES InstallMultipleProtocolInterfaces;
EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES UninstallMultipleProtocolInterfaces;
EFI_CALCULATE_CRC32 CalculateCrc32;
EFI_COPY_MEM CopyMem;
EFI_SET_MEM SetMem;
EFI_CREATE_EVENT_EX CreateEventEx;
} EFI_BOOT_SERVICES;
That’s a lot of boot services. In EFI, everything is handled by specific protocols, which are installed by various drivers. These provide rich functionality for the user programs. For example, the SimpleFileSystem protocol allows the user to open volumes without having to rewrite platform code to open eMMC, then parse the partition tables, and finally then parsing the filesystem.
Loading the mach_kernel.
Although EFI provides a rich firmware environment, its programming paradigm can be awfully over the top at times.
/* Load the kernel. */
Print(L" * Loading \"%s\"...", kMachKernelName);
Status = gBS->LocateProtocol (&gEfiSimpleFileSystemProtocolGuid, NULL, (VOID **)&FsProtocol);
if(Status != EFI_SUCCESS)
return EFI_LOAD_ERROR;
/* Try to open the volume and get the root directory. */
Status = FsProtocol->OpenVolume (FsProtocol, &Fs);
if(Status != EFI_SUCCESS)
return EFI_LOAD_ERROR;
File = NULL;
Status = Fs->Open (Fs, &File, kMachKernelName, EFI_FILE_MODE_READ, 0);
if(Status != EFI_SUCCESS)
return EFI_LOAD_ERROR;
Size = 0;
File->GetInfo(File, &gEfiFileInfoGuid, &Size, NULL);
FileInfo = AllocatePool (Size);
Status = File->GetInfo(File, &gEfiFileInfoGuid, &Size, FileInfo);
if(Status != EFI_SUCCESS)
return EFI_LOAD_ERROR;
/* Get the file size. */
Size = FileInfo->FileSize;
FreePool(FileInfo);
Status = gBS->AllocatePages(Type, EfiBootServicesCode, EFI_SIZE_TO_PAGES(Size), Image);
if ((Status == EFI_OUT_OF_RESOURCES) && (Type != AllocateAnyPages)) {
Status = gBS->AllocatePages(AllocateAnyPages, EfiBootServicesCode, EFI_SIZE_TO_PAGES(Size), Image);
}
if (!EFI_ERROR (Status)) {
Status = File->Read (File, &Size, (VOID*)(UINTN)(*Image));
}
This is overly complex, but still, not as complex as having to do it all from a core loader. People may ask, “why not just integrate everything into u-boot”? The answer to this is to be board agnostic. If I can just place my boot.efi file on a SD card for one board and I don’t have to recompile the firmware entirely, it makes my day go better.
Loading Other Files
Darwin on ARM, at least my version, is intended to act a lot like desktop Mac OS X, that is, it will have a proper HFS root file system with a /System/Library/Extensions folder. The kernel will not be prelinked as per iOS, but will instead be a standalone binary in the root of the filesystem. On u-boot, this isn’t really possible without extending the functionality built in to the bootloader, and I don’t really want to recompile u-boot for every single platform either.
EFI, as I stated before, provides a way to load files off block devices with recognized file systems, albeit a very cumbersome one. Loading kexts and parsing them is a simple task to do in this environment.
Enter the Matrix
Now, passing control from EFI to the actual OS? That’s simple. By calling GetMemoryMap and then ExitBootServices, the core of EFI is effectively jettisoned out, and now the OS is free to control mainly all of memory.
I pass control to Darwin by copying the kernel to where it should be, then doing core ARM initialization, and then finally using a bx lr into the kernel entrypoint.
After that, the operating system has to do everything.
Share