This reverts the parts of commit 3b3ea2c5
where it changed the EFI dependency on NET.
Signed-off-by: NJoe Hershberger <joe.hershberger@ni.com>
Reviewed-by: NDuncan Hare <dh@synoia.com>

Since the backing memory for a new device path can contain stale
data we have to make sure that we zero the buffer.  Otherwise some
code paths that don't set all fields in a structure backed by this
device path might contain unwanted stale data.
Signed-off-by: NPatrick Wildt <patrick@blueri.se>
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

When CONFIG_DM_ETH is set, we assemble the device path properly with a
full device hierarchy. Our helper function dp_fill() even put the MAC
node itself in it for us.

However, for non-DM compatibility we also have code in that added the
MAC node manually. That code now runs on top of the existing MAC node:

  Handle 0x3db2f6b0
    /HardwareVendor(e61d73b9-a384-4acc-aeab-82e828f3628b)[0: ]
    /USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/MacAddr(b8:27:eb:e1:81:47,1)
    /MacAddr(b8:27:eb:e1:81:47,57)/EndEntire

We obviously don't need the additional node and in fact, grub chokes on
it and fails to match the DP against the ethernet device node. So this
patch moves the additional MAC node into the non-DM code path:

  Handle 0x3db3fde0
    /HardwareVendor(e61d73b9-a384-4acc-aeab-82e828f3628b)[0: ]
    /USBClass(0,0,9,0,0)/USBClass(424,9514,9,0,2)/MacAddr(b8:27:eb:e1:81:47,1)
    /EndEntire

While at it, we also mark the non-DM MAC node as ethernet.

Fixes: b66c60dd ("efi_loader: add device-path utils")
Signed-off-by: NAlexander Graf <agraf@suse.de>

Enable networking command only when NET is enabled.
And remove selecting NET for CMD_NET
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NTom Rini <trini@konsulko.com>

Create device path nodes for UCLASS_ETH udevices.
Create device path nodes of block device children of UCLASS_MMC udevices.
Consistently use debug for unsupported nodes.
Set the log level to error.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
[agraf: Fix build failure by adding #ifdef CONFIG_DM_ETH]
Signed-off-by: NAlexander Graf <agraf@suse.de>

On a block device and its partitions the same protocols can be
installed. To tell the apart we can use the type of the last
node of the device path which is not the end node.

The patch provides a utility function to find this last node.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Provide new function efi_dp_part_node() to create a device
node for a partition.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

For the construction of device paths we need to call the
AllocatePool service. We should not ignore if it fails due to an
out of memory situation.

This patch changes the device path functions to return NULL if
the memory allocation fails.

Additional patches will be needed to fix the callers.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Correctly create the device path for IDE and SCSI disks.

Support for SATA remains to be done in a future patch.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

When creating the device path of a block device it has to
comprise the block device itself and should not end at
its parent.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Add a description for dp_part_fill().
Reword a comment in the function.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

According to the UEFI spec the numbering of partitions has to
start with 1.

Partion number 0 is reserved for the optional device path for
the complete block device.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

The SD cards and eMMC devices have different device nodes.
The current coding interpretes all MMC devices as eMMC.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

When calling efi_dp_find_obj(), we usually want to find the *exact* match
of an object for a given device path. However, I ran into a nasty corner case
where I had the following objects with paths available:

Handle 0x9feffa70
  /HardwareVendor(e61d73b9-a384-4acc-aeab-82e828f3628b)[0: ]/USB(6,0)/EndEntire
Handle 0x9feffb58
  /HardwareVendor(e61d73b9-a384-4acc-aeab-82e828f3628b)[0: ]/USB(6,0)/HD(1,800,32000,2de808cb00000000,1,1)/EndEntire

and was searching for

  /HardwareVendor(e61d73b9-a384-4acc-aeab-82e828f3628b)[0: ]/USB(6,0)/HD(1,800,32000,2de808cb00000000,1,1)/EndEntire

But because our device path search looked for any substring match, it would
return

  /HardwareVendor(e61d73b9-a384-4acc-aeab-82e828f3628b)[0: ]/USB(6,0)/EndEntire

because that path is a full substring of the path we were searching for.

So this patch adapts the device path search logic to always look for exact
matches first. The way we distinguish between those cases is by looking at
whether our caller actually deals with remainders.

As a side effect, the code as is from all I can tell now never does a
substring match anymore, because it always gets called with rem=NULL, so
we always only do exact matches now.
Reported-by: NJonathan Gray <jsg@jsg.id.au>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Use function efi_search_protocol().
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

Zero partition_signature in the efi_device_path_hard_drive_path
structure when signature_type is 0 (no signature) as required by the
UEFI specification.

This is required so that efi_dp_match() will work as expected
when doing memcmp() comparisons.  Previously uninitialised memory
would cause it not match nodes when it should have when the signature
type was not GUID.

Corrects a problem where the loaded image protocol would not return a
device path with MEDIA_DEVICE causing the OpenBSD bootloader to fail
on rpi_3 and other targets.

v2: Also handle signature_type 1 (MBR) as described in the specification
Signed-off-by: NJonathan Gray <jsg@jsg.id.au>
Tested-by: NArtturi Alm <artturi.alm@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

efi_dp_match does not change its arguments.
So they should be marked as const.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexander Graf <agraf@suse.de>

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>

Helpers to construct device-paths from devices, partitions, files, and
for parsing and manipulating device-paths.

For non-legacy devices, this will use u-boot's device-model to construct
device-paths which include bus hierarchy to construct device-paths.  For
legacy devices we still fake it, but slightly more convincingly.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>