On 04/16/2017 09:34 PM, Simon Glass wrote:
Hi Alex,
On 16 April 2017 at 04:08, Alexander Graf agraf@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@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.
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@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