From nobody Sun Jul 10 01:59:47 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 096E03E03B0 for ; Sun, 10 Jul 2022 01:59:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.146]) (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 4LgVZc6t6Qz3nCr for ; Sun, 10 Jul 2022 01:59:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657418390; bh=EMFUDbG6EpASpYONw0+Py3zC1f/QClcd24thVTehAjg=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=jXHtjX8vSGWgGnO9GhX66ZzW49QlnkkZd6c1Vx55ByOHU9aXT5E1gwsI5FHafdPAUsfMD17UGGcZHbQP20afMluSvCm6rvUAZXk/DILNuyl5XEcv6hEkg78rzhWjLTfY2XOVNhod6e4j+9h9q8yADGwoJa6f6c96bMPgu217273rEwZJhILd+lr4L4p1UKjkMFjAZE2l/lSNtTJTlMnQ1tU5pY0BcGeh+//KSgHI5AnnjlhUtS3FLM0RoTS6zqebPqNtK2aBhHjnnMP8pgjI/1mZT+jluzstXxx00Vn2UE5jTana8b68yvynRpAME9MxSRlONF8jHhYBtCkZOptlEQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657418390; bh=OqfMM/WE5Ku85qsSQY+SCJNpDJFOyq/GD62cMs7ucoV=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=rDf84ELYTxi5uB8j307skYzQJa2k47JxiHK5b/CnFqhi5PDIpnpwV7sBwCkchiqTwlMsER/xuydQ6yJisMgyeqjQzEkkK6TCYvCUiHTHk8J1FD7dd0yA5R4hZwVMOxmx1+meAFDd78ES6SWMi/pn0egfDRRxk3utCHGbcZD7cj5NAT1/8IG0ae4VzyBaxp0Oi3bAlOmSpgg1W/thV1mm4GLV1YpqruWL5hH+aSP4ZDX+EAG0sMeDkH7cYld1EeS9zfTlqiLTHz0dkJHeI0zlDB0z6eg1SN0fd6HSJUOwGjw9rbFidT3B6oWkNUVp//7DVJLaIDaTFnUXTynZ5LAelQ== X-YMail-OSG: 8b7.QaAVM1neYtdEUHO.3MkWabWXrztGzBYydZE_D8jA13rB.Ej_x1RQMS19cek BPjc0DlKJ0qEYjhon6jQKiqWK5Uuazi7HRtJyXNblw3nnTca7Nnx10PjjimNtBibSHGlVn27yXBl Thcjw03rwHiMw1Sx3vDK16cFr3g3wPIPq0MXjjbHbyY5XViKVIMw1dhQ4m7eJLDLm8U8saTNKCjt zyUCfw.qU1CL6t_qxyeeZoZ1CLR4tTyivuOS80u3tRuTSYatT8cny4Tdo2MiGscFjun5NEu4LDse 6Fn80i.SWNWuytsl7f003uI_O.8PQaqreCV3Vu8kf3bP9PhCX9nWBjvx4BafDAaMQ0sk0weOL8E6 aP4ovjc8.pYpPSF8BHP_1uHFZqneDeDVT2TLetAUgbNDuFVfVY8roVINP.vQhYb85UVaYjwz9PLQ j2ZphMbHKJZGLVETAg2fxIBgd5Sd00ojuUEhKeuUhDeKoUGfwrFr.I9Z5RHWPqeO5t4ViY.YyZ2u f_JhGjSonNg2mPlWRFpyrsl9TrpMUpF1f4oca37rUjiNsU.5lj8_p4CKLdIm7EbzsmQXuT9hV7Ks i.dGk7LKRq.pVzMSS6bimf.pP2Poxtj0H3twe9VWtg2OdmbVG6zWX69VnjRAepeO9oxzfhZow2XF lCc13EmiQPTBvsDyJtRrmWkbF_tdLAn2Xe9TqYLnx8Kv1LkDaikOpsyL_S.WLX0eqSSlljM99UQ7 HwUkBv1_u_82Uh8AbCZGpogVtl4MNLauB8FjoLmBMA4_ATkom_5xi802DiTVlfc2LJf6JeAOcBdx vE9rnJ2_q5d0UB60YL_4vhR6Bt3WCyOGfs0IIRgUgDajdRoOZyPjTQRrY59UviTksu0CcSTn7rlG 1p75gflav1IyKzq9oH637tsxCyb.ObE0yZVHI5_V82HWWp4Vmizq_hBeoROUj3NhddGUqV8sklSl m4X9NoZPhING5MEupQH1bOBVoBdac7dYoq7LqRQrq8uv.znizbnMJICTmSqtFOELAAYg6R6Asm7i Chbx7mRUWktYwXW5y.k7utFk8iOtwGqfFbxIYUq57J8Y.pK2bT3axjnnSAfEJXIRnrah.VLi4qf3 a4RXdYmFQpgzgIo2Dfx__k9E8_NQApzyLBTwJyer3K6UvT2wiJUtgRddDF4io0rqkEN45UvfhW6z A92i5HVRdV0UzkTRSttlc3GArbNCsFloyAPZcrDSGAYTt.veNGlQ48ndvRjNiZeAjmTqT1GRi7MJ lsa3N1WLD8s.pYT2hlAV4zRfeLTntMXoTZWW.DEDiY12oL19gsqR.SB4K64FHGHu1p1ZMVHqp.Fk 6YbTFZSxA7.OdZtvPQXjGYbXtZmb3ZkQC.pYeFuMxmFnhEBGx6j5l6vfIyTT76K9n6mQYHB62lZS X7jbvxtTR5oJx3Y5a3DdztlFbFiCsTTnQ9YjwqLHILkKUckTks_jReRpT4qCIxGQIL7SF26waXZW 1pNbOJDpa8sfd5.KikRH1rQCZtZ9Vi.uHI76ZNOzywyaPPV6xLMykqtT3r4XTNOmsDJwOsb0f6WR xmB1R3Om4EktAMe9VGyfMnXeijtz7EJwrizjHQxrGDXrGewkDBRyIy8CMIE_VqVdT2c2bssm9fqM WUedxddYoVJsDAIJ_P6hA4YpncBPEoyZ.vUhNgLNIpJdzYjkKfK7NbygyRcGEWFnAbKpE13zZOIW GtgmygMjM6Zda7kMuVGueKUtW0fOrbcDgOV4HUUq5apTkUFakiHeEmhmtknO31o7WaIT_DYqwGup h95BpOyPMcro4sOiUCxKGN0yRO8zYj7g_47.ER.zRJQrRpZ.qX7wLKfr3VTLGVuWxMFv3cvAi.pu 9Q9JZo7nD7fYVDeC36BsXqmk37aG10zrnhvbVPymFPySySDk4DksAVpqHl2_zVX5144ZfeL7_qy3 BgjDtcu35NjrplocbmBBWApeRkeM3XbcYDLfCV70L_tJycqlijWEX52j2BS0SdsvS_5vYf2r3mSK 4QUT_y4Rml19Yx26EBFN_PFs8Dh33TwVQLPRgFPzxktNwlDUiCKdE5v9WBScOuStYv2AJeillOgs IShUPGMgO32KjQxrWJ1O0b7CnSEUQxrlSyqgLIm7i5uogf7uYPLOl_n42NqcR8LBuW8YlHgw1Z8v ypiVBlYSym86M7zSH7iGypZkHbCIUiCoZ8PQQbyMFgFMxHtEvvmOyPOeHyvo8Ip8DisEcjtn3Fzz GxjcM7bf0CBLTvn8UGzhReUM39ZImRCnhmrnrTe6QEXDUkrXaBVkEcIgqR17wDWfXTg9KvNwY X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Jul 2022 01:59:50 +0000 Received: by hermes--production-gq1-56bb98dbc7-28prh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 53aac7eaa1534f6abdcb979599b69622; Sun, 10 Jul 2022 01:59:48 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii 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 18:59:47 -0700 References: To: "freebsd-arm@freebsd.org" In-Reply-To: Message-Id: <77F18A4B-6B89-478A-A0CF-306866014536@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LgVZc6t6Qz3nCr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jXHtjX8v; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.47 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.98)[-0.975]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[arm]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jul-5, at 15:45, Mark Millard wrote: > 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.) 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. For reference for the working stable/13 context and other content involved: # 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) (/boot/efi/armstub8-gic.bin does not have very useful version-string information.) # strings -a /boot/efi/u-boot.bin | grep 'U-Boot 20' U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000) 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). (/boot/efi/EFI/BOOT/bootaa64.efi and /boot/efi/EFI/freebsd/loader.efi do not have very useful version-string information.) # 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 Unfortunately, it has been some time since a FreeBSD-13.1-STABLE-arm64-aarch64-RPI-*.img (a snapshot) has managed to build and be distributed. I'm not sure what the result would be like for such at this point. Once such is available, I may do an experiment based on just a stable/13 snapshot. > But using: >=20 > FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220701-9aa02d5120a-256480.img >=20 > does not have the problem. =3D=3D=3D Mark Millard marklmi at yahoo.com