[PATCH] bootstd: Skip over bad device during bootflows scanning
Tony Dinh
mibodhi at gmail.com
Wed Nov 1 20:03:57 CET 2023
Hi Simon,
On Wed, Nov 1, 2023 at 9:10 AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Tony,
>
> On Tue, 31 Oct 2023 at 13:45, Tony Dinh <mibodhi at gmail.com> wrote:
> >
> > On Tue, Oct 31, 2023 at 12:26 PM Tony Dinh <mibodhi at gmail.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, Oct 30, 2023 at 12:47 PM Tony Dinh <mibodhi at gmail.com> wrote:
> > > >
> > > > During scanning for the next bootdev, if bootdev_next_prio() encounters
> > > > a device error (e.g. ENOSYS), let it continue scanning the next devices,
> > > > not stopping prematurely.
> > > >
> > > > Background:
> > > >
> > > > During scanning for bootflows, it's possible for bootstd to encounter a
> > > > faulty device controller. Also when the same u-boot is used for another
> > > > variant of the same board, some device controller such as SATA might
> > > > not exist.
> > > >
> > > > I've found this issue while converting the Marvell Sheevaplug board to
> > > > use bootstd. This board has 2 variants, the original Sheevaplug has MMC and
> > > > USB only, but the later variant comes with USB, MMC, and eSATA ports. We
> > > > have been using the same u-boot (starting with CONFIG_IDE and later with DM
> > > > CONFIG_SATA) for both variants. This worked well with the old
> > > > envs-scripting booting scheme.
> > > >
> > > > Signed-off-by: Tony Dinh <mibodhi at gmail.com>
> > > > ---
> > > >
> > > > boot/bootdev-uclass.c | 2 --
> > > > 1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
> > > > index 44ae98a926..b1d48e5b69 100644
> > > > --- a/boot/bootdev-uclass.c
> > > > +++ b/boot/bootdev-uclass.c
> > > > @@ -677,8 +677,6 @@ int bootdev_next_prio(struct bootflow_iter *iter, struct udevice **devp)
> > > > BOOTFLOWIF_SHOW);
> > > > log_debug("- bootdev_hunt_prio() ret %d\n",
> > > > ret);
> > > > - if (ret)
> > > > - return log_msg_ret("hun", ret);
> > > > }
> > > > } else {
> > > > ret = device_probe(dev);
> > > > --
> > > > 2.39.2
> > > >
> > >
> > > Per your request, here is the console trace log when the device error
> > > occurs. Perhaps we could improve bootdev_next_prio() to make the error
> > > status more visible in the console with printf? I've briefly looked at
> > > other device bootdev hunt drivers and did not see enough console
> > > output for this type of error, so it might be better that we have this
> > > output either in bootdev_next_prio() or bootdev_hunt_drv().
> > >
> > > <BEGIN LOG>
> > > U-Boot 2024.01-rc1-tld-1-00003-gd697d7b93a-dirty (Oct 26 2023 - 16:17:16 -0700)
> > > Marvell-Sheevaplug
> > >
> > > SoC: Kirkwood 88F6281_A0
> > > DRAM: 512 MiB
> > > Core: 17 devices, 12 uclasses, devicetree: separate
> > > NAND: 512 MiB
> > > MMC: 338-uclass_find_device_by_seq() 0
> > > 346-uclass_find_device_by_seq() - 0 'mvsdio at 90000'
> > > 349-uclass_find_device_by_seq() - found
> > > 252- mvebu_mmc_power_up() mvebu_mmc mvsdio at 90000: power up
> > > 399-mvebu_mmc_initialize() mvebu_mmc mvsdio at 90000: mvebu_mmc_initialize
> > > 338-uclass_find_device_by_seq() 1
> > > 346-uclass_find_device_by_seq() - 0 'mvsdio at 90000'
> > > 353-uclass_find_device_by_seq() - not found
> > > mvsdio at 90000: 0
> > > Loading Environment from NAND... 338-uclass_find_device_by_seq() 0
> > > 346-uclass_find_device_by_seq() - 0 'ethernet-controller at 72000'
> > > 349-uclass_find_device_by_seq() - found
> > > OK
> > > In: serial
> > > Out: serial
> > > Err: serial
> > > Net: eth0: ethernet-controller at 72000
> > > Hit any key to stop autoboot: 0
> > >
> > > => env def -a
> > > ## Resetting to default environment
> > >
> > > => bootflow scan -l
> > > Scanning for bootflows in all bootdevs
> > > Seq Method State Uclass Part Name Filename
> > > --- ----------- ------ -------- ---- ------------------------
> > > ----------------
> > > 338-uclass_find_device_by_seq() 0
> > > 346-uclass_find_device_by_seq() - 0 'extlinux'
> > > 349-uclass_find_device_by_seq() - found
> > > 338-uclass_find_device_by_seq() 1
> > > 346-uclass_find_device_by_seq() - 0 'extlinux'
> > > 346-uclass_find_device_by_seq() - 1 'script'
> > > 349-uclass_find_device_by_seq() - found
> > > 338-uclass_find_device_by_seq() 2
> > > 346-uclass_find_device_by_seq() - 0 'extlinux'
> > > 346-uclass_find_device_by_seq() - 1 'script'
> > > 346-uclass_find_device_by_seq() - 2 'pxe'
> > > 349-uclass_find_device_by_seq() - found
> > > 871- bootdev_hunt_prio() Hunting for priority 1
> > > 883- bootdev_hunt_prio() exit 0
> > > 715- bootdev_setup_iter() - bootdev_hunt_prio() ret 0
> > > 83-bootstd_get_bootdev_order() - targets <NULL> 00000000
> > > 746- bootdev_setup_iter() setup labels 00000000
> > > 641- bootdev_next_prio() next prio 0: dev=00000000/none
> > > 659- bootdev_next_prio() - ethernet-controller at 72000.boo: 6, want 0
> > > 659- bootdev_next_prio() - mvsdio at 90000.bootdev: 2, want 0
> > > 668- bootdev_next_prio() None found at prio 0, moving to 1
> > > 871- bootdev_hunt_prio() Hunting for priority 1
> > > 883- bootdev_hunt_prio() exit 0
> > > 678- bootdev_next_prio() - bootdev_hunt_prio() ret 0
> > > 659- bootdev_next_prio() - ethernet-controller at 72000.boo: 6, want 1
> > > 659- bootdev_next_prio() - mvsdio at 90000.bootdev: 2, want 1
> > > 668- bootdev_next_prio() None found at prio 1, moving to 2
> > > 871- bootdev_hunt_prio() Hunting for priority 2
> > > Hunting with: mmc
> > > 783- bootdev_hunt_drv() Hunting with: mmc
> > > 879- bootdev_hunt_prio() bootdev_hunt_drv() return 0
> > > 883- bootdev_hunt_prio() exit 0
> > > 678- bootdev_next_prio() - bootdev_hunt_prio() ret 0
> > > 659- bootdev_next_prio() - ethernet-controller at 72000.boo: 6, want 2
> > > 659- bootdev_next_prio() - mvsdio at 90000.bootdev: 2, want 2
> > > 756- bootdev_setup_iter() Selected bootdev: mvsdio at 90000.bootdev
> > > 134-bootflow_iter_set_dev() iter: Setting dev to mvsdio at 90000.bootdev, flags 0
> > > Scanning bootdev 'mvsdio at 90000.bootdev':
> > > 573-bootdev_get_bootflow() ->get_bootflow mvsdio at 90000.bootdev,0=00000000
> > > 337- mvebu_mmc_set_ios() mvebu_mmc mvsdio at 90000: bus[0] clock[0]
> > > 321- mvebu_mmc_set_bus() mvebu_mmc mvsdio at 90000: ctrl 0xf809:
> > > push-pull 1bit-width
> > > 279- mvebu_mmc_set_clk() mvebu_mmc mvsdio at 90000: clock off
> > > 337- mvebu_mmc_set_ios() mvebu_mmc mvsdio at 90000: bus[1] clock[0]
> > > 321- mvebu_mmc_set_bus() mvebu_mmc mvsdio at 90000: ctrl 0xf809:
> > > push-pull 1bit-width
> > > 279- mvebu_mmc_set_clk() mvebu_mmc mvsdio at 90000: clock off
> > > 337- mvebu_mmc_set_ios() mvebu_mmc mvsdio at 90000: bus[1] clock[97703]
> > > 321- mvebu_mmc_set_bus() mvebu_mmc mvsdio at 90000: ctrl 0xf809:
> > > push-pull 1bit-width
> > > 287- mvebu_mmc_set_clk() mvebu_mmc mvsdio at 90000: clock (97703) div : 1022
> > > 85- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: cmdidx [0x0]
> > > resp_type[0x0] cmdarg[0x0]
> > > 88- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: cmd 0 (hw state 0x20f8)
> > > 233- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: resp[0x0] mvebu_mmc
> > > mvsdio at 90000: cmdidx [0x8] resp_type[0x15] cmdarg[0x1aa]
> > > 88- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: cmd 8 (hw state 0x20f8)
> > > 233- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: resp[0x15]
> > > mvebu_mmc mvsdio at 90000: cmdidx [0x37] resp_type[0x15] cmdarg[0x0]
> > > 88- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: cmd 55 (hw state 0x20f8)
> > > 233- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: resp[0x15]
> > > mvebu_mmc mvsdio at 90000: cmdidx [0x0] resp_type[0x0] cmdarg[0x0]
> > > 88- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: cmd 0 (hw state 0x20f8)
> > > 233- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: resp[0x0] mvebu_mmc
> > > mvsdio at 90000: cmdidx [0x1] resp_type[0x1] cmdarg[0x0]
> > > 88- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: cmd 1 (hw state 0x20f8)
> > > 233- mvebu_mmc_send_cmd() mvebu_mmc mvsdio at 90000: resp[0x1] Card did
> > > not respond to voltage select! : -110
> > > 333-bootdev_get_sibling_blk() act: returning err=-95
> > > 550-default_get_bootflow() sibling_blk ret=-95, blk=(none)
> > > 559-default_get_bootflow() blk: returning err=-108
> > > 375- bootflow_check() check: returning err=-108
> > > 414- bootflow_scan_first() check - ret=-108
> > > 191- iter_incr() entry: err=-108
> > > 248- iter_incr() inc_dev=1
> > > 281- iter_incr() labels 00000000
> > > 641- bootdev_next_prio() next prio 2: dev=1fb4e800/mvsdio at 90000.bootdev
> > > 668- bootdev_next_prio() None found at prio 2, moving to 3
> > > 871- bootdev_hunt_prio() Hunting for priority 3
> > > 883- bootdev_hunt_prio() exit 0
> > > 678- bootdev_next_prio() - bootdev_hunt_prio() ret 0
> > > 659- bootdev_next_prio() - ethernet-controller at 72000.boo: 6, want 3
> > > 659- bootdev_next_prio() - mvsdio at 90000.bootdev: 2, want 3
> > > 668- bootdev_next_prio() None found at prio 3, moving to 4
> > > 871- bootdev_hunt_prio() Hunting for priority 4
> > >
> > > Hunting with: ahci
> > > 783- bootdev_hunt_drv() Hunting with: ahci
> > > Removing devices on SATA bus...
> > > Cannot find SATA device (err=0)
> > > 786- bootdev_hunt_drv() - hunt result -38
> > > 879- bootdev_hunt_prio() bootdev_hunt_drv() return -38
> > > 883- bootdev_hunt_prio() exit -38
> > > 678- bootdev_next_prio() - bootdev_hunt_prio() ret -38
> > > 681- bootdev_next_prio() hun: returning err=-38
> > > 308- iter_incr() ret=-38, dev=00000000 none
> > > 134-bootflow_iter_set_dev() iter: Setting dev to (none), flags 0
> > > No more bootdevs
> > > 326- iter_incr() incr: returning err=-19
> > > 434- bootflow_scan_next() iter_incr: ret=-19
> > > 436- bootflow_scan_next() done: returning err=-19
> > > 422- bootflow_scan_first() get: returning err=-19
> > > --- ----------- ------ -------- ---- ------------------------
> > > ----------------
> > > (0 bootflows, 0 valid)
> > >
> > > <END LOG>
> >
> > A bit more information: drivers/ata/sata.c outputs these lines:
> >
> > Removing devices on SATA bus...
> > Cannot find SATA device (err=0)
>
> Thanks for the trace!
>
> I believe the problem is that sata_rescan() returns -ENOSYS. That
> error means that there is a device but it does not implement the
> uclass method requested. In this case -ENOENT would be a better error,
> since there is nothing there.
>
> Then in bootdev_hunt_drv(), check for -ENOENT from the info->hunt()
> call and ignore it.
>
> You should also update bootdev_hunter_func() docs to indicate what
> -ENOENT means.
Sounds good! I'll send a V2 patch.
All the best,
Tony
>
> Regards,
> Simon
More information about the U-Boot
mailing list