From nobody Sun Jun 06 17:34:26 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 9D21395ABB5 for ; Sun, 6 Jun 2021 17:34:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4FykCF2R5cz3P2J for ; Sun, 6 Jun 2021 17:34:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623000871; bh=UkL0wam1mQX3a4sN/mWUfD4Z40kA+5VSy7aE5t1u5hw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=QGCzCar3ZVCWNgwDOTC1+bHSSM3o2HJ5R269Khk2FBouvwnT/Q4uLm6k27hW6JS54TQZ++dHeF1BMBFvjvU5y6rNPSIrSWyRyYLvF2IWMMY7cnuuAFebusrX5kGZtl0ESu77S9AO/BI2PDeBHDYmes7a0ZWmdzljrq3dMC7f6iv7pMHQydL9GqkmagYV5MLSftuKhKx5anRrkZIgAq4BWrf8exBg60zNm7EhB/rA2eptm0rSpQ2inVv0cQzKpOmcIEwURs/Ul1oykJ2o09Pe7Ne9vqWsyG6hWlmdwhwaBV5bHZap5tQ7rBr5RotQgFoOCfN1pOUZZcthotw3Byryzw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623000871; bh=Bxcxt5xiutPXz07Dj/tfGBGeKO5XnyxZIUwR8uytA0c=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hbbIkD8Lv4C7z6IlNsNxPxx8U/33MofW6s63sOlJaZve3F4soczpuh7Z7rLhxVfitp7hr1ZiWh68yxP/EHaX9tBbNBdCBijegP0GV8mNEwUfbkQ/lOYYSzTp6kRsBD8sAJtVYRRxcbvW6+zZkMnRIyiuAfjyFN42/bA5jRc4wATgBmcKNG9/CprKKoHKGh7340j7LJSvcRzecpuLTvASHWvq23NtFYhaLLSQSoXzk+ot3KXSPLO8XdQw08FHkTQXibuqJ4Xd5+Tx0aYgrv2snU2tiDGFWRGBiaq1ZXaFfRHEFhzWyKVNiWK6T0yWdAnTMlFVLZvuyNIWxl3oNcrIqw== X-YMail-OSG: .K8L8ogVM1k6gvoVoAUkbuk9eStIe9P.5V7rgTlQIjo98wBbtkuUg04zevvPvfP gmAdDsq.WjRCHjIn6urJOj.zGxvTJHf5GGKD0C2I_ogyZr0cb8wOo.DIGHDqndnRl1gqzKJt3x8g Q36x3gkHgSSgnqFKtvBy8Nt9YtxPkyEp.CLY.oJCbW088WeZbugc5gxDL.sBZDhl8ingt.6A5yFO S3Gnfd4BCfK_bQIWks_KPIITZsaglgpBFacngsBFLEXE5srIWESJZl820VtWkB7ToujyI4P98yrj 2NHzzKbWK_IuttfpG.MHYqh.9IXxBTTk6MROWBIWFO0BBJI0qWEbYX6j7ijcsI84_ycDPpQIVWV6 4.XMPOC.k9l_FIq6HEOIRsVNpgle9FyrBQ8Evp9ug5MfVrCgCYMXGrESkAtXyXeosFl7dGspg3aL kMMARNbdIRrvws9OXSxaHKD3TvvM3b8v.J7DBUTp_WlAGmnTiZ1qXm7MuHivAltqx8o8JtIWuF7n ha_3kquDXwHefna6X6owCi4WBwzfbffWdezmj2KJMz5mbtwfxl.PK5p6lQkF6IYBev7PYFyKpZ8o v_kS1CoA98Qgb3yDBIIMNIVB.yf2JgDfTdxwF7nz91HX24OVm59vT0rk_AwIcg6NrVk4EWnSAZwQ PJqYYJu6NUGVAbdehJM8_Xb6o._xawgp4EDhTrAB9vL4E6aerQ5EGziv25yBxlPpeBFYOMUEZbhQ AwG0vaIb2XSyxn95h8lHg8xLzGMJ91D3CO.OsKZ_KKXe6UgzIjDPxjafhj4xE4AMvR.0V3egQPks RT03pHI3m9xEGaS_0NQX0w0Vz6Mcm9NsHDY6zlP5BF.a1JM9FIXfBayP9SNScc_F8BpVasoh9pLM xRiWzkOAtkbsAwFzX069ash4fJ.6VS0W5i8oXFtbZN_p_E59PKvOiEiGYOL0mbkyUDMkwzgyru6Y aFTKfwwK5L9n8kA_hBEUl8Masp6AJVm9fbnNRrX.E7LiShlp8dBzq59aaJKLab0_zNalVyoffVHw Cret3IqLPrp.Z1pqNz4FP5zjlLs5kX2UbUpzZlezMTdfhQNjxfWbMV3a0vKN1qCcvDeLipLgjaAM AZjPrPZrHmfp3tGWeFE8wwxnRegGf3dDYEAK.x_k_TvCozjJfEQoaAjB1mbgJ5FdFQ4yMq7Te9c4 eQVG2RC.XhAWs4OUTIyZuBOzrDFacM3CEdThWieFCHowxpICuZGHvU2s95z8ynDQAhy97VaZi1Zf ZZHBlnQhio.Oc8j026sMNahaPWtTRVlflcJ0iRQsPBHsvcq7WeaK_Echs8Z0_v7yitJLNIsb.ntv E9lvotFmHgCPpvNYdMJ0Nffbg9HhX6mWDGinZa.nfE4Vinmsf2PAny7DFRkhEge9YCm5E4U8l_Ba uxisUSEGQKrRoRbDJNCXFJVvkF8nErhkObNMV8ga9kOiO1ZC5yKHAT0cymfv0MWOMPjw_A7rJNsO Z3f_1ZMtpZV0me6FEn8trLavvj9pMRVVX3HfLc.1rTnF2mgUfPiQNPsEI0fk8xvlRbEBRE_hUOrq P.93Wlsy6HwtMooiRqUh8BbsSYvPJBO08xZN.8aaJPx98cMwxy_WSVFcPSFlfF_FX4iG6_YpPO7a RwZybey89lGxUr5egWQefaSZSLUqQsaj1GWWVhk3.aHi6b3vxBKSEPABgCxyvRR.yv1d8.aWMrDa 6kRUChMpxUulABXRTzpLKT8rgwJUQxP7vdB1M20kaKuMm7Kq2MdC0GBFgHl4i8rO6HPkKCVnyd.d O.wen5vG9qBTlqhPpd5HMNl.EIwmhyVCB0wDO2W96v2d_w7HDmA8Uc7O5GdGPIojxh04s50Jd14B K2NgBkmjlfCNstLNmkuvGgdf2L.nIIJZAg02zSwvaJwMxnMISZuX594eQ_xwjvDhfnSGD9NaBM0D EkRHRkA6Qf4JQgF5eC7BjL4SUZkvsIfOFVZNHIPr8G_hdAgTWcHLUU6j0BUzOa6EPiuLLPYtYAa8 dnb0xzn2fmpZaThyjnfzZzIC.gOLQrlXQ8sdBH31V3UhXucxJFkE5rPag0PL1xOkqQqkRKAGfnZn UtyW8rqI2ExE099w8FmBiIvYXATFGxbUMnY34simqgtK1qVDX1rfUZqXH47QRd7jmuRNTdzEibEm BvFJ4eqPxug_aqucVMZzzL5OgaKq3D3eUtyHerarr9JJ46Sl2aNBcj6q2fpSYdPExlIGhdQpQTm6 1lJ8VwIbNcF9gSkNMxDSZ2Gs.doSsXb57ksPmux66UGFznLtXvuLNDB9Q5XlxaY_u253iH1gjdxe atR4SL.xtWYvLWx.d8laIHl7Dnj4stQXt4rs9xbFgEzTIvwrjV3FugI_jmDdYROLkKMpViaDgDiQ QrTVu3QwlLWZyWstAkxvMNOQVwagtS48YCRVdzyOoKZEeRFcvY5e1DdD3mVjhT3Ajq4D4jsyJ98G 3uwwxqi659RkdIDQFD3EL7ZF6Kcv5b1VQNc3NVv..qBpP7fL7rQ3RpTAqgPFDkINEPA8WbxI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 6 Jun 2021 17:34:31 +0000 Received: by kubenode564.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 12ca7ccffb1585e0654eb8a1e7698377; Sun, 06 Jun 2021 17:34:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Subject: Re: Strange u-boot behavior In-Reply-To: <20210606160040.GA97697@www.zefox.net> Date: Sun, 6 Jun 2021 10:34:26 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Rspamd-Queue-Id: 4FykCF2R5cz3P2J X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-6, at 09:00, bob prohaska 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 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)