These names are better used for access to devices provided by an EFI
layer. Use EFI_LOADER instead here, since these are only available in
U-Boot's EFI_LOADER layer.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Fix obvious typos. Use US spelling consistently.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

Move this over to the new rST format.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Artem Lapkin <email2tema@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>

The current EFI video driver only works when running in the stub. In that
case the stub calls boot services (before jumping to U-Boot proper) and
copies the graphics info over to the efi table. This is necessary because
the stub exits boot services before jumping to U-Boot.

The app maintains access to boot services throughout its life, so does not
need to do this. Update the driver to support calling boot services
directly.

Enable video output for the app. Note that this uses the
EFI_GRAPHICS_OUTPUT_PROTOCOL protocol, even though it mentions vesa.

A sample qemu command-line for this case is:

   qemu-system-x86_64 -bios /usr/share/edk2.git/ovmf-ia32/OVMF-pure-efi.fd
   -drive id=disk,file=try.img,if=none,format=raw -nic none
   -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Most modern platforms use 64-bit EFI so it is useful to have a U-Boot app
that runs under that. Add a (non-functional) build for this.

Note that --whole-archive causes the gcc 9.2 linker to crash, so disable
this for now. Once this is resolved, things should work.

For now, avoid mentioning the documentation for the 64-bit app, since it
does not work.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

It is quite complicated to run U-Boot on QEMU since we have four
different builds and they must use different versions of qemu and the
UEFI binaries.

Add a script to help. It requires U-Boot itself to be built. Once that
is done you can use this script to build an image for use with qemu and
optionally run it.

Signed-off-by: Simon Glass <sjg@chromium.org>

The existing intructions in the U-Boot on EFI doc do not work with
the latest QEMU. Update the doc with the correct instructions, as
well as using the new OVMF URL link.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

OF_HOSTFILE is used on sandbox configs only.  Although it's pretty
unique and not causing any confusions,  we are better of having simpler
config options for the DTB.

So let's replace that with the existing OF_BOARD.  U-Boot would then
have only three config options for the DTB origin.
- OF_SEPARATE, build separately from U-Boot
- OF_BOARD, board specific way of providing the DTB
- OF_EMBED embedded in the u-boot binary(should not be used in production

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

This reverts commit a7e4f905d206d5895dab4bd38a8316e4f2fe15fe.
The description originally written by Sughosh is still valid
even after the commit 47a25e81d35c ("Revert "efi_capsule: Move signature
from DTB to .rodata"") was applied.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

When a test hands on a real board there is no way on the console to obtain
any information about why it hung.

With sandbox we can actually find out that it died and get a signal or
exit code. Add this to make it easier to figure out what happened.

So instead of:

test/py/u_boot_spawn.py:171: in expect
    c = os.read(self.fd, 1024).decode(errors='replace')
E   OSError: [Errno 5] Input/output error

We get:

test/py/u_boot_spawn.py:171: in expect
    c = os.read(self.fd, 1024).decode(errors='replace')
E   ValueError: U-Boot exited with signal 11 (Signals.SIGSEGV)

Signed-off-by: Simon Glass <sjg@chromium.org>