On Tue, Sep 12, 2017 at 8:30 AM, Simon Glass sjg@chromium.org wrote:
Hi Rob,
On 10 September 2017 at 05:21, Rob Clark robdclark@gmail.com wrote:
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: Rob Clark robdclark@gmail.com
include/efi_api.h | 10 + include/efi_loader.h | 26 ++ lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_boottime.c | 13 +- lib/efi_loader/efi_device_path.c | 563 +++++++++++++++++++++++++++++++++++++++ 5 files changed, 611 insertions(+), 3 deletions(-) create mode 100644 lib/efi_loader/efi_device_path.c
Since this is new code we should not need the ifdef CONFIG_BLK, DM_MMC, etc. here, right?
Alexander was pretty much against dropping support for legacy devices.. so I think we need that.
There are a bunch of different places where efi_loader can be cleaned up when we require DM..
The deadline for CONFIG_BLK has been set as 2018.05.
Also can we add some simple unit tests for this code somewhere?
Getting some Shell.efi into the py tests would exercise this and a whole lot more. Although I think we need to add an aarch64 qemu device to travis?
BR, -R