This file documents the internals of the GNU Firmware Implementation. Copyright 2006 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Table of Contents ***************** Top 1 Introduction 2 Building GNUFI 2.1 Building The Firmware Kernel 2.2 Building A Firmware Image 2.3 The `gnufi-mkimage' Utility 2.4 Available Kernel Scripts 3 Firmware Loaders 3.1 i386 Multiboot loader 4 Board Specific Configuration Scripts 5 Libraries 5.1 libefi: Standard UEFI API 5.1.1 Protocol Interface Related Functions 5.1.2 Device Path Related Functions 5.1.3 String Functions 5.1.4 Parsing of Options 5.1.4.1 Example usage of efi_argp_parse 5.1.5 Memory Management 5.2 libefi-fshelp: File System Help Library 6 GNUFI Internals 6.1 Memory Management 6.2 Kernel Scripts 6.3 Internal Protocols 6.3.1 Variable Store 6.3.1.1 Interface 6.3.1.2 Related Definitions 7 Concept Index 8 Function Index Top *** This file describes GNUFI, the GNU Firmware Implementation. This document applies to version 0.0. Copyright (C) 2006 Free Software Foundation, Inc. 1 Introduction ************** GNUFI is a free implementation of the UEFI specification. UEFI defines a set of services and an environment that can be used to boot into an operating system. The design goals for GNUFI is that is should be (1) portable, (2) extendable and (3) specification confirming. To achieve those goals the following concepts are introduced: Loaders At configuration time different firmware loaders can be specified (*Note Loaders::.). This enables the firmware to be run in different pre-existing environments. An example of a firmware loader could be `i386-legacy'; a loader that loads the firmware in a legacy BIOS environment. Another example loader could be `ppc-uboot'; a loader that loads the firmware using the U-Boot bootloader on a PPC architecture. Kernel scripts Per-board configuration scripts, called kernel scripts or simply kscripts, are used to enable the user to select what services to include in a firmware image, and how to connect those services to devices. The kscripts are also used to setup fall-back console I/O in case that the boot manager can not initialize the preferred console. Modules Most services are implemented as modules, this enables the user of the firmware to pick with great detail what services he or she requires for their environment. 2 Building GNUFI **************** 2.1 Building The Firmware Kernel ================================ The GNUFI build system uses a `configure' script generated by GNU Autoconf. Before running the configure script, a firmware kernel loader has to be picked. *Note Loaders::, for a complete list of available loaders. The loader is specified using the `--with-loader' option to the configure script. _Suggestion_: Build the firmware in a separate directory from the sources. gnufi-0.0$ mkdir build && cd build gnufi-0.0/build$ ../configure --with-loader=i386-multiboot ... gnufi-0.0/build$ make ... gnufi-0.0/build$ The above example configures and builds a firmware kernel suitable to be loaded by a multiboot compliant boot loader, such as GNU GRUB. It also builds a set of runtime modules and a few utilities. 2.2 Building A Firmware Image ============================= The step after configuring and building the firmware kernel is to build a firmware image suitable for the system it should be run on. This is done using the `gnufi-mkimage' utility that was built alongside the kernel. The example below uses the `gnufi-mkimage' utility to create a firmware image that is suitable to be used on Intel 440BX based systems: $ gnufi-mkimage -o firmware.image i386-440bx.kscript How the image is installed and started is loader specific. *Note Loaders::. 2.3 The `gnufi-mkimage' Utility =============================== The `gnufi-mkimage' utility takes a kernel script file as argument (*Note Kernel scripts::.) and creates a firmware image based on its contents. The utility also takes the following options; `-o FILE' Specify output file. `-d DIR' Specify where modules specified in the configuration file can be found. 2.4 Available Kernel Scripts ============================ Below is a list of board specific kernel scripts distributed with GNUFI: `i386-440bx.kscript' Intel 440BX based boards. 3 Firmware Loaders ****************** GNUFI is designed so that the firmware can be loaded in several different ways, suiting the desired environment. A `loader' is responsible for loading the firmware kernel into memory and collecting information about the environment before passing control to the firmware kernel. 3.1 i386 Multiboot loader ========================= TODO 4 Board Specific Configuration Scripts ************************************** Board specific configuration scripts, called kernel scripts or simply kscripts, are used to enable the user to select what services to include, and how to connect those services to devices. The scripts contain a sequence of operations to perform while starting the firmware. An operation is specified by a single operation command word and a set of arguments. All lines that start with a `#' are treated as comments. The following operations are available: `load MODULE' Load and start module specified by MODULE. The module can either be a driver or an application. `connect PATH' Connect device path specified by PATH to a (or several) suitable drivers picked by the firmware. The last component of the path will be recursively connected, meaning that any children that it may create will also be connected. `set VARIABLE PATH' Set variable VARIABLE to the handle specified by PATH. The following variables are available: `stdout' `stderr' Sets handles for standard output and standard error output. `stdin' Set handle for standard input. Below is a complete (bogus) example of a kscript that loads a set of modules, connects the PCI IDE controller, which will also connect any possible disks that it detects. After that it will set console handles to the first serial console on the PCI ISA bridge. # board kscript: bogus-example.kscript load cpuio-i386.efi load pci-rb+i386t1.efi load pci-bus.efi load pci-ide.efi load disk-io.efi load pci-isa.efi load ser-ns16550.efi # connect IDE controller connect /pciroot(0)/pci(1,1) # connect stdout and stderr set stdout /pciroot(0)/pci(0,1)/acpi(PNP0503,0) set stderr /pciroot(0)/pci(0,1)/acpi(PNP0503,0) # connect stdin set stdin /pciroot(0)/pci(0,1)/acpi(PNP0503,0) 5 Libraries *********** 5.1 libefi: Standard UEFI API ============================= The `libefi' library contains the functions for the standard UEFI interface alongside a few convenience functions. Include the file `' to get prototypes for the functions. 5.1.1 Protocol Interface Related Functions ------------------------------------------ TODO: overall description -- Function: efi_status_t efi_install_protocol_interface (efi_handle_t *HANDLE, efi_guid_t *GUID, efi_interface_type_t TYPE, void *INTERFACE) Attach a protocol interface to handle *HANDLE. The protocol is identified by GUID. If *HANDLE is `NULL', a new handle will be allocated and returned. -- Function: efi_status_t efi_uninstall_protocol_interface (efi_handle_t HANDLE, efi_guid_t *GUID, void *INTERFACE) Uninstall a protocol instance. If this was the last protocol associated with the handle, the handle will be destroyed. 5.1.2 Device Path Related Functions ----------------------------------- These functions are user to manage device paths in different ways. Most of them are not part of the UEFI interface, but implemented as convenience functions in the library. -- Function: efi_status_t efi_device_path_add_to_handle (efi_handle_t HANDLE, efi_device_path_t *PATH) Add device path specified by PATH to the device handle HANDLE. -- Function: efi_device_path_t* efi_device_path_get_from_handle (efi_handle_t HANDLE) Return device path for handle specified by HANDLE, or `NULL' in case of error. -- Function: efi_device_path_t* efi_device_path_build (efi_boolean_t FREE_THEM, ...) Build a device path from a given list of path nodes. The list is NULL terminated. If FREE_THEM is true, release memory for all given nodes. -- Function: efi_device_path_t* efi_device_path_iterate (efi_device_path_t **pathp) Iterate nodes of the device path. *PATHP should be set to point to the path that is to be iterated. `NULL' will be returned when the end of the path has been reached. 5.1.3 String Functions ---------------------- -- Function: efi_int_t efi_wstrcmp (efi_char16_t *S1, efi_char16_t *S2) Compare unicode strings S1 and S2 and return the difference. -- Function: efi_int_t efi_wstrncmp (efi_char16_t *S1, efi_char16_t *S2, efi_uint_t N) Compare unicode strings S1 and S2, and return the difference. Only compare N number of characters. -- Function: efi_int_t efi_wstricmp (efi_char16_t *S1, efi_char16_t *S2) Compare strings and return the difference, independent of case. -- Function: efi_char16_t* efi_wstrcpy (efi_char16_t *D, efi_char16_t *S) Copy string specified by S to the memory buffer pointed to by D. Return D. -- Function: efi_char16_t* efi_wstrncpy (efi_char16_t *DST, const efi_char16_t *SRC, efi_uint_t SIZE) Copy SIZE characters from string SRC to string buffer DST. Return DST -- Function: efi_uint_t efi_wstrlen (efi_char16_t *S) Return length of given string S. 5.1.4 Parsing of Options ------------------------ The `efi' library contains functionality for parsing options. The parsing framework is modeled after `argp' from the GNU C library. The application defines a list of valid options, and pass them together with a parse hook to the `efi_argp_parse' method. The hook will get invoked during the parsing with information about what option was just parsed. Definitions and prototypes is available in `gnu/efi/util/argp.h'. The options is defined as a NULL terminated array of `efi_argp_option_t' structures. The `efi_argp_option_t' structure has the following members: -- argp Option: efi_char16_t* longarg Long argument name of the option, if any. Long arguments are argumnets that start with `--'. For example `--output'. -- argp Option: int shortarg Short argument name of the option, if any. Short argument are arguments that start with `-'. For example `-o'. -- argp Option: int flags Option flags. The only flag currently available is `EFI_ARGP_ARG_OPTIONAL' which defines that the option takes an optional argument. -- argp Option: int key A key that can be used by the parser hook to identify the option. -- argp Option: efi_char16_t* doc A documentation string that describes the option. Mandatory. -- argp Option: efi_char16_t* arg Name of the argument that the option takes. Should be in uppercase. FIXME: If neither LONGARG nor SHORTARG is specified in the option is treated as an mandatory argument to the program. If no option is defined for the program argument, the hook will be invoked with OPT as NULL but a valid ARG argument. FIXME: When all options has been parsed the parser will invoke the hook with OPT and ARG set to NULL to signal that all options has been parsed. The signature of the hook: -- Function: efi_status_t efi_argp_parse_hook_t (void *DATA, efi_argp_option_t *OPT, efi_char16_t *ARG) Parse hook invoked from the option parser. DATA is a user defined pointer that was provided to EFI_ARGP_PARSE. OPT is the option that was pased, and ARG is an optional argument to the option. The hook should return `EFI_SUCCESS' if it could handle the option. _Caution:_ The option parser uses the first argument passed to `efi_argp_parse' as the program name. -- Function: efi_status_t efi_argp_parse (int ARGC, efi_char16_t **ARGV, efi_argp_option_t *OPTIONS, efi_argp_parse_hook_t HOOK, void *DATA) Parse options and invoke hook HOOK with the parsed option. OPTIONS is a list of options that should be parsed. ARGC is the number of arguments passed to the program. ARGV is an array of all arguments. DATA is a user defined pointer that will be passed to the hook. 5.1.4.1 Example usage of efi_argp_parse ....................................... The small example below shows a program that accepts two options: `--count' and `--verbose', with short versions `-c' and `-v' respectively. static efi_argp_option_t options = [] { { L"count", 'c', 0, 0, L"Forward direction", L"NUM" }, { L"verbose", 'v', 0, 0, L"Verbose output", NULL }, { 0, 0, 0, 't', L"Text to display", L"TEXT" }, { 0, 0, 0, 0, 0, 0 } }; int count = 10; int verbose = 0; efi_char16_t *text = NULL; static efi_status_t parse (void *data, efi_argp_option_t *opt, efi_char16_t *arg) { switch (opt->shortarg) { case 'c': count = efi_wstrtoul (arg, NULL, 0); break; case 'v': verbose = 1; break; } switch (opt->key) { case 't': text = arg; break; } return EFI_SUCCESS; } efi_status_t efi_main (efi_handle_t image, int argc, efi_char16_t **argv) { efi_status_t err; int i; err = efi_argp_parse (argc, argv, options, parse, 0); if (err) return err; for (i = 0; i < count; i++) if (verbose) efi_printf (L"%s\n", text); return EFI_SUCCESS; } 5.1.5 Memory Management ----------------------- Besides the functions that the UEFI makes available for memory management, the `efi' library provides a set of convenience functions to make it easier to allocate and free memory. To allocate pooled memory the `efi_malloc' function can be used. The difference from `efi_allocate_pool' is that `efi_malloc' returns a pointer to the allocated memory. Memory allocated with `efi_malloc' is like any other pooled memory freed with `efi_free_pool'. -- Function: void* efi_malloc (efi_memory_type_t type, efi_uint_t size) Allocate SIZE bytes of pooled memory from memory pool specified by TYPE. Return pointer to allocated memory, or `NULL' if memory could not be allocated. The `efi_palloc' and `efi_pfree' functions operate on page memory, meaning that the handle non-pooled memory. `efi_palloc' allocates memory and sets it to a specified memory type, using the given allocation scheme. `efi_pfree' releases memory allocated with either `efi_palloc' or `efi_allocate_pages'. -- Function: void* efi_palloc (efi_allocate_type_t ALLOCATE_TYPE, efi_memory_type_t MT, efi_uint_t SIZE) Allocate memory using allocation scheme ALLOCATE_TYPE and memory type MT. Allocate SIZE bytes of memory. -- Function: void efi_pfree (void *P, efi_uint_t SIZE) Free pages pointed to by P. SIZE is the number of bytes allocated. 5.2 libefi-fshelp: File System Help Library =========================================== The `libefi-fshelp' library can be used by drivers that want to implement the `simple file system' protocol. The library presents a complete interface, but communicates with the file system backend through a minimal API. The interface is defined in the `gnu/efi/util/fshelp.h' header. The file system backend defines a type `efi_fshelp_node_t' that represents a node in the file system. The type is fully opaque to the library. Nodes are reference counted. The library can at any time obtain an extra reference by calling the `reference' operation on the node, or release a reference by invoking `release'. It is up to the file system implementation to maintain references. -- Function: efi_status_t efi_fshelp_install_protocol_interface (efi_handle_t CONTROLLER, efi_fshelp_t *FSHELP, struct efi_fshelp_ops *OPS) Install all the protocol interfaces that the library defines on the controller specified by CONTROLLER. FSHELP is the fshelp instance that will be used through out the lifetime of the protocols. OPS is the file system backend operations vector. The `efi_fshelp_ops' vector contains the following operations: -- fshelp Operation: efi_status_t mount (efi_fshelp_t *FSHELP, efi_fshelp_node_t **ROOT) Try to mount file system and return a reference to node in *ROOT. -- fshelp Operation: void reference (efi_fshelp_node_t *NODE) Obtain reference to node specified by NODE. -- fshelp Operation: void release (efi_fshelp_node_t *NODE) Release reference to node specified by NODE, possible destroy it. -- fshelp Operation: efi_status_t getinfo (efi_fshelp_node_t *NODE, efi_file_info_t *INFO) Retreive information about the node NODE and store it in the buffer specified by INFO. The backend may in turn cache the information for higher performance. -- fshelp Operation: efi_status_t setinfo (efi_fshelp_node_t *NODE, efi_file_info_t *INFO) Set information about the node NODE given the information in INFO. -- fshelp Operation: efi_status_t readdir (efi_fshelp_node_t *DIR, efi_uint64_t *FPOS, efi_fshelp_node_t **NODEP, efi_char16_t **NAMEP) Read a directory entry at the position specified by *FPOS from node DIR. If no more directory entries could be read, the operation should return `EFI_NOT_FOUND'. A reference to the node in the read directory entry is returned in *NODEP, and the name of the entry in *NAMEP. The caller is resposible for releasing the reference to *NODEP and freeing the memory of *NAMEP. The position *FPOS should be updated on a successful read. -- fshelp Operation: efi_status_t read (efi_fshelp_node_t *NODE, efi_uint64_t FPOS, efi_uint_t *SIZE, void *BUFFER) Read data from the node NODE at position given by FPOS. The amount of data to read is determined by *SIZE, which will be updated with the actual amount of data read on return. On return, if *SIZE is zero there is no more data to read. The data will be read into buffer BUFFER. The library also implements a set of helper functions that can be used to more easily implement some of the fshelp operations. -- Function: efi_status_t efi_fshelp_read_helper (efi_fshelp_node_t *NODE, efi_fshelp_read_hook_t READ, void *READ_DATA, efi_uint64_t POS, efi_uint_t *SIZE, void *BUFFER, efi_fshelp_block_hook_t BLOCK, efi_uint64_t FILESIZE, int LOG2BLOCKSIZE) Read *SIZE bytes from the node NODE into the buffer BUFFER, beginning with the block POS. READ hook is used to read disk blocks. READ_DATA will be passed to the hook as the first argument. BLOCK hook is used to translate file blocks to disk blocks. The file is FILESIZE bytes big and the blocks have a size of LOG2BLOCKSIZE (in log2, units of 512 bytes blocks). 6 GNUFI Internals ***************** This chapter describes the internal workings of the GNUFI kernel. 6.1 Memory Management ===================== The GNUFI kernel presents a slim memory interface that is used both by the loader and by the internals of the kernel itself. The loader is responsible to feed memory information to the kernel. It should do this by first allocating a region of the memory to hold memory descriptor data. This is done using the `efi_mm_init' function. Characteristics and attributes for different memory regions are passed to the kernel using the `efi_mm_set' function. _Note:_ Characteristics for the memory descriptor region must be set manually by the loader. The kernel does _not_ do that itself. The memory type should be `EFI_MEMORY_TYPE_RUNTIME_SERVICES_DATA'. The loader should also set the memory type to `EFI_MEMORY_TYPE_RUNTIME_SERVICES_CODE' and `EFI_MEMORY_TYPE_RUNTIME_SERVICES_DATA' for the kernels code and data, respectively. _Note:_ Memory region starting at physical address zero should not be passed to the kernel as conventional memory, nor be used as memory for the memory descriptors. -- Function: void efi_mm_init (efi_physical_address_t ADDR, efi_uint_t SIZE) Initialize memory system. ADDR points to the region that will be used to manage the memory descriptors. SIZE gives the size of the memory region. Note that the memory region given to this function must be also be reserved using the `efi_mm_set' function. -- Function: efi_status_t efi_mm_set (efi_physical_address_t START, efi_physical_address_t END, efi_memory_type_t MEMORY_TYPE, efi_uint64_t ATTRIBUTES) Set memory type of specified range to memory type given in MEMORY_TYPE. The region is specified by START and END. The `efi_mm_alloc' function can be used to locate a region of memory that is suitable for allocation, given the specified allocation type. The caller is self responsible for changing memory type for the resulting region. -- Function: efi_status_t efi_mm_alloc (efi_allocate_type_t ALLOCATE_TYPE, efi_uint_t NUM_PAGES, efi_physical_address_t *MEMORY) Locate a suitable memory range for a memory allocation specified by ALLOCATE_TYPE. NUM_PAGES gives the size of the requested memory. The UEFI specification mandates the changes to the memory descriptor database must be recorded, so that it may be noted if the database has been altered between two points. This is done using a "generation counter" that is increased when an alteration is done to the database. -- Variable: efi_uint_t efi_mm_key Memory key. Updated everytime the memory descriptor database is altered. 6.2 Kernel Scripts ================== The kernel script is inlined in binary representation together with the GNUFI kernel in the firmware image. It is up to the `gnufi-mkimage' utility to merge modules and build a kscript structure that the loader can later pass to the kernel. In binary representation is a kernel script a list of TLV-records, in native endianess. Signature of the kscript generic header; struct efi_kscript { efi_uint16_t type; efi_uint16_t subtype; efi_uint32_t offset; }; TYPE specifies what kind of script record it is. The last entry must be of type `EFI_KSCRIPT_END_TYPE'. SUBTYPE is a type specific. OFFSET gives the number of bytes from this script record to the next. `EFI_KSCRIPT_END_TYPE' Defines the end of the script. `EFI_KSCRIPT_LOAD_TYPE' Load and start a module. The modules contents is inlined in the record. Also provided is the command line, which will be passed to the module as a load option. Signature of the record: struct efi_kscript_load { efi_kscript_t header; efi_uint32_t cmdline; efi_uint32_t size; efi_uint8_t data[0]; }; CMDLINE is an offset from the record to a NUL-terminated unicode string. SIZE is the length of the module data in bytes. `EFI_KSCRIPT_CONNECT_TYPE' Connect drivers to the device path that is inlined in the record. struct efi_kscript_connect { efi_kscript_t header; efi_device_path_t path; }; `EFI_KSCRIPT_SET_TYPE' Set variable to point to the handle specified by the inlined device path. struct efi_kscript_set { efi_kscript_t header; efi_device_path_t path; }; The SUBTYPE if the generic header specifies what variable is to be set. The following variables are available; * EFI_KSCRIPT_SET_CONIN_SUBTYPE * EFI_KSCRIPT_SET_CONOUT_SUBTYPE * EFI_KSCRIPT_SET_CONERR_SUBTYPE 6.3 Internal Protocols ====================== GNUFI uses a set of internally defined protocols to communicate between different modules. This section tries to describe them more in detail. 6.3.1 Variable Store -------------------- The internal `variable store' protocol is used to provide storage for variables that can be accessed through the runtime services. The protocol exposes characteristics of the store along with a set of functions used to read, clear and update the contents of the store. The store is divided into a number of banks, where each bank can be read and updated individually. 6.3.1.1 Interface ................. The interface provided by the `variable store' protocol has the following functions and variables: -- Variable Store: efi_uint32_t revision Revision of the interface, should be `EFI_VARIABLE_STORE_PROTOCOL_REVISION'. -- Variable Store: efi_uint32_t attributes Attributes of the store. See related defintions below for a list of available attributes. -- Variable Store: efi_uint_t bank_size Size in bytes of each bank in the store. -- Variable Store: efi_uint_t num_banks Number of banks that the store presents. -- Variable Store: efi_status_t read (efi_variable_store_t *THIS, efi_uint_t BANK, void *BUFFER) Read the content of bank BANK into buffer BUFFER. The buffer must at least be able to hold the amount of data that the store defines for a bank. -- Variable Store: efi_status_t update (efi_variable_store_t *THIS, efi_uint_t BANK, void *BUFFER) Update the content of bank BANK with the data in buffer BUFFER. The buffer msut at least hold the amount of data that the store defined for a bank. -- Variable Store: efi_status_t clear (efi_variable_store_t *THIS, efi_uint_t BANK) Reset content of bank BANK. 6.3.1.2 Related Definitions ........................... #define EFI_VARIABLE_STORE_GUID (efi_guid_t) \ { 0xdfc23a79, 0xd3f9, 0x4a0e, \ { 0xac, 0xcb, 0x7f, 0x11, 0xf1, 0x53, 0xf2, 0xa7 } \ } The protocol interface contains an ATTRIBUTES variable that defines under what situations the store can be used; `EFI_VARIABLE_STORE_NONVOLATILE' The store provides nonvolatile storage. Variables will survive a power-cycle. `EFI_VARIABLE_STORE_BOOT_SERVICE' The store is only available while the boot services are still running. `EFI_VARIABLE_STORE_RUNTIME' The store is available in runtime mode; i.e, after boot services has been terminated. The protocol interface contains a revision member that defines the version of the interface. All future versions of the interface will be compatible. If non-compatible changes have to be introduced, a new guid will be allocated for the protocol. `EFI_VARIABLE_STORE_PROTOCOL_REVISION' Protocol interface revision. 7 Concept Index *************** EFI_VARIABLE_STORE_BOOT_SERVICE: See 6.3.1.2. (line 733) EFI_VARIABLE_STORE_GUID: See 6.3.1.2. (line 720) EFI_VARIABLE_STORE_NONVOLATILE: See 6.3.1.2. (line 729) EFI_VARIABLE_STORE_PROTOCOL_REVISION: See 6.3.1.2. (line 746) EFI_VARIABLE_STORE_RUNTIME: See 6.3.1.2. (line 737) gnufi-mkimage: See 2.2. (line 119) kscript <1>: See 6.2. (line 601) kscript <2>: See 4. (line 168) kscript <3>: See 2.4. (line 146) kscript <4>: See 2.3. (line 134) kscript: See 1. (line 73) 8 Function Index **************** clear: See 6.3.1.1. (line 715) efi_argp_parse: See 5.1.4. (line 362) efi_argp_parse_hook_t: See 5.1.4. (line 351) efi_device_path_add_to_handle: See 5.1.2. (line 253) efi_device_path_build: See 5.1.2. (line 262) efi_device_path_get_from_handle: See 5.1.2. (line 257) efi_device_path_iterate: See 5.1.2. (line 268) efi_fshelp_install_protocol_interface: See 5.2. (line 475) efi_fshelp_read_helper: See 5.2. (line 529) efi_install_protocol_interface: See 5.1.1. (line 235) efi_malloc: See 5.1.5. (line 438) efi_mm_alloc: See 6.1. (line 586) efi_mm_init: See 6.1. (line 567) efi_mm_set: See 6.1. (line 575) efi_palloc: See 5.1.5. (line 450) efi_pfree: See 5.1.5. (line 454) efi_uninstall_protocol_interface: See 5.1.1. (line 241) efi_wstrcmp: See 5.1.3. (line 276) efi_wstrcpy: See 5.1.3. (line 289) efi_wstricmp: See 5.1.3. (line 285) efi_wstrlen: See 5.1.3. (line 298) efi_wstrncmp: See 5.1.3. (line 280) efi_wstrncpy: See 5.1.3. (line 294) getinfo: See 5.2. (line 494) mount: See 5.2. (line 484) read <1>: See 6.3.1.1. (line 703) read: See 5.2. (line 515) readdir: See 5.2. (line 505) reference: See 5.2. (line 487) release: See 5.2. (line 490) setinfo: See 5.2. (line 500) update: See 6.3.1.1. (line 709)