Date: Wed, 18 Mar 2020 13:36:02 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: head -r538966 on OrangePi+ 2ed: boot loader crashes when USB drive is present at power-on/boot Message-ID: <863312E1-4216-49BA-A623-CAC85F123655@yahoo.com> References: <863312E1-4216-49BA-A623-CAC85F123655.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@1c11000': seq 1 is in use by 'mmc@1c10000'
mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
Loading Environment from FAT... Unable to use mmc 1:1...
In: serial
Out: serial
Err: serial
Net: phy interface7
eth0: ethernet@1c30000
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
Bus usb@1c1c000: USB EHCI 1.00
Bus usb@1c1c400: USB OHCI 1.0
Bus usb@1c1d000: USB EHCI 1.00
Bus usb@1c1d400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
scanning bus usb@1c1c000 for devices... 1 USB Device(s) found
scanning bus usb@1c1c400 for devices... 1 USB Device(s) found
scanning bus usb@1c1d000 for devices... 2 USB Device(s) found
scanning bus usb@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=20
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 =20
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=3D0 slice=3D<auto> partition=3D<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)=20
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=3D"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 =3D=3D -1) {
printf(" Probing all %s devices...\n", =
device_typename(load_type));
/* Try each disk of given type in succession until one =
works. */
for (unit =3D 0; unit < UB_MAX_DEV; unit++) {
currdev.dd.d_unit =3D =
uboot_diskgetunit(load_type, unit);
if (currdev.dd.d_unit =3D=3D -1)
break;
print_disk_probe_info();
open_result =3D devsw[devidx]->dv_open(&f, =
&currdev);
if (open_result =3D=3D 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 =3D 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.)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?863312E1-4216-49BA-A623-CAC85F123655>