From nobody Sun Jun 6 16:00:40 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 53681955C98 for ; Sun, 6 Jun 2021 16:00:42 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Fyh6x5H1Nz3GfZ for ; Sun, 6 Jun 2021 16:00:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 156G0eF4097955 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 6 Jun 2021 09:00:40 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 156G0eOZ097954; Sun, 6 Jun 2021 09:00:40 -0700 (PDT) (envelope-from fbsd) Date: Sun, 6 Jun 2021 09:00:40 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Strange u-boot behavior Message-ID: <20210606160040.GA97697@www.zefox.net> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> X-Rspamd-Queue-Id: 4Fyh6x5H1Nz3GfZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Jun 06, 2021 at 12:11:20AM -0700, Mark Millard wrote: > > > On 2021-Jun-5, at 21:31, bob prohaska 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