On 15.04.17 21:13, Heinrich Schuchardt wrote:
On 04/15/2017 08:27 PM, Alexander Graf wrote:
On 15.04.17 20:18, Heiner Kallweit wrote:
Am 15.04.2017 um 17:05 schrieb Andreas Färber:
Am 14.04.2017 um 08:22 schrieb Jaehoon Chung:
On 04/13/2017 03:30 AM, Heiner Kallweit wrote:
From: Carlo Caione <ca...@caione.org>
This driver implements MMC support on Meson GX (S905) based systems.
It's based on Carlo Caione's work, changes:
- BLK support added
- general refactoring
Signed-off-by: Carlo Caione <ca...@caione.org>
Signed-off-by: Andreas Färber <afaer...@suse.de>
Signed-off-by: Heiner Kallweit <hkallwe...@gmail.com>
Applied to u-boot-mmc. Thanks!
Thanks guys for all the work on this!
I have tested it successfully on the Odroid-C2.
But for the Vega S95 Telos I needed to disable the first of three MMC
nodes (SDIO) - otherwise U-Boot would happily iterate over them for
distro boot with Heinrich's patch, but GRUB would come up with no disks,
so that booting failed. I'm not yet sure why, maybe it's a UEFI-side
problem in that it is the first MMC device that is absent rather than
the last one?
I don't own this device so I can just provide a guess.
Based on DT the device ordering most likely is:
mmc0: SDIO
mmc1: SD
mmc2: eMMC
sd_emmc_a - Wireless SDIO Module
sd_emmc_b - SD card
sd_emmc_c - eMMC
I'm not familiar with distro boot, but as far as I understand Heinrich's
patch it just adds mmc0 and mmc1. Therefore distro boot doesn't try to
boot from eMMC.
I will resubmit https://patchwork.ozlabs.org/patch/750859/
odroid-c2: enable MMC as boot target
with 3 MMC targets.
I have tested on my Odroid C2 that the fallthrough to DHCP is still
working with 3 defined MMC targets.
If grub comes up, distro boot has successfully found the target binary
and executed it. For some reason, grub can not find its boot origin though.
You could enable
CONFIG_DISPLAY_BOARDINFO=y
CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y
Boardinfo will display the MMC devices detected.
bootefi hello
prints the number of disks detected and handed over to the EFI target.
Andreas, please add debug prints like the ones below and check that the
device names match:
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 97a0fc9..a98cd95 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -364,5 +364,6 @@ void efi_set_bootdev(const char *dev, const char
*devnr, const char *path)
} else {
snprintf(devname, sizeof(devname), "%s", path);
}
+printf("Setting boot device name to '%s'\n", devname);
ascii2unicode(bootefi_image_path[0].str, devname);
}
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 1e3dca4..f83fa0e 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -207,6 +207,7 @@ static void efi_disk_add_dev(const char *name,
if (!desc->lba)
return;
+printf("Adding disk device '%s'\n", name);
diskobj = calloc(1, objlen);
/* Fill in object data */
Alex
Wouldn't it make sense to add Alex's patch to mainline?
You usually don't want these debug messages in a proper u-boot build.
Maybe as debug prints.
We really need to simply improve on general debuggability of the efi
object model though :). I need to sit down and make grub's "lsefi" just
work. Ideally that would give us all the hints we need to find out
what's going wrong in situations like this, as it has access to all
pieces that we need.
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
