Date: Sun, 6 Jun 2021 10:34:26 -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: <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> In-Reply-To: <20210606160040.GA97697@www.zefox.net> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jun-6, at 09:00, bob prohaska <fbsd at www.zefox.net> wrote: > On Sun, Jun 06, 2021 at 12:11:20AM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2021-Jun-5, at 21:31, bob prohaska <fbsd at www.zefox.net> wrote: >>=20 >>> 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) >>=20 >> 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? >=20 > It's a dual-boot system, with a complete FreeBSD-current install > on both USB and microSD storage.=20 How do you control which device provides kernel+world if both have a kernel_world? >>=20 >> Some of the confusion may become clearer about why I >> might care in my later notes. >>=20 >> 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. >>=20 > Purely inertia. U-boot doesn't update via the normal make install > cycle, requiring a careful reading of notes for manual upgrade.=20 > It was usable two months ago, though not without hiccups.=20 I will note that U-Boot 2021.04 has problems with USB booting for armv7. I've had to stick with 2020.10 U-Boot for such devices that I want to have USB based booting, with an RPi2B v1.1 and a OPi+2E. Ports has progressed to U-Boot 2021.04 . >> What RPi3B+ firmware version? This can be found via: >>=20 >> # strings start.elf | grep "VC_BUILD_ID_" >>=20 > # 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) >=20 > That's old, but it used to work with this USB train. =20 bootcode.bin has improvements since back then, as do other things in the RPi firmware. I suggest trying the same vintage that is on 13.0-RELEASE's media. Later possibly newer from snapshot media if it has more recent. In other words: a bias to vintages more other folks are also using, where there is a wider knowledge context for how things are going. For reference, from a RPi4B (and a ROCK64), I am using: # strings start4.elf | grep "VC_BUILD_ID_" VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) >> Depending on what is reported: this might have >> questions about the vintage used. >>=20 >>> 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 >>=20 >> What alternatives have you tried? >>=20 >> *) Have you tried starting a boot sequence once with >> program_usb_boot_timeout=3D1 in config.txt , per notes in: >>=20 >> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/b= ootflow.md >>=20 >=20 > Just tried it, usb scan still fails to find the mass storage device = while=20 > usb tree sees it. >=20 >> 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): >>=20 >> vcgencmd otp_dump | grep 66 >>=20 >> should have bit 24 set in what it reports. >>=20 >> 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. >>=20 >=20 > The "boot from USB" OTP was set during initial experiments > some time ago. RPi3B+'s have this set before they are shipped out. >> @) Have you tried any mixes of bootcode_delay=3D???, >> boot_delay=3D???, boot_delay_ms=3D??? in config.txt ? >> These are documented in: >>=20 >> = https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md= >>=20 >> 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. >>=20 >> 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). >>=20 >=20 > I'm seeing lots of=20 > MESS:00:00:01.300591:0: hdmi: HDMI:EDID error reading EDID block 0 = attempt...=20 > errors from u-boot. Up to now they didn't seem to matter.=20 Do you have a HDMI screen attached? Whatever, bootcode_delay allows extra time for slow HDMI devices. >> 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. >>=20 >=20 > I'm using that method on a Pi2, but haven't tried it on the > Pi3B since it's a dual-boot.=20 Which gets back to the question: how do you control which device's kernel+world is booted? >> 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. >=20 > Indeed, if the disk is moved to the hub it's overlooked by > usb tree in addition to being missed by usb scan.=20 >=20 >>=20 >=20 >=20 >> See: >>=20 >> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/R= EADME.md >>=20 >> and "Special bootcode.bin-only boot mode" in: >>=20 >> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md >>=20 >> 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: >>=20 >> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/m= sd.md >>=20 >> 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. >>=20 >> 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.) >>=20 >> 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. >>=20 >> 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. >>=20 >> (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.) >=20 > 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.=20 >=20 I'd include RPi4B firmware updates to match 13.0 with that. =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?407FDEDF-8595-4F20-91B9-B475CCE95B39>