- 24 7月, 2017 1 次提交
-
-
由 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>
-
- 07 6月, 2016 2 次提交
-
-
由 Alexander Graf 提交于
We introduced special "DEBUG_EFI" defines when the efi loader support was new. After giving it a bit of thought, turns out we really didn't have to - the normal #define DEBUG infrastructure works well enough for efi loader as well. So this patch switches to the common debug() and #define DEBUG way of printing debug information. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Alexander Graf 提交于
Some times you may want to exit an EFI payload again, for example to default boot into a PXE installation and decide that you would rather want to boot from the local disk instead. This patch adds exit functionality to the EFI implementation, allowing EFI payloads to exit. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 27 5月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
We can now successfully boot EFI applications from disk, but users may want to also run them from a PXE setup. This patch implements rudimentary network support, allowing a payload to send and receive network packets. With this patch, I was able to successfully run grub2 with network access inside of QEMU's -M xlnx-ep108. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 19 4月, 2016 6 次提交
-
-
由 Alexander Graf 提交于
The bootefi cmd today fetches its device tree pointer from either the location appointed by "fdt addr" with a fallback to the U-Boot control fdt. This integration is unusual for U-Boot and diverges from the way we usually handle parameters to boot commands. So let's pass the fdt directly into the bootefi command instead and move the control fdt logic into the distro boot script. Signed-off-by: NAlexander Graf <agraf@suse.de> Acked-by: NStephen Warren <swarren@wwwdotorg.org> Reviewed-by: NAndreas Färber <afaerber@suse.de>
-
由 Alexander Graf 提交于
The uEFI spec doesn't dictate where the device tree should live at, but legacy 32bit ARM grub2 has some assumptions that it may stay at its place when it's already loaded by the firmware. So let's put it somewhere where Linux that comes after would happily find it - around the recommended 128MB line. Signed-off-by: NAlexander Graf <agraf@suse.de> Tested-by: NAndreas Färber <afaerber@suse.de>
-
由 Alexander Graf 提交于
When the user did not pass any device tree or the boot script didn't find any, let's use the system device tree as last resort to get something the payload (Linux) may understand. This means that on systems that use the same device tree for U-Boot and Linux we can just share it and there's no need to manually provide a device tree in the target image. While at it, also copy and pad the device tree by 64kb to give us space for modifications. Signed-off-by: NAlexander Graf <agraf@suse.de> Tested-by: NAndreas Färber <afaerber@suse.de>
-
由 Alexander Graf 提交于
Whenever we want to tell our payload about a path, we limit ourselves to a reasonable amount of characters. So far we only passed in device names - exceeding 16 chars was unlikely there. However by now we also pass real file path information, so let's increase the limit to 32 characters. That way common paths like "boot/efi/bootaa64.efi" fit just fine. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Alexander Graf 提交于
The payload gets information on where it got loaded from. This includes the device as well as file path. So far we've treated both as the same thing and always gave it the device name. However, in some situations grub2 actually wants to find its loading path to find its configuration file. So let's split the two semantically separte bits into separate structs and pass the loaded file name into our payload when we load it using "load". Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Alexander Graf 提交于
When loading an el torito image, uEFI exposes said image as a raw block device to the payload. Let's do the same by creating new block devices with added offsets for the respective el torito partitions. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 27 3月, 2016 1 次提交
-
-
由 Alexander Graf 提交于
The EFI standard defines a simple boot protocol that an EFI payload can use to access video output. This patch adds support to expose exactly that one (and the mode already in use) as possible graphical configuration to an EFI payload. With this, I can successfully run grub2 with graphical output. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
- 16 3月, 2016 3 次提交
-
-
由 Alexander Graf 提交于
EFI payloads can query for the device they were booted from. Because we have a disconnect between loading binaries and running binaries, we passed in a dummy device path so far. Unfortunately that breaks grub2's logic to find its configuration file from the same device it was booted from. This patch adds logic to have the "load" command call into our efi code to set the device path to the one we last loaded a binary from. With this grub2 properly detects where we got booted from and can find its configuration file, even when searching by-partition. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Alexander Graf 提交于
We have a nice framework around image fils to prepare a device tree for OS execution. That one patches in missing device tree nodes and fixes up the memory range bits. We need to call that one from the EFI boot path too to get all those nice fixups. This patch adds the call. Signed-off-by: NAlexander Graf <agraf@suse.de>
-
由 Alexander Graf 提交于
In order to execute an EFI application, we need to bridge the gap between U-Boot's notion of executing images and EFI's notion of doing the same. The best path forward IMHO here is to stick completely to the way U-Boot deals with payloads. You manually load them using whatever method to RAM and then have a simple boot command to execute them. So in our case, you would do # load mmc 0:1 $loadaddr grub.efi # bootefi $loadaddr which then gets you into a grub shell. Fdt information known to U-boot via the fdt addr command is also passed to the EFI payload. Signed-off-by: NAlexander Graf <agraf@suse.de> Reviewed-by: NSimon Glass <sjg@chromium.org> Tested-by: NSimon Glass <sjg@chromium.org> [trini: Guard help text with CONFIG_SYS_LONGHELP] Signed-off-by: NTom Rini <trini@konsulko.com>
-