Hi Heinrick, On 19 April 2017 at 05:26, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > 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 > 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.
I just re-read this thread and saw this point again. If this is not on the board, shouldn't the device have "disabled" in its node? > > 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 <afaer...@suse.de> > Cc: Simon Glass <s...@chromium.org> > Signed-off-by: Heinrich Schuchardt <xypron.g...@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(-) Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
