Date: Sun, 6 Jun 2021 00:11:20 -0700 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Strange u-boot behavior Message-ID: <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> In-Reply-To: <20210606043152.GA94545@www.zefox.net> References: <20210606043152.GA94545@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jun-5, at 21:31, bob prohaska <fbsd at www.zefox.net> wrote: > For some time now I've been booting an Rpi3B+ using a microSD > card configured with=20 > U-Boot 2019.10 (Mar 17 2020 - 22:01:14 -0700) I'm unclear. Do you have the whole msdos file system content on the microsd card and only the FreeBSD UFS kernel+world on the USB drive? No msdos file system on the USB drive? Some of the confusion may become clearer about why I might care in my later notes. Another question: why still U-Boot 2019.10 instead of updating to match, say, what is on modern RELEASE or snapshot builds for the version of FreeBSD that you are using on the RPi3B+ ? You seem to be using a generally not-used combination by sticking to an older U-Boot but updating other things. What RPi3B+ firmware version? This can be found via: # strings start.elf | grep "VC_BUILD_ID_" Depending on what is reported: this might have questions about the vintage used. > by stopping it at the u-boot prompt and issuing > usb reset > followed by=20 > run bootcmd_usb0 > after which the usb hard disk boots and all is well. >=20 > Lately, usb reset has taken to reporting > resetting USB... > Bus usb@7e980000: scanning bus usb@7e980000 for devices... Device NOT = ready > Request Sense returned 02 04 01 > 5 USB Device(s) found > scanning usb for storage devices... 0 Storage Device(s) found >=20 > However, usb tree reports > USB device tree: > 1 Hub (480 Mb/s, 0mA) > | U-Boot Root Hub=20 > | > +-2 Hub (480 Mb/s, 2mA) > | > +-3 Vendor specific (12 Mb/s, 90mA) > | FTDI FT232R USB UART AM00FGTR > | =20 > +-4 Vendor specific (480 Mb/s, 2mA) > | =20 > +-5 Mass Storage (480 Mb/s, 0mA) > ASMT ASM105x 12345678D558 >=20 > The problem isn't wholly new; the usb reset command sometimes had > to be repeated once or twice before the disk was found. Now it seems=20= > a persistent failure.=20 >=20 > Once FreeBSD has booted, the disk is seen and accessed as usual.=20 What alternatives have you tried? *) Have you tried starting a boot sequence once with program_usb_boot_timeout=3D1 in config.txt , per notes in: = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/b= ootflow.md This programs a One Time Programmable bit to cause extra some time to be allowed. The program_usb_boot_timeout=3D1 does not need to be kept in place. After another reboot (to a RaspiOS in order to have the command available): vcgencmd otp_dump | grep 66 should have bit 24 set in what it reports. This might only be useful for option (B) below. I've never found wording specifying the range of modes that this adds time to. But it might apply to all or most modes. @) Have you tried any mixes of bootcode_delay=3D???, boot_delay=3D???, boot_delay_ms=3D??? in config.txt ? These are documented in: = https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md= bootcode_delay can add time before any start*.elf is read from whatever media --but it is not clear if the config.txt containing the bootcode_delay=3D??? and start*.elf can be from different media. boot_delay and boot_delay_ms control waiting some amount of time in start*.elf before loading the next stage (U-Boot for FreeBSD's normal sequence). A) Using a microsd card with only a modern bootcode.bin should be able to have the rest of the material on the USB device, including U-Boot. This way tends to have more fixes/improvements than depending on the internal support for direct USB booting: It supposedly works for more USB devices. I do this on a RPi2B v1.1 that does not have support (B) below. I have done this in temporary contexts on a RPi3B where (B) below seemed to have a problem for some reason. Dealing with booting from (some?) powered hubs can be a type of context where this proves useful. See: = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/R= EADME.md and "Special bootcode.bin-only boot mode" in: = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md If the msdos file system that contains bootcode.bin also contains an empty file named "timeout" it will wait longer for a USB device to be ready. See "Known issues" in: = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md B) "The Raspberry Pi 3B+ supports USB mass storage boot out of the box". So, unless some of those improvements metioned in (A) turn out to be necessary, no microsd card should be needed, presuming that all the required material (including U-Boot) is on the USB drive. I do this on a RPi3B and RPi2B v1.2 (after enabling them: not "out of the box") and all the RPi4B's. (Some RPi4B's required eeprom updates to enable this.) This does not give any control over getting extra time for the USB device to be ready: it would first have to have already read something from the device. But the details of this might be better than the details of some specific microsd card based RPi3B+ firmware boots. I.e., it might be worth a try. C) I will note that it is possible to have the FreeBSD kernel also on the microsd card in a UFS partition and to have "world" on the USB drive. This leads to only FreeBSD's kernel and later using the USB drive. But keeping the copy of the kernel and such on the separate media is messier and atypical. (Note: I do this sort if thing for the ROCK64 where the dd'd U-Boot does not support USB for the FreeBSD loader to put to use. I defer USB first-use to the kernel.) =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?27786296-8C55-4CEC-A587-14BF4465A4F8>