linuxboot/dxe
2018-08-09 06:58:17 -04:00
..
efidxe.h make gDXE->Dispatch() a function pointer 2018-08-09 06:56:26 -04:00
efifv.c split fv/ffs code into separate file 2018-08-09 06:58:17 -04:00
efifv.h split fv/ffs code into separate file 2018-08-09 06:58:17 -04:00
elf_x86_64_efi.lds linuxboot bds makes it to the end using the gnu-efi lds script 2018-08-09 06:58:12 -04:00
fvloader.c use the gnu-efi-devel package headers (should make this part of the checkout) 2018-08-09 06:55:36 -04:00
hello.c use the gnu-efi-devel package headers (should make this part of the checkout) 2018-08-09 06:55:36 -04:00
linuxboot.c split fv/ffs code into separate file 2018-08-09 06:58:17 -04:00
Makefile split fv/ffs code into separate file 2018-08-09 06:58:17 -04:00
README.md use the gnu-efi-devel package headers (should make this part of the checkout) 2018-08-09 06:55:36 -04:00
serial.h fvloader and hello world example dxe modules 2018-08-09 06:54:00 -04:00

Overview

These are small DXE modules that help bootstrap the LinuxBoot kernel. They depend on the gnu-efi-devel package for the headers.

Developing DXE

Calling conventions

The EFI environment uses the Microsoft ABI, so gcc must be told which functions are called from or call into the EFI system. This is done with the EFIAPI macro, which annotates the functions with the gcc x86 extension __attribute__((ms_abi))

The entry point into the DXE module must be named efi_main() and should have the prototype:

EFI_STATUS
EFIAPI
efi_main(
	EFI_HANDLE image,
	EFI_SYSTEM_TABLE * st
);

Any callbacks that are registered, such as for the ExitBootServices event, must also be flagged with EFIAPI.

Memory allocation

There are lots of pools of memory allocation during EFI, some of which are cleared when the OS starts, some of which stay resident, etc. In general you can request memory with:

    void * buf;

    if (gST->BootServices->AllocatePool(
            EfiBootServicesData,
            len,
            &buf
    ) != 0) {
	// handle an error...
}