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 <ag...@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 <afaer...@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 m...@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 m...@72000.blk... >>>>> Adding disk device 'm...@72000.blk' >>>>> ** First descriptor is NOT a primary desc on 1:1 ** >>>>> Scanning disk m...@74000.blk... >>>>> Adding disk device 'm...@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: m...@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 >>>> m...@70000.blk no further devices are scanned. m...@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 <s...@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 > > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
