bootmeth_efi doesn't allocate any buffer to load efi in any case.
enable static buffer flag for all cases.

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

Signed-off-by: Shantur Rathore <i@shantur.com>

While booting with efi, if fdt isn't available externally,
just use the built-in one.

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

Signed-off-by: Shantur Rathore <i@shantur.com>

We need to set boot->fname before calling efi_set_bootdev
otherwise this crashes as bflow->fname is null.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

bootmeth_efi sets up bootp_arch which is read later in bootp.c
Currently bootp_arch is being set as integer string and being
read in bootp.c as hex, this sends incorrect arch value to dhcp server
which in return sends wrong file for network boot.

For ARM64 UEFI Arch value is 0xb (11), here we set environment as 11
and later is read as 0x11 and 17 is sent to dhcp server.

Setting it as hex string fixes the problem.

Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Shantur Rathore <i@shantur.com>

EFI applications can be very large and thus used to cause boot failures
when malloc() space was exhausted.

A recent changed fixed this by using the kernel_addr_r environment var
as the address of the buffer. However, it still frees the buffer when
the bootflow is discarded.

Fix this by introducing a flag to indicate whether the buffer was
allocated, or not.

Note that kernel_addr_r is not the last word here. It might be better
to use lmb to place images. But there is a lot of refactoring to do
before we can remove the environment variables. The distro scripts rely
on them so it is safe for bootstd to do so too.

Fixes: 6a8c2f9781c bootstd: Avoid allocating memory for the EFI file

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported by: Simon Glass <sjg@chromium.org>
Reported by: Shantur Rathore <i@shantur.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Shantur Rathore <i@shantur.com>

Use the correct background colour when using white-on-black.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Remove superfluous "did".

Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>

During bootstd scanning for bootdevs, if bootdev_hunt_drv() encounters
a device not found error (e.g. ENOENT), let it return a successful status
so that bootstd will continue scanning the next devices, not stopping
prematurely.

Background:

During scanning for bootflows, it's possible for bootstd to encounter a
faulty device controller. Also when the same u-boot is used for another
variant of the same board, some device controller such as SATA might
not exist.

I've found this issue while converting the Marvell Sheevaplug board to
use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
USB only, but the later variant comes with USB, MMC, and eSATA ports. We
have been using the same u-boot (starting with CONFIG_IDE and later with DM
CONFIG_SATA) for both variants. This worked well with the old
envs-scripting booting scheme.

Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This has a typo which makes the method inoperable. Correct it so that
'bootflow read' works correctly for ChromeOS.

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

Two bugs have appeared:

- arguments can have an equals sign embedded in them, which must be
  considered part of the value
- arguments must fully match the name; partial matches should be
  ignored

Fix these and add a test to cover both.

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