We need to do something different for vidconsole, since it cannot
respond to the query on stdin. Prep work for next patch.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
These should be set according to the image type. Shell.efi and SCT.efi
use these fields to determine what sort of image they are loading.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
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 <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things. If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload. (For
example, fallback.efi configuring BootOrder and BootXXXX load-option
variables.)
Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky. One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt. Whatever the solution, it
likely involves some per-board support.
Mapping between EFI variables and u-boot variables:
efi_$guid_$varname = {attributes}(type)value
For example:
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
"{ro,boot,run}(blob)0000000000000000"
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
"(blob)00010000"
The attributes are a comma separated list of these possible
attributes:
+ ro - read-only
+ boot - boot-services access
+ run - runtime access
NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).
If not specified, the attributes default to "{boot}".
The required type is one of:
+ utf8 - raw utf8 string
+ blob - arbitrary length hex string
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This avoids printf() spam about file reads (such as loading an image)
into unaligned buffers (and the associated memcpy()). And generally
seems like a good idea.
Signed-off-by: Rob Clark <robdclark@gmail.com>
[agraf: use __aligned]
Signed-off-by: Alexander Graf <agraf@suse.de>
Previously we only supported the case when the EFI application loaded
the image into memory for us. But fallback.efi does not do this.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
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 <robdclark@gmail.com>
[agraf: whitespace fixes, unsigned fixes]
Signed-off-by: Alexander Graf <agraf@suse.de>
Get rid of the hacky fake boot-device and duplicate device-path
constructing (which needs to match what efi_disk and efi_net do).
Instead convert over to use efi_device_path helpers to construct
device-paths, and use that to look up the actual boot device.
Also, extract out a helper to plug things in properly to the
loaded_image. In a following patch we'll want to re-use this in
efi_load_image() to handle the case of loading an image from a
file_path.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Also, create disk objects for the disk itself, in addition to the
partitions. (UEFI terminology is a bit confusing, a "disk" object is
really a partition.) This helps grub properly identify the boot device
since it is trying to match up partition "disk" object with it's parent
device.
Now instead of seeing devices like:
/File(sdhci@07864000.blk)/EndEntire
/File(usb_mass_storage.lun0)/EndEntire
You see:
/ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire
/ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c00000000,1,1)/EndEntire
/ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,200000,dd904a8c00000000,1,1)/EndEntire
/ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c00000000,1,1)/EndEntire
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,60000,38ca680200000000,1,1)/EndEntire
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca680200000000,1,1)/EndEntire
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca680200000000,1,1)/EndEntire
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca680200000000,1,1)/EndEntire
This is on a board with single USB disk and single sd-card. The
UnknownMessaging(1d) node in the device-path is the MMC device,
but grub_efi_print_device_path() hasn't been updated yet for some
of the newer device-path sub-types.
This patch is inspired by a patch originally from Peter Jones, but
re-worked to use efi_device_path, so it doesn't much resemble the
original.
Signed-off-by: Rob Clark <robdclark@gmail.com>
[agraf: s/unsigned/unsigned int/]
Signed-off-by: Alexander Graf <agraf@suse.de>
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 <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This is really the same thing as the efi_device_path struct.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
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 <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
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 <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
EFI client programs need the signature information from the partition
table to determine the disk a partition is on, so we need to fill that
in here.
Signed-off-by: Peter Jones <pjones@redhat.com>
[separated from efi_loader part, and fixed build-errors for non-
CONFIG_EFI_PARTITION case]
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
Prep work for next patch.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Check that the notification function of an
EVT_SIGNAL_EXIT_BOOT_SERVICES event is called
exactly once.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
All events of type EVT_SIGNAL_EXIT_BOOT_SERVICES have to be
notified when ExitBootServices is invoked.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Run a 10 ms periodic timer and check that it is called 10 times
while waiting for 100 ms single shot timer.
Raise the TPL level to the level of the 10 ms timer and observe
that the notification function is not called again.
Lower the TPL level and check that the queued notification
function is called.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
This unit test uses timer events to check the implementation
of the following boottime services:
CreateEvent, CloseEvent, WaitForEvent, CheckEvent, SetTimer
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
We should be able to call efi_set_timer repeatedly.
So let us reset the signaled state here.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
For the correct implementation of the task priority level (TPL)
calling the notification function must be queued.
Add a status field 'queued' to events.
In function efi_signal_event set status queued if a notification
function exists and reset it after we have called the function.
A later patch will add a check of the TPL here.
In efi_create_event and efi_close_event unset the queued status.
In function efi_wait_for_event and efi_check_event
queue the notification function.
In efi_timer_check call the efi_notify_event
if the status queued is set.
For all timer events set status signaled.
In efi_console_timer_notify set the signaled state of the
WaitForKey event.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
A Python test script is provided that runs the EFI selftest
if CONFIG_CMD_EFI_SELFTEST=y.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
A testing framework for the EFI API is provided.
It can be executed with the 'bootefi selftest' command.
It is coded in a way that at a later stage we may turn it
into a standalone EFI application. The current build system
does not allow this yet.
All tests use a driver model and are run in three phases:
setup, execute, teardown.
A test may be setup and executed at boottime,
it may be setup at boottime and executed at runtime,
or it may be setup and executed at runtime.
After executing all tests the system is reset.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Macro EFI_CALL was introduced to call an UEFI function.
Unfortunately it does not support return values.
Most UEFI functions have a return value.
So let's rename EFI_CALL to EFI_CALL_VOID and introduce a
new EFI_CALL macro that supports return values.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Fix typo in teh EFI_BOOT_SERVICES_CODE description.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
We should use the predefined constants EFI_PAGE_SHIFT
and EFI_PAGE_MASK where applicable.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
The UEFI spec allows an EFI system partition (ESP, with the bootloader or
kernel EFI apps on it) to reside on a disk using a "legacy" MBR
partitioning scheme.
But in contrast to actual legacy disks the ESP is not marked as
"bootable" using bit 7 in byte 0 of the legacy partition entry, but is
instead using partition *type* 0xef (in contrast to 0x0b or 0x0c for a
normal FAT partition). The EFI spec isn't 100% clear on this, but it even
seems to discourage the use of the bootable flag for ESPs.
Also it seems that some EFI implementations (EDK2?) even seem to ignore
partitions marked as bootable (probably since they believe they contain
legacy boot code).
The Debian installer [1] (*not* mini.iso), for instance, contains such an
MBR, where none of the two partitions are marked bootable, but the ESP
has clearly type 0xef.
Now U-Boot cannot find the ESP on such a disk (USB flash drive) and
fails to load the EFI grub and thus the installer.
Since it all boils down to the distro bootcmds eventually calling
"part list -bootable" to find potential boot partitions, it seems logical
to just add this "partition type is 0xef" condition to the is_bootable()
implementation.
This allows the bog standard arm64 Debian-testing installer to boot from
an USB pen drive on Allwinner A64 boards (Pine64, BananaPi-M64).
(Ubuntu and other distribution installers don't have a legacy MBR, so
U-Boot falls back to El Torito there).
[1] https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Variable always should only be appended but not overwritten by
lib/efi_loader/Makefile.
Remove variable efiprogs which is not otherwise used.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Replace all occurences of helloworld by generalized forms.
This allows us to build additional EFI applications that are
included into the U-Boot binary without loading
scripts/Makefile.lib with specific filenames.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
In scripts/Makefile.lib we build section including helloworld.efi.
This allows to load the EFI binary with command 'bootefi hello'.
scripts/Makefile.lib contains explicit references to strings
containing helloworld and hello_world. This makes it impossible
to generalize the coding to accomodate additional built in
EFI binaries.
Let us rename the variables __efi_hello_world_* to
__efi_helloworld_*.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
The target
$(obj)/helloworld.so:
exists twice in Makefile.lib.
If you add an echo command to each of the two recipes you get
warnings like:
scripts/Makefile.lib:383: warning:
overriding recipe for target 'drivers/power/battery/helloworld.so'
scripts/Makefile.lib:379: warning:
ignoring old recipe for target 'drivers/power/battery/helloworld.so'
This patch removes the obsolete target.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Commit f494950b (efi_loader: call __efi_exit_check in efi_exit) added a call
to __efi_exit_check inside efi_exit to account for the fact that we're exiting
the efi_exit function via a longjmp call.
However, __efi_exit_check also swizzles gd to the application gd while the
longjmp will put us back into EFI context, so we need the efi (u-boot) gd.
This patch fixes that up by explicitly setting gd back to efi_gd before
doing the longjmp. It also adds a few comments on why it does that.
Signed-off-by: Alexander Graf <agraf@suse.de>
To understand what is happening in OpenProtocol or LocateProtocol
it is necessary to know the protocol interface GUID.
Let's write a debug message.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
The calls to __efi_entry_check and __efi_exit_check have to match.
If DEBUG is defined, panic() will be called otherwise.
If debugging is activated some Travis CI builds fail due to an
assertion in EFI_CALL without the patch.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
There is no need to use attribute EFIAPI for
efi_disk_rw_blocks. It is not an API function.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Command 'bootefi hello' currently uses CONFIG_SYS_LOAD_ADDR
as loading address.
qemu machines have by default 128 MiB RAM.
CONFIG_SYS_LOAD_ADDR for x86 is 0x20000000 (512 MiB).
This causes 'bootefi hello' to fail.
We should use the environment variable loadaddr if available.
It defaults to 0x1000000 (16 MiB) on qemu_x86.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
legacy_hole_base_k and legacy_hole_size_k are defined but
not used.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Enable this option for link so that the timer is available earlier.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With SPL we often have limited memory and do not need very many bootstage
records. Add a separate Kconfig option for SPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The CONFIG_BOOTSTAGE_USER_COUNT option is no-longer needed since we can now
support any number of user IDs. Also BOOTSTAGE_ID_COUNT is not needed now.
Drop these unused options.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
With bootstage we need access to the timer before driver model is set up.
To handle this, put the required state in global_data and provide a new
function to set up the device, separate from the driver's probe() method.
This will be used by the 'early' timer also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Once U-Boot relocates itself the existing driver-model timer (if any) is
no-longer valid until the device is reinitialised. Any use of the device
may cause a crash. To handle this, set the timer to NULL after relocation.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This adds support to Intel Cherry Hill board, a board based on
Intel Braswell SoC. The following devices are validated:
- serial port as the serial console
- on-board Realtek 8169 ethernet controller
- SATA AHCI controller
- EMMC/SDHC controller
- USB 3.0 xHCI controller
- PCIe x1 slot with a graphics card
- ICH SPI controller with an 8MB Macronix SPI flash
- Integrated graphics device as the video console
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
FSP's built-in UPD configuration enables PUNIT power configuration,
but on B0 stepping, this causes CPU hangs in fsp_init(). Disable it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rob Clark
Peter Jones
Heinrich Schuchardt
Andre Przywara
Alexander Graf
Tom Rini
Simon Glass
Bin Meng