[U-Boot] [PATCH v2 1/1] core/uclass: iterate over all devices of a uclass

Simon Glass sjg at chromium.org
Wed Apr 19 21:34:41 UTC 2017


On 19 April 2017 at 15:06, Andreas Färber <afaerber at suse.de> wrote:
> Am 19.04.2017 um 13:26 schrieb Heinrich Schuchardt:
>> When iterating over the devices of an uclass the iteration stops
>> at the first device that cannot be probed.
>> When calling booefi this will result in no block device being
>
> "bootefi"
>
>> passed to the EFI executable if the first device cannot be probed.
>>
>> The problem was reported by Andreas Färber in
>> https://lists.denx.de/pipermail/u-boot/2017-April/287432.html
>>
>> For testing I used an odroid-c2 with a dts including
>> &sd_emmc_a {
>>       status = "okay";
>> }
>> This device does not exist on the board and cannot be initialized.
>>
>> With the patch uclass_first_device and uclass_next_device
>> iterate internally until they find the first device that can be
>> probed or the end of the device list is reached.
>>
>> Debug output is provided for the two functions.
>>
>> Reported-by: Andreas Färber <afaerber at suse.de>
>> Cc: Simon Glass <sjg at chromium.org>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>> ---
>> v2:
>>   As suggested by Simon Glass correct uclass_first_device() and
>>   uclass_next_device() instead of uclass_get_device_tail() to
>>   avoid side effects.
>> v1:
>>   The original patch was posted as
>>   core/uclass: uclass_get_device_tail: always set devp
>>   https://lists.denx.de/pipermail/u-boot/2017-April/288068.html
>> ---
>>  drivers/core/uclass.c | 44 +++++++++++++++++++++++++++++++++-----------
>>  1 file changed, 33 insertions(+), 11 deletions(-)
>
> Reviewed-by: Andreas Färber <afaerber at suse.de>
> Tested-by: Andreas Färber <afaerber at suse.de>
>
> Confirming that on my Vega S95 Telos this results in a full GRUB menu,
> and GRUB sees two disks.
>
> Many thanks,
>
> Andreas

Just to be clear, I am NAKing this patch. I do not want to change the
existing semantics as it requires existing code to check the function
return value. Instead I would like to:

- Fix the bug found by Alvaro
https://lists.denx.de/pipermail/u-boot/2017-April/288091.html This
involves setting *devp to NULL when returning an error.
- Add two new functions which return the device whether it probes or
not, allowing iteration to continue. Since we have two potential users
for these functions, it seems worth it.

I'll take a look at this soon unless someone else does :-)

Regards,
SImon

>
>
> ## Starting application at 0x01000000 ...
>
>
> U-Boot 2017.05-rc2-00063-gfc365a8 (Apr 19 2017 - 22:48:23 +0200) vega-s95
>
> DRAM:  2 GiB
> MMC:   mmc at 70000: 0, mmc at 72000: 1, mmc at 74000: 2
> Using default environment
>
> In:    serial at 4c0
> Out:   serial at 4c0
> Err:   serial at 4c0
> Net:   eth0: ethernet at 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 44 ms (451.2 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 12 ms (10.3 MiB/s)
> ## Starting EFI application at 01080000 ...
> mmc_init: -95, time 1806
> Scanning disk mmc at 72000.blk...
> About to add disk device 'mmc at 72000.blk'
> Adding disk device 'mmc at 72000.blk'
> ** First descriptor is NOT a primary desc on 2:1 **
> Scanning disk mmc at 74000.blk...
> About to add disk device 'mmc at 74000.blk'
> Adding disk device 'mmc at 74000.blk'
> Found 2 disks
> Welcome to GRUB!
>
> [...]
>
> grub>ls
> (hd0) (hd0,msdos2) (hd0,msdos1) (hd1)
>
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)


More information about the U-Boot mailing list