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 carlo@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 carlo@caione.org Signed-off-by: Andreas Färber afaerber@suse.de Signed-off-by: Heiner Kallweit hkallweit1@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