The gnufi User and Developer Documentation

For version 0.0, 24 October 2006

Johan Rydberg <jrydberg@gnu.org>

Copyright \begin{matrix}c \\ ◯ \end{matrix} 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

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Building GNUFI. . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Building The Firmware Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Building A Firmware Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3 The ‘gnufi-mkimage’ Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.4 Available Kernel Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Firmware Loaders. . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1 i386 Multiboot loader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

4 Board Specific Configuration Scripts . . . . . . . . 4

5 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.1 libefi: Standard UEFI API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1.1 Protocol Interface Related Functions . . . . . . . . . . . . . . . . . . . . . 5 5.1.2 Device Path Related Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1.3 String Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1.4 Parsing of Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.1.4.1 Example usage of efi argp parse . . . . . . . . . . . . . . . . . . . . . 7 5.1.5 Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.2 libefi-fshelp: File System Help Library . . . . . . . . . . . . . . . . . . . . . . . . 8

6 gnufi Internals . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6.1 Memory Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2 Kernel Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3 Internal Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.3.1 Variable Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.1.1 Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3.1.2 Related Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

7 Concept Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

8 Function Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

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 (See Chapter 3 [Loaders], page 3.). 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. See Chapter 3 [Loaders], page 3, 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. See Chapter 3 [Loaders], page 3.

2.3 The ‘gnufi-mkimage’ Utility

The ‘gnufi-mkimage’ utility takes a kernel script file as argument (See Chapter 4 [Kernel scripts], page 4.) 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 <gnu/efi/api.h> 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.

Chapter 7: Concept Index 15

7 Concept Index

E

EFI VARIABLE STORE BOOT SERVICE … 14 EFI VARIABLE STORE GUID . . . . . . . . . . . . . . 13 EFI VARIABLE STORE NONVOLATILE. … 14 EFI VARIABLE STORE PROTOCOL REVISION

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 EFI VARIABLE STORE RUNTIME . . . . . . . . . 14

G

gnufi-mkimage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

K

kscript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1, 2, 4, 12

Chapter 8: Function Index 16

8 Function Index

C

clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

E

efi_argp_parse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 efi_argp_parse_hook_t. . . . . . . . . . . . . . . . . . . . . . . 7

efi_device_path_add_to_handle . . . . . . . . . . . . . . 5

efi_device_path_build. . . . . . . . . . . . . . . . . . . . . . . 5

efi_device_path_get_from_handle . . . . . . . . . . . . 5
efi_device_path_iterate . . . . . . . . . . . . . . . . . . . . 5
efi_fshelp_install_protocol_interface . . . . . 9
efi_fshelp_read_helper . . . . . . . . . . . . . . . . . . . . . 9
efi_install_protocol_interface . . . . . . . . . . . . . 5

efi_malloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 efi_mm_alloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 efi_mm_init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 efi_mm_set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 efi_palloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 efi_pfree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

efi_uninstall_protocol_interface. . . . . . . . . . . 5

efi_wstrcmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 efi_wstrcpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 efi_wstricmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 efi_wstrlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 efi_wstrncmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 efi_wstrncpy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

G

getinfo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

M

mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

R

read. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9, 13 readdir. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

S

setinfo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

U

update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13