From nobody Sun Jul 10 04:23:42 2022 X-Original-To: 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 DCB6C1CFD005 for ; Sun, 10 Jul 2022 04:23:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LgYmg58DRz4304 for ; Sun, 10 Jul 2022 04:23:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657427025; bh=vt54lmKJRwLqdxpxO0N9PC39NH8iG9wCFYVIlfJWqKQ=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=nkgQLxmBYH1N5XbRk9yadVBrcLt/UreDeiPfS4E+bZ+DHFJqGSpcFoudk/ogr/cucZNgKjI0aeRaB4AUT2A/KYnMdYwT+V+oulgZufRQ10zE/J5Z9Zwt24565fqbofYf9O4OQOuVqAj1kjiyFlvx45hgo2rqIQnTV2nkA90hnkqkqgqGgmIFi+yqkfjABvl0HlY7/tXSFlL3lvFl5k4IWF9uDxRcQbAdgOlqdD5zqFHjcj18uzKaGhXVkxo2MRcKncWtXiKBxcodSp+8PbJTRtXmZnlCI7xYXC9lW2DCH6T7BZQq4CxUXcv0SzdcBm0m/DkFop6hb8h8SYPuYukWpA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657427025; bh=qTjG606GezQfB/zrq8zULw+444GLOjxZUFLieBj2pEY=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=qnOizHEFkkkSMdpZB/90ZsW0gcj+qQd5dXqIh4wsVkYkUHzL3elYq8v8qqs5jjD8Wvp5Pl8gjdMB8qXiFZInekjh6IGLu0DQqguGmDAJu0pgesm+orMOy4ILZnvBgBSIk72BKQp034DyPvXVTVuECd6It2nxLJokYSRHswXJBpf8agCwHmJ5cqCTsyMa7e3c89Uzg9DJKo5ABpMAHSxGE1GdFhDW644tUCbQXhoXuPCvP+iFEO4ThQHEiuXjdvuf+Jo7/nLERJ9bGwrp9iR0J5MLcsiNHroQDsfRJo6NnuQZrUpEl/8SiTzY1I6sNHPQTe0cpsRCNQo0L3e7CKUQBQ== X-YMail-OSG: gYh2wKsVM1m4f.RI6sPJI8ozSDR1XEVte6B6kQl5RchF6AGmdi8e0mXV5h8neoU e8BT_6v7Ls3UADP0Z_tKfHyyAj8IuMhPnjVyC1m74kIo2j3F3JcbFThSl2V9wMGZNcjg.5EtWiFI AMGY0RzWKS0dVTzbZDoL3DNUTmhZOTD2lyRe7SAvx6bIWkwsXbQCUw2P3KI3Q7fZoclYCj6YWeTN 1kNu34pQAakZrS146IhaejqzF9jSsiIDu0q2y81BVSTHjdNHVyiUVNUoTpCTtdvvztScFAyHfo89 CtfquU9uezahePdlbOfsTqObG27_j.1rdhoTtc8TthdkwwAOkpcF6tssfsLxADM8_lKEfHocXa4H B7bF1JmGF7_290TL.v7Drfb9YC2vLSNidXeAeZgWpYdIHukCjQ.W.oK94pEiO6dItbV3j.eWVwqm w.12C9c9GsOXzbtxp65da.cuK0cuUSH4d.nByX.8G9JOPJCcza8mzW2sBg_EtuJmbJvjlid7oZ7R isrJnfkZBWvTYNXTDTHuFNsqB.t3Lw9c8ugMIDPk3Z01Dg5_jDLzndcMZxYKtpbeN6Mi1i7Iqm64 0dBXpDdswbog.TqbDMtdN6o.gXyjBbXZ7g0JzDBxBO3WdFRf35HiX7CPzT5U2N.ZGAooGz6aqeGy bxvjLwDo1aXRHePxWXqmCgEGyAn2Ke6sMDKntGfrodXLw1jBdZXZr4Kz4VHY2b1N2WlbYqGYtfkU lVRGQ8qa57JMx5DpRuEFiClYfLyxO9CSTFOucWtVrpbk7zoPC.GyW0636CDxJytx9qJHDCqKBTu_ ie4gWdEd6aP5BQa69q3v_HwWl.nuzBBK2XuCUt4BpM4NfSKjumsqgLv8IbUMjqaxStsBN8d.D7c5 OQ4guICI7BruT67rx0XE5hePwYPQseKRvA_Yg1INcYTLmAdu4KiIEE25X1qy6Z8v8N5Xkfjy6ch6 kokwdiB7W6RRJ6IRmgvprXrJhQTX1SRQgToFhNbdgd71PulIE59U9t2FKdX9IkyXyGAxNh0rlGQ3 XCQgaWCrP_ZjwvMj6c0SlUOtPe6bnaPKWvUZkgk_CiKA9_Ph79Rr8x65uEuPtIK996Y1zMFn8CUF OqLCZRAglWydEFniBkVLYcnSIwLCSNjdf8hMISyqnt0BYFseQR.e2wBOKVTw._T1Pf4RARQcURq9 4x9uW5tpNYniyUUubhcpBjtSkunhDDKhqNNtpRlWc2ZsJiVyGSveSKG426cyWB0K.xZ_5ZIwFXv1 Jb77i3E58Pr5JSu.jRppn7ishVfyYZLd3SbawhE7NVS6.41arGWjwsB7UpIKyIb07ppWfcpmD9HS Gyv.wRRR1pjo.1Oam1hRf5gFL4JxenaKt7AEfic7oRLHs9XxGfK0I_4_SpYBKUdFpyfESthgSAFA PfmZqlZkE9N_Qs85M78voSggwGSWCCWQlxnqx1YHwUsWI.alSwqNtTq9_rTRwNWSXij6vhsbLy.n IvfXw.vp1ibSX4OkGwpc.oCWwIVAj.9mQT5urabN4jn2o5cp5P9pKyUnTwWBLO.niqS3XTlADta0 ieOir1fORFHaol9PBNho9uPDBH9T.OOphuO6UQORx1TCKrZNjr8JdWSrn701FTLOYt3h4h0ifz.U XF129SRQcesrP6s9vOzZxgAKZymCAMcECtj79WMyrnmdP_J50mUqzBa5kputB3MFNIEvrx5R39BN OjHrdru6.FH6Xm04DQqKJ87Vh32l43MHNgp5vZuqgFfzq9Jig30Iu.l0XDUsmfu5uwxixMuXAdTz RNBIAEO5_ZldcvjxW68PMrBvJknrjkdlh_BhcV46vWLzXOVWYeMdMTrqr8jzjNiQpP_LVVLq7YCq Bmr0ukjK8PTSQ41RE4Z1FVBdz5BBiejiEDVpcLGY0tNqTPdUs8Uv727QSsYYoP8bXnR9FLGUrF69 EW5X.0yKj5nTOyrZkGuMMwQKnCwOOOk7G_jWALUuoVvZZXC1nNviiUvM7N7H8hfPz7Tf_XtrMIZt Q5bOngUC6D_N_cyTSVrb4ID_PdgGl.Y8ZENk_seDVG1pttZBs3SNnnI8r44FG0clHJKY0Vq8oFgS GTKnaRrlchu7MJMr3Jsx2_anm6ssXTDWUiW0IdJXDY.gEVZoaMJj2vsN40clbcGpqY9cjUwnjctl xgiAJfFJu3VSbUJ38oKGMgdZqIgNS1zMXvj3SfpQxd7fUk3fhmANHvj1sEuCQqF8SAs8mEgOMJKJ yxj8eI3oS9VaFRA.NPKBU94hJAmaLcqEQHbT8RXXkSC45L.oUNAKY4k8NgYfRYmWTTXBxDzQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Jul 2022 04:23:45 +0000 Received: by hermes--production-gq1-56bb98dbc7-r7f9c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8522a468239f1b16f16898db547d0c40; Sun, 10 Jul 2022 04:23:43 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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.120.0.1.13\)) Subject: Re: 13.1-RELEASE image fails to boot Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) when dd'd to the example USB3 media then used to try to boot via USB3 port Date: Sat, 9 Jul 2022 21:23:42 -0700 References: <77F18A4B-6B89-478A-A0CF-306866014536@yahoo.com> To: "freebsd-arm@freebsd.org" In-Reply-To: <77F18A4B-6B89-478A-A0CF-306866014536@yahoo.com> Message-Id: <0AB0761B-4E22-4181-A29D-F0260B6F8055@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LgYmg58DRz4304 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nkgQLxmB; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[arm] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jul-9, at 18:59, Mark Millard wrote: > On 2022-Jul-5, at 15:45, Mark Millard wrote: >=20 >> On 2022-Jul-5, at 14:17, Mark Millard wrote: >>=20 >>> Summary for Rev 1.4 8 GiByte RPi4B (B0T vintage SOC) context: >>>=20 >>> A) One type of USB3 media (USB2 compatible) works for booting via = USB2-port. >>> B) The same media fails for USB3-port based boot attempts. >>> C) I boot the same type of media for main [so: 14] instead of = 13.1-RELEASE. >>> D) An alternate type of USB3 media (USB2 compatible) booted via USB3 = just >>> fine via 13.1-RELEASE. >>>=20 >>> The details . . . >>>=20 >>> I intended for for use in the Rev 1.4 8 GiByte RPi4B's >>> by first going onto USB3 media (of the same kind I >>> normally use on the RPi4B's with main and the like). >>> So, I tried:=20 >>>=20 >>> # dd if=3DFreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da0 \ >>> bs=3D1m conv=3Dsync status=3Dprogress >>>=20 >>> and then tried to boot the RPi4B via the media and it gets >>> the following (the kernel loads and runs but . . .): >>>=20 >>> . . . >>> Trying to mount root from ufs:/dev/ufs/rootfs [rw]... >>> uhub0: 5 ports with 4 removable, self powered >>> ugen0.2: at usbus0 >>> uhub1 on uhub0 >>> uhub1: = on usbus0 >>> Root mount waiting for: usbus0 >>> uhub1: 4 ports with 4 removable, self powered >>> Root mount waiting for: usbus0 >>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT >>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = 3 >>> mountroot: waiting for device /dev/ufs/rootfs... >>> Mounting from ufs:/dev/ufs/rootfs failed with error 19. >>>=20 >>> Loader variables: >>> vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs >>> vfs.root.mountfrom.options=3Drw >>>=20 >>> Manual root filesystem specification: >>> : [options] >>> Mount using filesystem >>> and with the specified (optional) option list. >>>=20 >>> eg. ufs:/dev/da0s1a >>> zfs:zroot/ROOT/default >>> cd9660:/dev/cd0 ro >>> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >>>=20 >>> ? List valid disk boot devices >>> . Yield 1 second (for background tasks) >>> Abort manual input >>>=20 >>> mountroot>=20 >>>=20 >>> Plugging into the other USB3 port and attempting the >>> power on boot just changes the port numbers from 3 to 2 >>> in the sequence. >>>=20 >>> Plugging into a USB2 port does not have the problem and >>> it completes the boot and operates. (The media is USB3 >>> but USB2 compatible as well.) >>>=20 >>> Adding to /boot/loader.conf : >>>=20 >>> # First, 3 additions: >>> kern.cam.boot_delay=3D10000 >>> vfs.mountroot.timeout=3D10 >>> vfs.root_mount_always_wait=3D1 >>>=20 >>> and retrying via a USB3 port just results in: >>>=20 >>> . . . >>> Root mount waiting for: usbus0 CAM >>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_TIMEOUT >>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = 3 >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Mounting from ufs:/dev/ufs/rootfs failed with error 2; retrying for = 10 more seconds >>> Mounting from ufs:/dev/ufs/rootfs failed with error 2. >>>=20 >>> Loader variables: >>> vfs.root.mountfrom=3Dufs:/dev/ufs/rootfs >>> vfs.root.mountfrom.options=3Drw >>>=20 >>> Manual root filesystem specification: >>> : [options] >>> Mount using filesystem >>> and with the specified (optional) option list. >>>=20 >>> eg. ufs:/dev/da0s1a >>> zfs:zroot/ROOT/default >>> cd9660:/dev/cd0 ro >>> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >>>=20 >>> ? List valid disk boot devices >>> . Yield 1 second (for background tasks) >>> Abort manual input >>>=20 >>> mountroot>=20 >>>=20 >>> So: same problem. >>>=20 >>> For reference, from the media being plugged into a different >>> aarch64 FeeBSD machine running main: >>>=20 >>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage = device Samsung PSSD T7 Touch (0x04e8:0x4001) >>> ugen1.5: at usbus1 >>> umass0 on uhub4 >>> umass0: on = usbus1 >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>> umass0:6:0: Attached to scbus6 >>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI device >>> da0: Serial Number REDACTED >>> da0: 400.000MB/s transfers >>> da0: 953869MB (1953525168 512 byte sectors) >>> da0: quirks=3D0x2 >>>=20 >>> The RPi4B is of a vintage that has the "3 GiByte DMA" issue >>> present, not that it would be likely to be contributing here. >>>=20 >>>=20 >>> So I then tried the sequence using a different type of USB3 >>> media (also USB2 compatible), placed in a USB3 port to boot: >>>=20 >>> usb_msc_auto_quirk: UQ_MSC_NO_GETMAXLUN set for USB mass storage = device OWC Envoy Pro mini (0x1e91:0xa2a5) >>> ugen1.5: at usbus1 >>> umass0 on uhub4 >>> umass0: on = usbus1 >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>> umass0:6:0: Attached to scbus6 >>> da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI device >>> da0: Serial Number REDACTED >>> da0: 400.000MB/s transfers >>> da0: 228936MB (468862128 512 byte sectors) >>> da0: quirks=3D0x2 >>>=20 >>> For this media, the sequence worked and booted successfully. >>>=20 >>>=20 >>> So the issue is somehow specific to some USB3 media=20 >>> used in the USB3 ports but not to others. "reset failed, >>> error=3DUSB_ERR_TIMEOUT" may need more time or better >>> recovery if a wider range of boot devices are to be >>> supported. May be the T7 Touch needs more than the >>> standard amount of time to reset as a USB3 device or >>> some such. (I've no clue about the details.) >>=20 >> I substituted a 13-STABLE kernel.txz expansion and got the >> same result using that kernel. (There are not .img files >> for this currently.) >=20 > I took a different path of setting up a stable/13 based > media, based on my own build context but upgrading a > 13.1-RELEASE starting point. This stable/13 variant boots > the RPi4B's just fine via the USB3 media that 13.1-RELEASE > failed to boot with. I'm not sure what the differences > that matter are. >=20 Well, the kernel.txz was based on: Thu, 30 Jun 2022 =E2=80=A2 git: 70fd40edb869 - stable/13 - debugnet: Fix an error = handling bug in the DDB command tokenizer Mark Johnston via: Fri, 01 Jul 2022 =E2=80=A2 New FreeBSD snapshots available: stable/13 (20220701 = 70fd40edb86) Glen Barber while my build was based on: stable/13-n251684-815db559eccc-dirty (815db559eccc is from Wed, 06 Jul 2022) Between those are: Fri, 01 Jul 2022 =E2=80=A2 git: 39cd7aa134df - stable/13 - USB: add quirks to = XHCI Bjoern A. Zeeb =E2=80=A2 git: 66754c01ff95 - stable/13 - XHCI: clear warm and = port reset Bjoern A. Zeeb and that last mentions port reset handling explicitly. It is, at least, suggestive. > For reference for the working stable/13 context and > other content involved: >=20 > # strings -a /boot/efi/start4.elf | grep VC_BUILD_ID_=20 > 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) >=20 > (/boot/efi/armstub8-gic.bin does not have very useful > version-string information.) >=20 > # strings -a /boot/efi/u-boot.bin | grep 'U-Boot 20' > U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000) >=20 > Note: To my knowledge, the RPi* firmware, armstub8-gic.bin > file, and u-boot.bin file above are all as they were for > 13.1-RELEASE's image, other that for 13.1-RELEASE I had > also tried adding /boot/efi/timeout and I've left that > in place since then and I've added my usual > /boot/efi/config.txt material (that had also not made a > difference for 13.1-RELEASE). >=20 > (/boot/efi/EFI/BOOT/bootaa64.efi and > /boot/efi/EFI/freebsd/loader.efi do not have very useful > version-string information.) >=20 > # uname -apKU # manually line split > FreeBSD 13S-ufs 13.1-STABLE FreeBSD 13.1-STABLE #40 > stable/13-n251684-815db559eccc-dirty: Sat Jul 9 14:02:23 PDT 2022 > = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1301505 1301505 >=20 >=20 > Unfortunately, it has been some time since a >=20 > FreeBSD-13.1-STABLE-arm64-aarch64-RPI-*.img >=20 > (a snapshot) has managed to build and be distributed. > I'm not sure what the result would be like for such at > this point. >=20 > Once such is available, I may do an experiment based on > just a stable/13 snapshot. >=20 >> But using: >>=20 >> = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.img >>=20 >> does not have the problem. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com