head -r538966 on OrangePi+ 2ed: boot loader crashes when USB drive is present at power-on/boot

Wed Mar 18 20:36:10 UTC 2020

Without a USB drive present at power-on or
boot, the OPi+2e boots fine. (The USB drives
involved have a partition holding a ufs file
system and a partition holding a swap/aging
space.)

In all cases below, /boot/ is from the microsd
card. But the intended configuration is for
vfs.root.mountfrom to be used to direct the
stages after kernel-booting to the USB drive.

The output sequence related to the crash when
the USB drive is present looks like:

QUOTE
U-Boot SPL 2019.07 (Aug 02 2019 - 11:19:36 +0000)
DRAM: 2048 MiB
Trying to boot from MMC1

U-Boot 2019.07 (Aug 02 2019 - 11:19:36 +0000) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Plus 2E
DRAM:  2 GiB
MMC:   Device 'mmc at 1c11000': seq 1 is in use by 'mmc at 1c10000'
mmc at 1c0f000: 0, mmc at 1c10000: 2, mmc at 1c11000: 1
Loading Environment from FAT... Unable to use mmc 1:1...
In:    serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet at 1c30000
starting USB...
Bus usb at 1c1a000: USB EHCI 1.00
Bus usb at 1c1a400: USB OHCI 1.0
Bus usb at 1c1b000: USB EHCI 1.00
Bus usb at 1c1b400: USB OHCI 1.0
Bus usb at 1c1c000: USB EHCI 1.00
Bus usb at 1c1c400: USB OHCI 1.0
Bus usb at 1c1d000: USB EHCI 1.00
Bus usb at 1c1d400: USB OHCI 1.0
scanning bus usb at 1c1a000 for devices... 1 USB Device(s) found
scanning bus usb at 1c1a400 for devices... 1 USB Device(s) found
scanning bus usb at 1c1b000 for devices... 1 USB Device(s) found
scanning bus usb at 1c1b400 for devices... 1 USB Device(s) found
scanning bus usb at 1c1c000 for devices... 1 USB Device(s) found
scanning bus usb at 1c1c400 for devices... 1 USB Device(s) found
scanning bus usb at 1c1d000 for devices... 2 USB Device(s) found
scanning bus usb at 1c1d400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
199 bytes read in 1 ms (194.3 KiB/s)
## Executing script at 43100000
384312 bytes read in 19 ms (19.3 MiB/s)
## Starting application at 0x42000000 ...
Consoles: U-Boot console  
Compatible U-Boot API signature found @0xb9f6ea60FreeBSD/armv7 U-Boot loader, Revision 1.3

DRAM: 2048MB
Number of U-Boot devices: 2
U-Boot env: loaderdev not set, will probe all devices.
Found U-Boot device: disk
  Probing all <unknown> devices...
  Checking unit=0 slice=<auto> partition=<auto>...data abort
pc : [<42009068>]          lr : [<420603f8>]
reloc pc : [<ce07d068>]    lr : [<ce0d43f8>]
sp : b9f649f8  ip : 42062900     fp : b9f64a28
r10: b9f64a58  r9 : 42062640     r8 : 420623c0
r7 : 420626c0  r6 : 00000000     r5 : 42062650  r4 : 420626c0
r3 : 00000000  r2 : 00000980     r1 : 00000000  r0 : 000000ee
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Code: e3500080 1afffefb e5d801c2 e35000ee (059821c6) 
Resetting CPU ...

resetting ...
END QUOTE

Stopping it earlier and using:

setenv loaderdev mmc 0
boot

avoids the problem because it avoids "probing" the
USB drive at the stage indicated above. But the
boot then actually uses:

vfs.root.mountfrom="ufs:/dev/gpt/BPIM3root"

in the /boot/loader.conf on the microsd card.
ufs:/dev/gpt/BPIM3root is a reference to the ufs
partition on the USB media. (With the mountfrom
commented out the microsd card is bootable by
itself.) So later the USB drive is put to use
successfully when the initial probing is avoided.

Looking in the /usr/src/stand/uboot/common/main.c
code shows:

static int
probe_disks(int devidx, int load_type, int load_unit, int load_slice,
    int load_partition)
{
. . .
        if (load_unit == -1) {
                printf("  Probing all %s devices...\n", device_typename(load_type));
                /* Try each disk of given type in succession until one works. */
                for (unit = 0; unit < UB_MAX_DEV; unit++) {
                        currdev.dd.d_unit = uboot_diskgetunit(load_type, unit);
                        if (currdev.dd.d_unit == -1)
                                break;
                        print_disk_probe_info();
                        open_result = devsw[devidx]->dv_open(&f, &currdev);
                        if (open_result == 0) {
                                printf(" good.\n");
                                return (0);
                        }
                        printf("\n");
                }
                return (-1);
        }
. . .
}

So it appears that the crash is during the code involved
for the line:

open_result = devsw[devidx]->dv_open(&f, &currdev);

Note that the boot attempt reported "Probing all <unknown>
devices..." so device_typename(load_type) came up with
"<unknown>". (I've no clue if that is significant to the
issue or not.)

It appeared that /usr/src/stand/usb/storage/umass_loader.c
and its umass_disk_open and umass_disk_open_sub might
be involved and then code from the likes of:
/usr/src/sys/dev/usb/ --such as from usb_msctest.c for
usb_msc_read_capacity. (I stopped looking around
there: well outside areas I know how to interpret.)

For reference, I used the OPi+2e u-boot material from
my poudriere-devel based port builds:

# ls -ldT /usr/local/share/u-boot/u-boot-orangepi-plus-2e/*
-rw-r--r--  1 root  wheel     503 Oct 26 19:12:16 2019 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/README
-rw-r--r--  1 root  wheel     199 Oct 26 19:12:16 2019 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/boot.scr
-rw-r--r--  1 root  wheel      66 Oct 26 19:12:16 2019 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/metadata
-rw-r--r--  1 root  wheel  471250 Oct 26 19:12:16 2019 /usr/local/share/u-boot/u-boot-orangepi-plus-2e/u-boot-sunxi-with-spl.bin

(The USB drives are USB SSDs.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)