There is no CONFIG_UEFI_SECURE_BOOT, and there was never any.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

The existing options, "--fit" and "--raw," are only used to put a proper
GUID in a capsule header, where GUID identifies a particular FMP (Firmware
Management Protocol) driver which then would handle the firmware binary in
a capsule. In fact, mkeficapsule does the exact same job in creating
a capsule file whatever the firmware binary type is.

To prepare for the future extension, the command syntax will be a bit
modified to allow users to specify arbitrary GUID for their own FMP driver.
OLD:
   [--fit <image> | --raw <image>] <capsule file>
NEW:
   [--fit | --raw | --guid <guid-string>] <image> <capsule file>

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>

Now we can use mkeficapsule command instead of EDK-II's script
to create a signed capsule file. So update the instruction for
capsule authentication.

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

- disable CONFIG_NET_RANDOM_ETHADDR when unnecessary on amlogic based configs
- meson64_android: add board specific env settings, in order to support VIM3/L for android
- add changes to support VIM3/L android boot by using meson64_android.h config

At present this is disabled, but it should work so long as the kernel does
not need EFI services. Enable it and add a note about remaining work.

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

When starting the app, locate all block devices and make them available
to U-Boot. This allows listing partitions and accessing files in
filesystems.

EFI also has the concept of 'disks', meaning boot media. For now, this
is not obviously useful in U-Boot, but add code to at least locate these.
This can be expanded later as needed.

We cannot use printf() in the early stub or app since it is not compiled
in

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

This is a 'y/n' selection, so fix it.
While at it remove the duplicate usage of CFG_CORE_HEAP_SIZE

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

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>

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>