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

Sun Apr 16 19:34:43 UTC 2017

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
>> 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?

Or could we enhance my helloworld test to check the test? I really
don't like having to run grub to find bugs :-)

Regards,
Simon