From nobody Wed Sep 21 16:17:31 2022 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 4MXk8j2QlQz4cv6r for ; Wed, 21 Sep 2022 16:17:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205]) (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 4MXk8h3lxvz3KKC for ; Wed, 21 Sep 2022 16:17:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663777058; bh=gNbJkkqrUGlNwwHB/U2p4Gb6cr3oUFDWYaETiy+A3Tc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IM1TPaE1xEQ7UoALEL2+Z3W2qyDWAA2dUfMvA+LSXmqxKV8oVvcbQqc9kr8EauEboRmMonXCkOLn1TDIYX8D0NffA1CcC7gpTFp9WlT9j5GaRr/q2XPzK0oEMPfvWBXEwa9lqxcU3lMo/e0BmfXfC5asi0ErfCcHyH5Ns628P4d7FrZVHMI6DovY6UqQPBZ9Wq8qC6PrmZ//+FGSwc6xwfKNGpLAxgp6/L5B/rSPUdDKjXsW+5L2P9TxxBo+NefxEYFH38vuCcyqfqa3TArA3DtGKUjheJay5+SDbn4k13NrE+w/gYlwvWSU1jIMwI9s4iWOyJyowY/h33pjnpqBvQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1663777058; bh=GX75nRfoz3vKhMg75L7n+rvWnJdSWP+w/X0yOOdUr00=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hAQfaN4ljX6T5GRBKClru0hWMfD8apGxAYDCoPgMm4WoYDC546U1UCfdEAGBqDF1Dp05oFnN7kqbxTDmWWvyG2G43jCPPjk+rxHBWUEO4sC6dlgmYjm6rMsGgshli+j5Pwhx8ZT8V5LBL66wwZYv0SSnyVI6tyWGOjNTsKZ0ZEr2nOZJB38dZ1Un8YowcVARxLXqmezaQJ3PduccNlEqorMUnksXgQkltC/EGfQn0DFaRcu2SdQH4IihA96vkwH2XN6s5C1RUBiSmlCPFWkGpOmBEAG/OpNCB7vuOvYTP/OMT2mESsdRHzuHmX1UlN0GsqQ2dXRVRBwBuR8sC6IOyA== X-YMail-OSG: 1VIrilsVM1m0Om3lT_nwYeLcGsxtsqCc_axRUUGzOqW1HPbEkdQZIRkbSGcls_0 aEZjvv0c7I9.8gcyEuS8CXBYdeW0q2ATwfbVFwSwNAZwZCQwiSOj22If1SRVFAmGGjg2MhWlazJR MK0BI0ZPZrwExYlxyBf6vUYsaXGlK6hXqngPDIciZDaDxTo6AMNo..Bud39fLiSNvfchFh8toNbJ e69L8USGKJqBjJboSdDhIptztSlMCEE2t8GlvW0sOp9ik4afsPZ0xQfTnOpf4E1C6Ju6Z.BRxBlw wT0Xb7w2etD0Jp4QvP36.oWdh_mdr3Pvt6KqEuQtI5fIf32_x_6_4StwUYvlbvY9QNV6ewVPP4Y2 ZlQpLch9gskV2meunGrOO5W74he4SKDNw8YHRtx5NQg.nu5ISHlR0zYGF44aPPBvWtKAWCUO4MqB UWs4sZ4wCmhjkapfCO9igx_6iNg6F4WuDE.6.JL4pzRz6_N2x2UDm9sHDa13S8Gjq4_YBe0OwgxY I4kDY8acZho1MuXPHX7MvQgdJqSZ7yw.i6MSNcO_Nla_OTEbkmV7qDJJq7e1I625CFu_2UarUy_D ikRj.G4vBHzZz5dva51uyFSD_p1DRyua6aAETmnFjgT5UlG04KmxBRatxVu3aegMQU3MU4h0r1sh vs6wsuZ2t8fbKKzhleDjDhmBojGymYTsefFT_EmujCp6u.zidUpHlo.q5o_GRmWW_FoW4Z6IT2ow Y2TMOmszOjjh.Uu6KjS3HoW9p3SMYWZHXaPj7_2IMPUdQhrwM_V0z4.H5YagoEhT_ZD5B_lEHI.n csGziWJgavcjV7V1fU39a5F.rxtxx8nQib3UaF9lDd.v4y3R0LfITT8OiJCDpMDQkv6sbPnJPvLp TZjyOkKVBxJqlwcBeuI44J0_dR5xnU9leLNdssIVDZZ5LSqb3nIC3qwsbHPNfxNcSVjJ0N8xTN9d bQvoZKPmdfZAR61JMk4s9LZ_5kTWWKVAbmJ_vBIshrSBuTfYMmNoqqAh8n8lpSjJ1_lQVLcIGS5N s3BZGf_Zc19RpoqYM06odVyvzQDiUgwimcCJpPm7X4IfQFQMU38rCLj73oTEbtlqRyiFjXWSmGT0 kMm2yrAdstDKaiQo2eXBSq3oDI9P4Kax3gd3ec.ooRW_ikuqjq69ZJS1pAeI1Zys5ylCZ44TYTgM iMaqzziXrQstv1XFJkfiksjBDzi__NuEj_iLykTffJBxgfsZcoRjKcwZ9s9AxvgLEtxPjyU67Pvr s2yG_eMUcDMvqH8h0Tki9NfcU7S2ZoJQgHP4s_RF5ypGvLPc25NWbnNDa9Y3.r7fkl6pXgVtUeK0 IcNpEebA9HPg5SudDEpKSoRrBepnbDWjWaBJ1kpj1mBcypuZXkJQi1tCZp6vIo.w5c2a2TBm21eT U5DCRp30iqbYmpmipkjXPu2O8XnYlhUyyJG3LogIhVtIDtlmPXVcguWGadcAcwTnw3k2Bykv15qe J9RUb_O1Lq_j.KM_qbO1MzhWJwLXPVjKz4yhjtyuHis.R1g7oXvbLLzbEF.ukXbX2EAWnTVrYR.o _95CjAsAYpw640Uv2dmT_LHFs.qNrTmoipTo.xoa8bH87_lIgwimz5ZWvjwE.WxFbc6RO.QF1JKG Wxj9fDdXrmR9zN4r0a1mKIjcEf3hLp22ULt._.9xJo5PiBXwavpkBU3zjIFbBoWdIGQY.Gjb_Aht dSSfqwB3bFl7GNxYXUd85WuqVjkMxAYXI0s5iwhCW87D4j6J9NA8bpLiDJizg3mCIEpYtiqc84vs jEBhyS03C8oNVXvoIw0bzHRg_0idJFVSKSIs.iUq5Am4vw6VlSaPJcRWjzymNZQJuTmpfvfWUI.M BprnH0897B8Y39G7VDgSZeNSWWfx2qxU0U8DIWuTPWgW3qEq6ZttLVGGH7wzTnmyeezTGHHbHzOX DJa4MH4_QWgzK7Qi2LIq1Vk0cd2Jsk3zLd_LzHisPl33DMEqMJDMP1OEh6stmKDJotVUi55dNBuV 8ljOOWCQGj65.n.NdQX2n.H2A1zMFfR2I_3znxUp6q2Lq77oE29FKcLxd9RvOxF8xPm5dYGBj0lw tSpFRC_n0TE0u_Q92DIInRpkbj0_qyjE0tad6O_79PM.qYVP8iI5P2DD.5K3TwfIWHN_9lSc9oR5 yDqTJcFcbsLDvhBN5vTw.tiJBPcPmUJt74I3R3uh4QbxVlr7kufbpeR8R9rBL_uZZedQ95G0pOyC k4PMVDEqH5eZm31RsdyPFaI5SGsdRMtgWiQqYEfnqwcMy5dKCqYQIgvuoq8JvEok85aJwL2REUw9 l7ilB X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Wed, 21 Sep 2022 16:17:38 +0000 Received: by hermes--production-bf1-64b498bbdd-jgj48 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4e1531a1f5eaefb46c54afbd975eda05; Wed, 21 Sep 2022 16:17:33 +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.120.0.1.13\)) Subject: Re: U-boot on RPI3, sees disk but won't boot it From: Mark Millard In-Reply-To: <20220921154240.GA37735@www.zefox.net> Date: Wed, 21 Sep 2022 09:17:31 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <8CC2A42B-21AC-44C6-BD02-44D320CADF63@yahoo.com> References: <20220919221553.GA33878@www.zefox.net> <9A2A4E83-22F2-4441-82BF-0B8E6718ED34@yahoo.com> <20220921154240.GA37735@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4MXk8h3lxvz3KKC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=IM1TPaE1; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.86)[-0.863]; NEURAL_HAM_SHORT(-0.83)[-0.830]; 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]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.205:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Sep-21, at 08:42, bob prohaska wrote: > On Mon, Sep 19, 2022 at 05:26:08PM -0700, Mark Millard wrote: >>=20 >> U-Boot resets the bus, re-enumerates the devices, etc. This >> can time out or otherwise fail despite prior activity by the >> RPi* firmware that managed to use the device. >>=20 >> My NVMe USB SSD media have such issues with RPI4B's, also >> getting 0 found in U-Boot. This is why I build U-Boot using >> the patch: >>=20 >> # more = /usr/ports/sysutils/u-boot-rpi-arm64/files/patch-include_configs_rpi.h=20= >> --- include/configs/rpi.h.orig 2022-01-22 06:03:55.862541000 -0800 >> +++ include/configs/rpi.h 2022-01-22 06:03:05.435341000 -0800 >> @@ -210,6 +210,8 @@ >> ENV_DEVICE_SETTINGS \ >> ENV_DFU_SETTINGS \ >> ENV_MEM_LAYOUT_SETTINGS \ >> + "usb_pgood_delay=3D2000\0" \ >> + "usb_ready_retry=3D5\0" \ >> BOOTENV >>=20 >>=20 >>=20 >=20 > You're using u-boot-rpi-arm64, while I've been using u-boot-rpi3. > Does that matter? The description seems to imply not. u-boot-rpi-arm64 works for both RPi3B and RPi4B and is what the snapshot and release images for them are based on in modern times. I used to have my RPi* U-Boots be based on u-boot-rpi3 and u-boot-rpi4 before u-boot-rpi-arm64 was created and used for snapshots and releases. But I changed to track the actively used variant as the basis for my builds and installs of U-Boot for the aarch64 RPi*'s. But I still have the same patch in place for u-boot-rpi3 and for u-boot-rpi4 : # more /usr/ports/sysutils/u-boot-rpi3/files/patch-include_configs_rpi.h --- include/configs/rpi.h.orig 2022-01-22 06:03:55.862541000 -0800 +++ include/configs/rpi.h 2022-01-22 06:03:05.435341000 -0800 @@ -210,6 +210,8 @@ ENV_DEVICE_SETTINGS \ ENV_DFU_SETTINGS \ ENV_MEM_LAYOUT_SETTINGS \ + "usb_pgood_delay=3D2000\0" \ + "usb_ready_retry=3D5\0" \ BOOTENV =20 =20 # more /usr/ports/sysutils/u-boot-rpi4/files/patch-include_configs_rpi.h --- include/configs/rpi.h.orig 2022-01-22 06:03:55.862541000 -0800 +++ include/configs/rpi.h 2022-01-22 06:03:05.435341000 -0800 @@ -210,6 +210,8 @@ ENV_DEVICE_SETTINGS \ ENV_DFU_SETTINGS \ ENV_MEM_LAYOUT_SETTINGS \ + "usb_pgood_delay=3D2000\0" \ + "usb_ready_retry=3D5\0" \ BOOTENV =20 =20 For my boot media, all 3 U-Boots need the patch. For RPi4B's in my context, the turbo status is needed for both RPi4B U-Boot variants. (Unsure for RPi3B's.) >> #1: >>=20 >> I'm unsure if this applies to more than RPi4B's and the like . . . >>=20 >> Booting an RPi* can have the clock speed(s) vary during booting >> and this can mess up timeouts/waits/etc. during booting, timing >> too early, for example. I use one of: >>=20 >> init_turbo=3D60 # or other sufficient number of seconds >>=20 >> or, if I'm always after turbo mode for general operation, >>=20 >> force_turbo=3D1 >>=20 >> in config.txt to avoid the failure. >>=20 >=20 > A few experiments with either (but not both) > initial_turbo=3D60 [spelling per rpi docs, hope that's right] or > force_turbo=3D1=20 > didn't have obvious effect. Sometimes found disk, sometimes didn't. As I said, I had problems unless both the patch and the turbo status were in place --but on RPi4B's. I do not actively use a RPi3B but do have access to one. If needed I could at some point try the RPi3B via a powered hub being involved. > For what it's worth, I've been using a timeout file, essentially out > of habit. Renaming it to no.timeout seems to have no obvious effect.=20= > It's unclear to me if timeout affects both firmware and u-boot, or > just firmware.=20 I also have and leave in place the timeout file. But I've not tried to determine if it was necessary for the RPi4B's in some time. Having it just means one fewer thing to deal with possibly contributing. >=20 >=20 >> On the RPi4B's I have to boot based on both #0 and #1 being >> in place. Either not being in place can lead to the 0 found >> status. >>=20 >> A powered hub being involved adds complications not invovled >> in my context. >>=20 >=20 > It might be possible to boot without the powered hub, seems to > me it has worked in the past. I'll give that a try again. I seem to remember discussions of startup current requirements for some spinning rust in your RPi3B context. (The power situation for RPi4B's is far less problematical.) >>=20 >> What the RPi* firmware does to get U-Boot in place is not >> used by U-Boot for its activity. The RPi* firmware need >> not work the same as U-Boot, allowing for differing results. >>=20 >=20 > Ahh, I thought u-boot inherited at least some environmental > details from the firmware. Thanks for the clarification! Resetting the bus and reenumating the media is how the not-found status happens. That is what the block of output from U-Boot is about for the 0 found message (and somewhat before). >> I warn that my notes above are based on RPi4B activity, not >> RPi3B use. Also, no power hub use is involved. How much >> applies to your context is a valid question. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com