[U-Boot] [PATCH v7 2/3] mmc: meson: add MMC driver for Meson GX (S905)

[Alexander Graf]

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