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 _at_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)Received on Wed Mar 18 2020 - 19:36:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:23 UTC