- 01 12月, 2017 4 次提交
-
-
由 Heinrich Schuchardt 提交于
Environment variable efi_selftest is passed as load options to the selftest application. It is used to select a single test to be executed. The load options are an UTF8 string. Yet I decided to keep the name propertiy of the tests as char[] to reduce code size. Special value 'list' displays a list of all available tests. Tests get an on_request property. If this property is set the tests are only executed if explicitly requested. The invocation of efi_selftest is changed to reflect that bootefi selftest with efi_selftest = 'list' will call the Exit bootservice. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Heinrich Schuchardt 提交于
Currently we pass bootefi_device_path and bootefi_image_path as device and image path without initializing them. They may carry values from previous calls to bootefi. With the patch the variables are initialized valid dummy values. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Heinrich Schuchardt 提交于
Where ulong or unsigned long are used to hold an EFI status code we should consistenly use efi_status_t. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Heinrich Schuchardt 提交于
The watchdog is initialized with a 5 minute timeout period. It can be reset by SetWatchdogTimer. It is stopped by ExitBoottimeServices. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 12 10月, 2017 1 次提交
-
-
由 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: 95c5553e ("efi_loader: refactor boot device and loaded_image handling") Signed-off-by: NRob Clark <robdclark@gmail.com> Acked-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 21 9月, 2017 2 次提交
-
-
由 Rob Clark 提交于
efi_exit() already restores gd, so we shouldn't EFI_EXIT() on the otherside of the longjmp(). Signed-off-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Heinrich Schuchardt 提交于
ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling leads to an error when building with CONFIG_CMD_BOOTEFI_SELFTEST=y This patch fixes the problem. Fixes: ad503ffe9c6 efi_loader: refactor boot device and loaded_image handling Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 20 9月, 2017 3 次提交
-
-
由 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: NRob Clark <robdclark@gmail.com> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Rob Clark 提交于
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: NRob Clark <robdclark@gmail.com> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 19 9月, 2017 3 次提交
-
-
由 Heinrich Schuchardt 提交于
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: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Heinrich Schuchardt 提交于
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: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Heinrich Schuchardt 提交于
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: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 12 8月, 2017 1 次提交
-
-
由 xypron.glpk@gmx.de 提交于
We should use constant EFI_PAGE_SIZE instead of 4096 where the coding relies on 4096 being EFI_PAGE_SIZE. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 26 7月, 2017 1 次提交
-
-
由 Alexander Graf 提交于
Before commit 7cbc1241 ("efi_loader: initalize EFI object list only once") we recreated the world on every bootefi invocation. That included the object tree as well as the configuration tables. Now however we don't recreate them, which means we must not explicitly override the configuration tables, as otherwise we may lose our SMBIOS table from the configuration table list on second bootefi invocation. This patch makes bootefi call our normal configuration table modification APIs to add/remove the FDT instead of recreating all tables from scratch. That way the SMBIOS table gets preserved across multiple invocations. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 24 7月, 2017 3 次提交
-
-
由 Heinrich Schuchardt 提交于
If several EFI applications are executed in sequence we want to keep the content of the EFI object list. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Rob Clark 提交于
Make EFI GOP support work with DM_VIDEO but without legacy LCD. Signed-off-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Rob Clark 提交于
shim.efi, for example, actually tries to parse this, but is expecting backslashes. Signed-off-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 19 7月, 2017 6 次提交
-
-
由 xypron.glpk@gmx.de 提交于
Set up a timer event and the WaitForKey event. In the notify function of the timer event check for console input and signal the WaitForKey event accordingly. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 xypron.glpk@gmx.de 提交于
Currenty any EFI status other than EFI_SUCCESS is reported as Application terminated, r = -22 With the patch the status code returned by the EFI application is printed. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 xypron.glpk@gmx.de 提交于
The Unified Extensible Firmware Interface Specification, version 2.7, defines in chapter 2.1.2 - UEFI Application that an EFI application may either directly return or call EFI_BOOT_SERVICES.Exit(). Unfortunately U-Boot makes the incorrect assumption that EFI_BOOT_SERVICES.Exit() is always called. So the following application leads to a memory exception on the aarch64 architecture when returning: EFI_STATUS efi_main( EFI_HANDLE handle, EFI_SYSTEM_TABlE systable) { return EFI_SUCCESS; } With this patch the entry point is stored in the image handle. The new wrapper function do_enter is used to call the EFI entry point. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 xypron.glpk@gmx.de 提交于
ConvertPathToText is implemented for * type 4 - media device path * subtype 4 - file path This is the kind of device path we hand out for block devices. All other cases may be implemented later. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> [agraf: fix whitespace] Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 xypron.glpk@gmx.de 提交于
The UEFI specification requires that LocateProtol finds the first handle supporting the protocol and to return a pointer to its interface. So we have to assign the protocols to an efi_object and not use any separate storage. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 xypron.glpk@gmx.de 提交于
efi_open_protocol was implemented to call a protocol specific open function to retrieve the protocol interface. The UEFI specification does not know of such a function. It is not possible to implement InstallProtocolInterface with the current design. With the patch the protocol interface itself is stored in the list of installed protocols of an efi_object instead of an open function. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> [agraf: fix efi gop support] Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 03 7月, 2017 1 次提交
-
-
由 Alexander Graf 提交于
When running bootefi, we allocate new space but never check whether the allocation succeeded. This patch adds a check so that in case things go wrong, we at least know they did. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 01 6月, 2017 1 次提交
-
-
由 Simon Glass 提交于
This header includes things that are needed to make driver build. Adjust existing users to include that always, even if other dm/ includes are present Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 28 1月, 2017 1 次提交
-
-
由 Patrick Delaunay 提交于
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com> Signed-off-by: NPatrick Delaunay <patrick.delaunay73@gmail.com>
-
- 19 1月, 2017 1 次提交
-
-
由 Alison Wang 提交于
For 64-bit kernel, there is a warning about x1-x3 nonzero in violation of boot protocol. To fix this issue, input argument 4 is added for armv8_switch_to_el2 and armv8_switch_to_el1. The input argument 4 will be set to the right value, such as zero. Signed-off-by: NAlison Wang <alison.wang@nxp.com> Reviewed-by: NAlexander Graf <agraf@suse.de> Tested-by: NRyan Harkin <ryan.harkin@linaro.org> Tested-by: NMichal Simek <michal.simek@xilinx.com> Reviewed-by: NYork Sun <york.sun@nxp.com>
-
- 23 11月, 2016 1 次提交
-
-
由 Alison Wang 提交于
To support loading a 32-bit OS, the execution state will change from AArch64 to AArch32 when jumping to kernel. The architecture information will be got through checking FIT image, then U-Boot will load 32-bit OS or 64-bit OS automatically. Signed-off-by: NEbony Zhu <ebony.zhu@nxp.com> Signed-off-by: NAlison Wang <alison.wang@nxp.com> Signed-off-by: NChenhui Zhao <chenhui.zhao@nxp.com> Reviewed-by: NYork Sun <york.sun@nxp.com>
-
- 17 11月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
Some boards decided not to run ATF or other secure firmware in EL3, so they instead run U-Boot there. The uEFI spec doesn't know what EL3 is though - it only knows about EL2 and EL1. So if we see that we're running in EL3, let's get into EL2 to make payloads happy. Signed-off-by: NAlexander Graf <agraf@suse.de> Reviewed-by: NYork Sun <york.sun@nxp.com>
-
- 15 11月, 2016 2 次提交
-
-
由 Simon Glass 提交于
It is useful to have a basic sanity check for EFI loader support. Add a 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot. Signed-off-by: NSimon Glass <sjg@chromium.org> [agraf: Fix documentation, add unfulfilled kconfig dep] Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Simon Glass 提交于
This should use U-Boot's standard format for hex address. Fix it. Signed-off-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 19 10月, 2016 3 次提交
-
-
由 Alexander Graf 提交于
When you boot an efi payload from network, then exit that payload and load another payload from disk afterwords, the disk payload will currently see the network device as its boot path. This breaks grub2 for example which tries to find its modules based on the path it was loaded from. This patch fixes that issue by always reverting to disk paths if we're not in the network boot. That way the data structures after a network boot look the same as before. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Simon Glass 提交于
These are missing in some functions. Add them to keep things consistent. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NAlexander Graf <agraf@suse.de> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Alexander Graf 提交于
We can pass SMBIOS easily as EFI configuration table to an EFI payload. This patch adds enablement for that case. While at it, we also enable SMBIOS generation for ARM systems, since they support EFI_LOADER. Signed-off-by: NAlexander Graf <agraf@suse.de> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
- 18 10月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
EFI allows an OS to leverage firmware drivers while the OS is running. In the generic code we so far had to stub those implementations out, because we would need board specific knowledge about MMIO setups for it. However, boards can easily implement those themselves. This patch provides the framework so that a board can implement its own versions of get_time and reset_system which would actually do something useful. While at it we also introduce a simple way for code to reserve MMIO pointers as runtime available. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 20 8月, 2016 1 次提交
-
-
由 Bin Meng 提交于
When typing 'bootefi' from U-Boot shell, nothing outputs. Like other commands, return CMD_RET_USAGE so that it can print help message. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NAlexander Graf <agraf@suse.de>
-
- 09 8月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
When using CONFIG_BLK, there were 2 issues: 1) The name we generate the device with has to match the name we set in efi_set_bootdev() 2) The device we pass into our block functions was wrong, we should not rediscover it but just use the already known pointer. This patch fixes both issues. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 26 7月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
When loading an efi image, we pass it the location it was loaded from. On file system backends, there are no relative paths, so we should always pass in absolute ones. For network paths, we may be relative. This fixes distro booting with grub2 for me when it fetches the grub2 config file from the loader partition. Reported-by: Nyork sun <york.sun@nxp.com> Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 25 6月, 2016 1 次提交
-
-
由 Sergey Kubushyn 提交于
Short help (description) in bootefi command has a trailing "\n" that breaks the "help" command output (empty line after "bootefi"). Nothing important, doesn't affect anything but better be fixed in the upcoming release. Still working on i.MX6 and their siblings NAND U-Boot update -- it works here but not ready for a submission yet. Anyway it is for the next cycle, not going to go into this release because it is too big and may affect something else. Also have some thoughts about fastboot (using multiple devices) but this will go into separate email with RFC. Signed-off-by: NSergey Kubushyn <ksi@koi8.net>
-