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

Mon Apr 17 22:39:55 UTC 2017

On 04/18/2017 06:18 AM, Heinrich Schuchardt wrote:
> On 04/16/2017 09:34 PM, Simon Glass wrote:
>> Hi Alex,
>>
>> On 16 April 2017 at 04:08, Alexander Graf <agraf at suse.de> wrote:
>>>
>>>
>>> On 16.04.17 04:09, Heinrich Schuchardt wrote:
>>>>
>>>> On 04/15/2017 11:51 PM, Andreas Färber wrote:
>>>>>
>>>>> Am 15.04.2017 um 23:16 schrieb Andreas Färber:
>>>>>>
>>>>>> Am 15.04.2017 um 23:04 schrieb Alexander Graf:
>>>>>>>>
>>>>>>>> Am 15.04.2017 um 22:34 schrieb Andreas Färber <afaerber at suse.de>:
>>>>>>>>>
>>>>>>>>> Am 15.04.2017 um 20:27 schrieb Alexander Graf:
>>>>>>>>>>
>>>>>>>>>> On 15.04.17 20:18, Heiner Kallweit wrote:
>>>>>>>>>>>
>>>>>>>>>>> Am 15.04.2017 um 17:05 schrieb Andreas Färber:
>>>>>>>>>>> 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
>>>>>>>>
>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Andreas, please add debug prints like the ones below and check that
>>>>>>>>> the
>>>>>>>>> device names match:
>>>>>>>>
>>>>>>>>
>>>>>>>> U-Boot 2017.05-rc1-00318-g082535f-dirty (Apr 15 2017 - 22:29:17 +0200)
>>>>>>>> vega-s95
>>>>>>>>
>>>>>>>> DRAM:  2 GiB
>>>>>>>> MMC:   mmc at 70000: 0, mmc at 72000: 1, mmc at 74000: 2
>>>>>>>> Using default environment
>>>>>>>>
>>>>>>>> In:    serial at 4c0
>>>>>>>> Out:   serial at 4c0
>>>>>>>> Err:   serial at 4c0
>>>>>>>> Net:   eth0: ethernet at c9410000
>>>>>>>> Hit any key to stop autoboot:  0
>>>>>>>> mmc_init: -95, time 1806
>>>>>>>> MMC Device 0 not found
>>>>>>>> no mmc device at slot 0
>>>>>>>> switch to partitions #0, OK
>>>>>>>> mmc1 is current device
>>>>>>>> Scanning mmc 1:1...
>>>>>>>> Setting boot device name to '//boot/dtb/amlogic/meson-gxbb-v'
>>>>>>>> 20335 bytes read in 43 ms (460.9 KiB/s)
>>>>>>>> Found EFI removable media binary efi/boot/bootaa64.efi
>>>>>>>> Setting boot device name to '/efi/boot/bootaa64.efi'
>>>>>>>> reading efi/boot/bootaa64.efi
>>>>>>>> 129024 bytes read in 13 ms (9.5 MiB/s)
>>>>>>>> ## Starting EFI application at 01080000 ...
>>>>>>>> mmc_init: -95, time 1807
>>>>>>>> Found 0 disks
>>>>>>>
>>>>>>>
>>>>>>> That looks like efi_disk didn't manage to enumerate any devices?
>>>>>>
>>>>>>
>>>>>> Apparently. The last line comes from
>>>>>> lib/efi_loader_efi_disk:efi_disk_register(), and CONFIG_BLK=y. As you
>>>>>> can see, there is not a single "Scanning disk" line, so I guess we do
>>>>>> not iterate over uclass devices properly?
>>>>>>
>>>>>> On the Odroid-C2 I get this:
>>>>>>
>>>>>> Scanning disk mmc at 72000.blk...
>>>>>> Card did not respond to voltage select!
>>>>>> mmc_init: -95, time 9
>>>>>> Found 1 disks
>>>>>>
>>>>>> Therefore my guess that it matters at what point in time - before or
>>>>>> after the disk we want - the error accessing an MMC device happens.
>>>>>
>>>>>
>>>>> For comparison, Vega S95 with first MMC node disabled in DT:
>>>>>
>>>>> Scanning disk mmc at 72000.blk...
>>>>> Adding disk device 'mmc at 72000.blk'
>>>>> ** First descriptor is NOT a primary desc on 1:1 **
>>>>> Scanning disk mmc at 74000.blk...
>>>>> Adding disk device 'mmc at 74000.blk'
>>>>> Found 2 disks
>>>>>
>>>>> Regards,
>>>>> Andreas
>>>>>
>>>> By adding sd_mmc_a to the odroid-c2.dts I was able to reproduce the
>>>> problem on the Odroid C2.
>>>>
>>>> While booting from SD card via booti still worked
>>>> bootefi would not find any block device:
>>>>
>>>> => bootefi hello
>>>> ## Starting EFI application at 01000000 ...
>>>> WARNING: Invalid device tree, expect boot to fail
>>>> efi_add_memory_map: 0x7cf53000 0x1 2 yes
>>>> uclass_find_device_by_seq: 0 -1
>>>> uclass_find_device_by_seq: 0 0
>>>>    - -1 -1
>>>>    - -1 -1
>>>>    - -1 -1
>>>>    - not found
>>>> set_state_simple op missing
>>>> blk_get_device: if_type=6, devnum=0: mmc at 70000.blk, 6, 0
>>>> mmc_init: -95, time 1807

This error number is "EOPNOTSUPP". Is "cfg->voltages" correct in meson_gx_mmc.c?

>>>> Found 0 disks
>>>> efi_add_memory_map: 0x7cf52000 0x1 6 yes
>>>> do_bootefi_exec:234 Jumping to 0x7cf53148
>>>> EFI: Entry efi_cout_output_string(000000007ff94b38, 000000007cf53280)
>>>> Hello, world!
>>>> EFI: Entry efi_exit(000000007ffa4598, 0, 0, 0000000000000000)
>>>> ## Application terminated, r = 0
>>>>
>>>> In the debug output you can see that after trying non-existant
>>>> mmc at 70000.blk no further devices are scanned. mmc at 72000.blk which has
>>>> the SD card is not enumerated.
>>>
>>>
>>> To me that looks like something wrong with DM code, as there is no explicit
>>> abort condition in efi_disk_register() for the CONFIG_BLK case. Let's CC
>>> Simon and ask for help :).
>>
>> Reviewed-by: Simon Glass <sjg at chromium.org>
>>
>> Do you have a board that uses CONFIG_BLK?
> 
> make odroid-c2_defconfig
> results in
> CONFIG_BLK=y
> 
>>
>> Or could we enhance my helloworld test to check the test? I really
>> don't like having to run grub to find bugs :-)
> 
> The current debug output is sufficient to demonstrate that the MMC
> devices are not correctly enumerated for bootefi if the first device
> cannot be probed.
> 
> Regards
> 
> Heinrich Schuchardt
> 
> 
> 
> 