| Message ID | 25d9a8b3-e825-ec6c-5dc3-46bd35d1a246@suse.de |
|---|---|
| State | Changes Requested |
| Delegated to: | Jaehoon Chung |
| Headers | show |
On 04/15/2017 08:27 PM, Alexander Graf wrote: > > > On 15.04.17 20:18, Heiner Kallweit wrote: >> Am 15.04.2017 um 17:05 schrieb Andreas Färber: >>> Am 14.04.2017 um 08:22 schrieb Jaehoon Chung: >>>> On 04/13/2017 03:30 AM, Heiner Kallweit wrote: >>>>> From: Carlo Caione <carlo@caione.org> >>>>> This driver implements MMC support on Meson GX (S905) based systems. >>>>> It's based on Carlo Caione's work, changes: >>>>> - BLK support added >>>>> - general refactoring >>>>> >>>>> Signed-off-by: Carlo Caione <carlo@caione.org> >>>>> Signed-off-by: Andreas Färber <afaerber@suse.de> >>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> >>>> >>>> Applied to u-boot-mmc. Thanks! >>> >>> Thanks guys for all the work on this! >>> >>> I have tested it successfully on the Odroid-C2. >>> >>> 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 sd_emmc_a - Wireless SDIO Module sd_emmc_b - SD card sd_emmc_c - eMMC >> >> I'm not familiar with distro boot, but as far as I understand Heinrich's >> patch it just adds mmc0 and mmc1. Therefore distro boot doesn't try to >> boot from eMMC. I will resubmit https://patchwork.ozlabs.org/patch/750859/ odroid-c2: enable MMC as boot target with 3 MMC targets. I have tested on my Odroid C2 that the fallthrough to DHCP is still working with 3 defined MMC targets. > > 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. You could enable CONFIG_DISPLAY_BOARDINFO=y CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y Boardinfo will display the MMC devices detected. bootefi hello prints the number of disks detected and handed over to the EFI target. > > Andreas, please add debug prints like the ones below and check that the > device names match: > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c > index 97a0fc9..a98cd95 100644 > --- a/cmd/bootefi.c > +++ b/cmd/bootefi.c > @@ -364,5 +364,6 @@ void efi_set_bootdev(const char *dev, const char > *devnr, const char *path) > } else { > snprintf(devname, sizeof(devname), "%s", path); > } > +printf("Setting boot device name to '%s'\n", devname); > ascii2unicode(bootefi_image_path[0].str, devname); > } > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c > index 1e3dca4..f83fa0e 100644 > --- a/lib/efi_loader/efi_disk.c > +++ b/lib/efi_loader/efi_disk.c > @@ -207,6 +207,7 @@ static void efi_disk_add_dev(const char *name, > if (!desc->lba) > return; > > +printf("Adding disk device '%s'\n", name); > diskobj = calloc(1, objlen); > > /* Fill in object data */ > > Alex > Wouldn't it make sense to add Alex's patch to mainline? Best regards Heinrich Schuchardt
On 15.04.17 21:13, Heinrich Schuchardt wrote: > On 04/15/2017 08:27 PM, Alexander Graf wrote: >> >> >> On 15.04.17 20:18, Heiner Kallweit wrote: >>> Am 15.04.2017 um 17:05 schrieb Andreas Färber: >>>> Am 14.04.2017 um 08:22 schrieb Jaehoon Chung: >>>>> On 04/13/2017 03:30 AM, Heiner Kallweit wrote: >>>>>> From: Carlo Caione <carlo@caione.org> >>>>>> This driver implements MMC support on Meson GX (S905) based systems. >>>>>> It's based on Carlo Caione's work, changes: >>>>>> - BLK support added >>>>>> - general refactoring >>>>>> >>>>>> Signed-off-by: Carlo Caione <carlo@caione.org> >>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de> >>>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> >>>>> >>>>> Applied to u-boot-mmc. Thanks! >>>> >>>> Thanks guys for all the work on this! >>>> >>>> I have tested it successfully on the Odroid-C2. >>>> >>>> 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 > > sd_emmc_a - Wireless SDIO Module > sd_emmc_b - SD card > sd_emmc_c - eMMC > >>> >>> I'm not familiar with distro boot, but as far as I understand Heinrich's >>> patch it just adds mmc0 and mmc1. Therefore distro boot doesn't try to >>> boot from eMMC. > > I will resubmit https://patchwork.ozlabs.org/patch/750859/ > odroid-c2: enable MMC as boot target > with 3 MMC targets. > > I have tested on my Odroid C2 that the fallthrough to DHCP is still > working with 3 defined MMC targets. > >> >> 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. > > You could enable > CONFIG_DISPLAY_BOARDINFO=y > CONFIG_CMD_BOOTEFI_HELLO_COMPILE=y > > Boardinfo will display the MMC devices detected. > > bootefi hello > prints the number of disks detected and handed over to the EFI target. > >> >> Andreas, please add debug prints like the ones below and check that the >> device names match: >> >> diff --git a/cmd/bootefi.c b/cmd/bootefi.c >> index 97a0fc9..a98cd95 100644 >> --- a/cmd/bootefi.c >> +++ b/cmd/bootefi.c >> @@ -364,5 +364,6 @@ void efi_set_bootdev(const char *dev, const char >> *devnr, const char *path) >> } else { >> snprintf(devname, sizeof(devname), "%s", path); >> } >> +printf("Setting boot device name to '%s'\n", devname); >> ascii2unicode(bootefi_image_path[0].str, devname); >> } >> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c >> index 1e3dca4..f83fa0e 100644 >> --- a/lib/efi_loader/efi_disk.c >> +++ b/lib/efi_loader/efi_disk.c >> @@ -207,6 +207,7 @@ static void efi_disk_add_dev(const char *name, >> if (!desc->lba) >> return; >> >> +printf("Adding disk device '%s'\n", name); >> diskobj = calloc(1, objlen); >> >> /* Fill in object data */ >> >> Alex >> > Wouldn't it make sense to add Alex's patch to mainline? You usually don't want these debug messages in a proper u-boot build. Maybe as debug prints. We really need to simply improve on general debuggability of the efi object model though :). I need to sit down and make grub's "lsefi" just work. Ideally that would give us all the hints we need to find out what's going wrong in situations like this, as it has access to all pieces that we need. Alex
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 Welcome to GRUB! error: disk `,msdos2' not found. Entering rescue mode... grub rescue> Regards, Andreas
On 04/15/2017 10:34 PM, Andreas Färber wrote: > 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 > Welcome to GRUB! > > error: disk `,msdos2' not found. > Entering rescue mode... > grub rescue> > > Regards, > Andreas > What is the output of ls in grub rescue mode? Best regards Heinrich
> 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? Alex > Welcome to GRUB! > > error: disk `,msdos2' not found. > Entering rescue mode... > grub rescue> > > Regards, > Andreas > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg)
Am 15.04.2017 um 22:52 schrieb Heinrich Schuchardt: > On 04/15/2017 10:34 PM, Andreas Färber wrote: >> 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 >> Welcome to GRUB! >> >> error: disk `,msdos2' not found. >> Entering rescue mode... >> grub rescue> [...] > What is the output of > ls > in grub rescue mode? Entirely empty. Regards, Andreas
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. Regards, Andreas
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
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
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 :). Alex
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? Or could we enhance my helloworld test to check the test? I really don't like having to run grub to find bugs :-) Regards, Simon
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
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 <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 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 >>>> 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 > > > >
Hi, On 17 April 2017 at 16:39, Jaehoon Chung <jh80.chung@samsung.com> wrote: > 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 <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 > > This error number is "EOPNOTSUPP". Is "cfg->voltages" correct in meson_gx_mmc.c? Or it could just be that there is no card inserted? See mmc_start_init(). It would be good to update mmc.c to return different errors for the different cases. Regards, Simon
On 04/24/2017 12:38 PM, Simon Glass wrote: > Hi, > > On 17 April 2017 at 16:39, Jaehoon Chung <jh80.chung@samsung.com> wrote: >> 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 <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 >> >> This error number is "EOPNOTSUPP". Is "cfg->voltages" correct in meson_gx_mmc.c? > > Or it could just be that there is no card inserted? See > mmc_start_init(). It would be good to update mmc.c to return different > errors for the different cases. Right..Will update. > > Regards, > Simon > > >
Hi Alex, On 16 April 2017 at 13:34, Simon Glass <sjg@chromium.org> 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? > > 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
diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 97a0fc9..a98cd95 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -364,5 +364,6 @@ void efi_set_bootdev(const char *dev, const char *devnr, const char *path) } else { snprintf(devname, sizeof(devname), "%s", path); } +printf("Setting boot device name to '%s'\n", devname); ascii2unicode(bootefi_image_path[0].str, devname); } diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index 1e3dca4..f83fa0e 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -207,6 +207,7 @@ static void efi_disk_add_dev(const char *name, if (!desc->lba) return; +printf("Adding disk device '%s'\n", name); diskobj = calloc(1, objlen); /* Fill in object data */