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

Sat Apr 29 00:25:57 UTC 2017

Hi Alex,

On 16 April 2017 at 13:34, Simon Glass <sjg at chromium.org> 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
>>> 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 :-)

Any thoughts on this one?

Regards,
Simon