
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@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@70000: 0, mmc@72000: 1, mmc@74000: 2 Using default environment
In: serial@4c0 Out: serial@4c0 Err: serial@4c0 Net: eth0: ethernet@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@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@72000.blk... Adding disk device 'mmc@72000.blk' ** First descriptor is NOT a primary desc on 1:1 ** Scanning disk mmc@74000.blk... Adding disk device 'mmc@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@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@70000.blk no further devices are scanned. mmc@72000.blk which has the SD card is not enumerated.
Best regards
Heinrich Schuchardt