Date: Sat, 2 Jul 2022 12:00:02 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Free BSD <freebsd-arm@freebsd.org> Subject: Re: RPi3 usb boot hang on stable/13 Message-ID: <24D669B0-728D-4910-884A-B2230AE442F9@yahoo.com> In-Reply-To: <3BDD64A4-8BC3-4E14-B17C-1958F6CBB87F@yahoo.com> References: <20220702165800.GA10701@www.zefox.net> <3BDD64A4-8BC3-4E14-B17C-1958F6CBB87F@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2022-Jul-2, at 10:34, Mark Millard <marklmi@yahoo.com> wrote:
> On 2022-Jul-2, at 09:58, bob prohaska <fbsd@www.zefox.net> wrote:
>=20
>> Lately an RPi3 running stable/13 has started hanging on boot from USB
>> The disk is on a powered hub.
>>=20
>> When gracefully rebooted it ends with:
>>=20
>> .....
>> MESS:00:00:03.166523:0: Device tree loaded to 0x4000 (size 0x63cd)
>> MESS:00:00:03.172180:0: uart: Set PL011 baud rate to 103448.300000 Hz
>> MESS:00:00:03.178716:0: uart: Baud rate change done...
>> MESS:00:00:03.182145:0: uart: Baud rate change done...
>> MESS:00:00:03.187830:0: gpioman: gpioman_get_pin_num: pin =
SDCARD_CONTROL_POWER not defined
>> MMC: mmc@7e300000: 1
>> Loading Environment from FAT... OK
>> In: serial
>> Out: vidconsole
>> Err: vidconsole
>> Net: No ethernet found.
>> starting USB...
>> Bus usb@7e980000: scanning bus usb@7e980000 for devices... 6 USB =
Device(s) found
>> scanning usb for storage devices... 1 Storage Device(s) found
>> Hit any key to stop autoboot: 0=20
>>=20
>> Device 0:=20
>=20
> That is U-Boot output. Looks like the output stopped before
> the load of even the FreeBSD loader: FreeBSD is not involved
> yet so it is not a FreeBSD problem.
Hmm. I looked at an old RPI3 boot-session log I have around and
it shows more text than you report. Is your serial connection
having problems? An example that is missing is the line
"U-Boot . . ." that identifies the version and build time
of U-Boot. That is rather generic material to be missing.
(I did not have a microsd card present. Such could be an
example of expected differences.)
QUOTE (of a similar range of text)
MESS:00:00:03.285409:0: Device tree loaded to 0x4000 (size 0x7640)
MESS:00:00:03.292968:0: uart: Set PL011 baud rate to 103448.300000 Hz
MESS:00:00:03.299261:0: uart: Baud rate change done...
MESS:00:00:03.302695:0: uart: Baud rate change done...
MESS:00:00:03.308421:0: gpioman: gpioman_get_pin_num: pin =
SDCARD_CONTROL_POWER not defined
U-Boot 2022.04 (Apr 23 2022 - 03:14:35 +0000)
DRAM: 948 MiB
RPI 3 Model B (0x2a02082)
Core: 72 devices, 10 uclasses, devicetree: board
MMC: mmc@7e300000: 2
Loading Environment from FAT... In: serial
Out: vidconsole
Err: vidconsole
Net: No ethernet found.
starting USB...
Bus usb@7e980000: USB DWC2
scanning bus usb@7e980000 for devices... 4 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot: 2 1 0=20
MMC Device 0 not found
no mmc device at slot 0
MMC Device 1 not found
no mmc device at slot 1
switch to partitions #0, OK
mmc2 is current device
Scanning mmc 2:1...
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk mmc@7e300000.blk...
Scanning disk usb_mass_storage.lun0...
Found 9 disks
Missing RNG device for EFI_RNG_PROTOCOL
** Unable to read file ubootefi.var **
Failed to load EFI variables
BootOrder not defined
EFI boot manager: Cannot load any image
Device 0: Vendor: Samsung Rev: 0 Prod: PSSD T7 Touch =20
Type: Hard Disk
Capacity: 953869.7 MB =3D 931.5 GB (1953525168 x 512)
... is now current device
Scanning usb 0:1...
END QUOTE
There is the difference (yours then mine):
MMC: mmc@7e300000: 1
vs.
MMC: mmc@7e300000: 2
I wonder it if is some sort of clue about something.
>> At that point the console is unresponsive.=20
>=20
> Nasty.
>=20
>> The machine has a history of not always finding the USB disk, but =
this
>> appears to be new behavior. As with the disk discovery problem, the
>> error can be worked around by simple repetition. Once booted it's=20
>> stable but network response remains erratic.
>>=20
>> There's some indication that power-cycling the hard disk helps.
>>=20
>> At the moment uname -a reports
>>=20
>> FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #5 =
stable/13-n251597-7c500f98b8d: Fri Jul 1 21:52:12 PDT 2022 =
bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
>=20
> But FreeBSD is not involved yet at the failure point.
>=20
> What vintage of U-Boot?
>=20
> # strings u-boot.bin | grep "U-Boot 20"
>=20
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24D669B0-728D-4910-884A-B2230AE442F9>