Date: Sun, 6 Jun 2021 09:00:40 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org Subject: Re: Strange u-boot behavior Message-ID: <20210606160040.GA97697@www.zefox.net> In-Reply-To: <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 06, 2021 at 12:11:20AM -0700, Mark Millard wrote: > > > 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 > > 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? It's a dual-boot system, with a complete FreeBSD-current install on both USB and microSD storage. > > 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. > Purely inertia. U-boot doesn't update via the normal make install cycle, requiring a careful reading of notes for manual upgrade. It was usable two months ago, though not without hiccups. > What RPi3B+ firmware version? This can be found via: > > # strings start.elf | grep "VC_BUILD_ID_" > # strings start.elf | grep "VC_BUILD_ID_" VC_BUILD_ID_USER: dc4 VC_BUILD_ID_TIME: 15:31:38 VC_BUILD_ID_BRANCH: master VC_BUILD_ID_TIME: Jun 7 2018 VC_BUILD_ID_HOSTNAME: dc4-XPS13-9333 VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 4800f08a139d6ca1c5ecbee345ea6682e2160881 (clean) That's old, but it used to work with this USB train. > 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 > > run bootcmd_usb0 > > after which the usb hard disk boots and all is well. > > > > 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 > > > > However, usb tree reports > > USB device tree: > > 1 Hub (480 Mb/s, 0mA) > > | U-Boot Root Hub > > | > > +-2 Hub (480 Mb/s, 2mA) > > | > > +-3 Vendor specific (12 Mb/s, 90mA) > > | FTDI FT232R USB UART AM00FGTR > > | > > +-4 Vendor specific (480 Mb/s, 2mA) > > | > > +-5 Mass Storage (480 Mb/s, 0mA) > > ASMT ASM105x 12345678D558 > > > > 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 > > a persistent failure. > > > > Once FreeBSD has booted, the disk is seen and accessed as usual. > > What alternatives have you tried? > > *) Have you tried starting a boot sequence once with > program_usb_boot_timeout=1 in config.txt , per notes in: > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/bootflow.md > Just tried it, usb scan still fails to find the mass storage device while usb tree sees it. > This programs a One Time Programmable bit to cause > extra some time to be allowed. The > program_usb_boot_timeout=1 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. > The "boot from USB" OTP was set during initial experiments some time ago. > @) Have you tried any mixes of bootcode_delay=???, > boot_delay=???, boot_delay_ms=??? 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=??? > 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). > I'm seeing lots of MESS:00:00:01.300591:0: hdmi: HDMI:EDID error reading EDID block 0 attempt... errors from u-boot. Up to now they didn't seem to matter. > 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'm using that method on a Pi2, but haven't tried it on the Pi3B since it's a dual-boot. > 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. Indeed, if the disk is moved to the hub it's overlooked by usb tree in addition to being missed by usb scan. > > See: > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/README.md > > and "Special bootcode.bin-only boot mode" in: > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.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/msd.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.) It looks to me like upgrading u-boot on the microSD should be the first priority. There remains a lingering suspicion that the USB-SATA adapter (a Startech) might be part of the problem, but why it might stop working now is unclear. Thanks for writing! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210606160040.GA97697>