10 Feb, 2018

2 commits


23 Jan, 2018

6 commits


01 Dec, 2017

4 commits


12 Oct, 2017

2 commits

  • Shell.efi uses this, and supporting color attributes makes things look
    nicer. Map the EFI fg/bg color attributes to ANSI escape sequences.
    Not all colors have a perfect match, but spec just says "Devices
    supporting a different number of text colors are required to emulate the
    above colors to the best of the device’s capabilities".

    Signed-off-by: Rob Clark
    Tested-by: Heinrich Schuchardt
    Reviewed-by: Alexander Graf
    [agraf: s/unsigned/unsigned int/]
    Signed-off-by: Alexander Graf

    Rob Clark
     
  • When we don't have a real device/image path, such as 'bootefi hello',
    construct a mem-mapped device-path.

    This fixes 'bootefi hello' after devicepath refactoring.

    Fixes: 95c5553ea2 ("efi_loader: refactor boot device and loaded_image handling")
    Signed-off-by: Rob Clark
    Acked-by: Heinrich Schuchardt
    Signed-off-by: Alexander Graf

    Rob Clark
     

09 Oct, 2017

8 commits


20 Sep, 2017

9 commits

  • 1) use fputs() to reduce cache flushes from once-per-char to
    once-per-string
    2) handle \r, \t, and \b in addition to just \n for tracking
    cursor position
    3) cursor row/col are zero based, not one based

    Signed-off-by: Rob Clark
    [agraf: s/unsigned/unsigned int/]
    Signed-off-by: Alexander Graf

    Rob Clark
     
  • Signed-off-by: Rob Clark
    Signed-off-by: Alexander Graf

    Rob Clark
     
  • Similar to a "real" UEFI implementation, the bootmgr looks at the
    BootOrder and BootXXXX variables to try to find an EFI payload to load
    and boot. This is added as a sub-command of bootefi.

    The idea is that the distro bootcmd would first try loading a payload
    via the bootmgr, and then if that fails (ie. first boot or corrupted
    EFI variables) it would fallback to loading bootaa64.efi. (Which
    would then load fallback.efi which would look for \EFI\*\boot.csv and
    populate BootOrder and BootXXXX based on what it found.)

    Signed-off-by: Rob Clark
    Signed-off-by: Alexander Graf

    Rob Clark
     
  • fallback.efi (and probably other things) use UEFI's simple-file-system
    protocol and file support to search for OS's to boot.

    Signed-off-by: Rob Clark
    [agraf: whitespace fixes, unsigned fixes]
    Signed-off-by: Alexander Graf

    Rob Clark
     
  • It needs to handle more device-path node types, and also multiple levels
    of path hierarchy. To simplify this, initially construct utf8 string to
    a temporary buffer, and then allocate the real utf16 buffer that is
    returned. This should be mostly for debugging or at least not critical-
    path so an extra copy won't hurt, and is saner than the alternative.

    Signed-off-by: Rob Clark
    Signed-off-by: Alexander Graf

    Rob Clark
     
  • This is really the same thing as the efi_device_path struct.

    Signed-off-by: Rob Clark
    Signed-off-by: Alexander Graf

    Rob Clark
     
  • Helpers to construct device-paths from devices, partitions, files, and
    for parsing and manipulating device-paths.

    For non-legacy devices, this will use u-boot's device-model to construct
    device-paths which include bus hierarchy to construct device-paths. For
    legacy devices we still fake it, but slightly more convincingly.

    Signed-off-by: Rob Clark
    Signed-off-by: Alexander Graf

    Rob Clark
     
  • Signed-off-by: Peter Jones
    Signed-off-by: Rob Clark
    Signed-off-by: Alexander Graf

    Peter Jones
     
  • All of the device-path related structures should be packed. UEFI
    defines the device-path as a byte-aligned data structure.

    Signed-off-by: Rob Clark
    Signed-off-by: Alexander Graf

    Rob Clark
     

25 Jul, 2017

1 commit

  • shim.efi (or rather gnu-efi's LibLocateProtocol() which shim.efi uses)
    resolves protocols via efi_locate_handle() so the console protocols
    need to be added to the efi object list.

    Signed-off-by: Rob Clark
    [agraf: whitespace fixes]
    Signed-off-by: Alexander Graf

    Rob Clark
     

24 Jul, 2017

1 commit

  • The first argument 'type' of CreateEvent is an 32bit unsigned
    integer bitmap and not an enum.

    The second argument 'type' of SetTimer take values of an
    enum which is called EFI_TIMER_DELAY in the UEFI standard.
    To avoid confusion rename efi_event_type to efi_timer_delay.

    Reported-by: Alexander Graf
    Signed-off-by: Heinrich Schuchardt
    Signed-off-by: Alexander Graf

    xypron.glpk@gmx.de
     

19 Jul, 2017

5 commits


03 Jul, 2017

1 commit

  • The UEFI specification states that the tpl, function and context
    arguments are to be ignored if neither EVT_NOTIFY_WAIT or
    EVT_NOTIFY_SIGNAL are specified. This matches observed behaviour with
    an AMI EDK2 based UEFI implementation.

    Skip calling the notify function if neither flag is present.

    Signed-off-by: Jonathan Gray
    Acked-By: Heinrich Schuchardt
    Signed-off-by: Alexander Graf

    Jonathan Gray
     

15 Nov, 2016

1 commit