On 11/17/2017 08:47 AM, Stefan Roese wrote:
When trying to load an image from a non-existent USB key, U-Boot v2017.11
crashes on my x86 platform:
=> load usb 0:1 03000000 abc
General Protection
EIP: 0010:[<7b59030d>] EFLAGS: 00010286
Original EIP :[<fff4330d>]
...
This used to work in v2017.09. Testing has shown, that this bug was
introduced with patch 95c5553e [efi_loader: refactor boot device and
loaded_image handling].
This patch now checks if a valid "desc" is returned from blk_get_dev()
and only continues when "desc" is available. Resulting in this cmd
output (again):
=> load usb 0:1 03000000 abc
** Bad device usb 0 **
Signed-off-by: Stefan Roese <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Heinrich Schuchardt <[email protected]>
Cc: Alexander Graf <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: Bin Meng <[email protected]>
---
cmd/bootefi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 478bc116e2..b468a20d82 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -390,6 +390,8 @@ void efi_set_bootdev(const char *dev, const char *devnr,
const char *path)
int part;
desc = blk_get_dev(dev, simple_strtol(devnr, NULL, 10));
+ if (!desc)
+ return;
part = parse_partnum(devnr);
bootefi_device_path = efi_dp_from_part(desc, part);
blk_get_dev can return NULL. We should abort efi_set_bootdev() when
receiving this value.
But I could not reproduce your problem on qemu-x86_64.
Reviewed-by: Heinrich Schuchardt <[email protected]>
_______________________________________________
U-Boot mailing list
[email protected]
https://lists.denx.de/listinfo/u-boot
