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
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 :).
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
