From nobody Sat Jul 16 18:19:06 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 4Llc1s5FL2z4X8TZ for ; Sat, 16 Jul 2022 18:19:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.30]) (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 4Llc1r60Fkz3wtv for ; Sat, 16 Jul 2022 18:19:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657995550; bh=By+rSL4znBoX3XBPjBFtGEnOsPtbUyxTS92WpeSImoc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=J06NGJ2/qQFnucyuyh4ocp43Il3qHlNFCLssV+KKXjIKpqnGOF/R9n5BOHu7joU3S9y+q9puvwbX6cK+vq1FYRBuOapN6fO7sRuFci74inMTeyGIz8USOOv+vvJ+yV2uIMIM4VP0qo3q59wjrJiVLJAFQAjd6dOydR0q1U7R761PurlKRVHWP8+dzwFstkpSWvox8W5Tyb+0plT+/SPx2Oa1UpCZc3Ir8xvJV5WjeTtzKsxmFYVXf4zJpALU6q/2wNvy8oj3gDWn1883gw3Du2H6jWIdfj4C7HBWTf83jDEf3IuR/ul6+g0czGXm4ur07n641qFvAk9+2mi5u7C3lw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1657995550; bh=Giuc6fhc4F8pkFdcwWVcySQiOvjXhREyedm4caJDYSi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Spe7rWwtAT5gdKqrDmnHdJMhlXldyUwyYd3ftW7jwoWdngNAwm5sOQRBdxBuFuOhqcR5Xs4propNBOeks+5+pw+3uD1UeXGCMHKaGPmC39sq43M+x+Ul8YSu8OMYqekUFHRnWIDbMET0Hzcm3/uYrS58pE+biSr4r6uTyrsb9E8Ka3TBSIXfoy58GVkcVro6LCg5dZteRnCj4nqUAAR/JqUoNrYXHFuNAJxBTmVi+AotoejwkxWuIBA1PPMyv8xkV7qo5tm9bslsI3hBkpVktWYVe1MZQy5+m4WRbTc8DRfu/VyAqF7vYvUam1apAbvAk4m1yrl2HFz2Yqjrizwicg== X-YMail-OSG: WcOb_54VM1lDPfEfTHWorGO_FkFIM6iF8.01rEQjkijsa9zMpnmeAKGTfLDcR_m Xad8dx8mZRj3c_5nsUp1oxld7Dn6sNawyfICNFcGXfwc0e4vp5FaUB6LTsD4xXE1zQlS8QAqRPIJ 7eJ4RpWC64fOR7jeeEoUf3WqgzHuvhCYJ5JTRfusVyamjMyQIVdi.UxN2BPuNKrsEJq8Cbq5cRm9 t27YzOlKQW.5AasRhbuixeiZdmoHcLlXCK4w5qU0fXn46f5CMoD.hPd1PrrbS7mM2XetiwSX0x1Q fMzCjXOmwsGg6DaYOuqBjcFFe_Ho4egwDbnFbejVwXBhBNIpeSbwLoDvGv.MkzzUzeDuQKdpFFOh bmgRm_W0itmxTOPRBmDF0H5l49VnBLjbzxaUrX5zoqO7hElPKZFpEKsO9sfwOAjhnAlUW198._1R jp5oeov2zFnyB2NjrQJBmT9vDGTQth2bK.k343xMEBpDhH1pBti3O2mTN1GHdsBglmhqF4sNe6Cd qqiA2DrzTjKparKi.tqDlN2Y9yuX_YHoD_wnd4naowNkv_IvIQf.p4ki_AAr6LSY3pT6Cgtgu7an i7ZTxyBEa.hunObImW3NOJkljdjg.YRFOrGwNLO4XpbcrMXdkdlaJg1l6KnFPnFJzoB7fAwhyRUQ zzoMxUJ8Y4ZjpAU1xU1xN4MuhjWfpD7Y3_RsLRtbhdVSaDam51JZyVGJPka1kfVh39IvvYQnvsZY lXFsJD_Zy3hOXEdTpmeo2v5HbK7CUt7Vtp76o5fmxBolW4aUKUqLeO9n0MQUrGkWkiGTy1PbK_QS RktystMQftHzyZoM0l_J2_BhpMKwRxn1ZS_n511IN0lGT3HBjsFxUhXyAvedvFOx3QWp_BpeUH4x 22Y7gDyDoTibpPi2_5O0t1qf.H_GURZL3U3l.tSlu_MErxP9.0EZFjFpBeVZ6T6V_xt8KXVGofCk NpdAECjTzRlpxM1qRs8Zqb.dvgbNUpNDLaNEmft7jOK9o6zJ.n1OZYZTNkC9VyPRxWeOo.vx5hyt KHhkEVVyF6mhMWqHoqbvvPEKnXBMqcHZ5.VHaxw77p3YYzevD2vBzSrvFeJdMMuAzTWw2PuUIeaP IsGXyrJTzmKF5N7325YOYBllfRCWLQg12SnQ.9jOAJYElWDKx4cfY9G94r5kfjyUa4BJfdKL7YJe EiN2gafXHzFdIRBTFvvgLVW0QoIxHWB2LEevcH4OMgNvK.viJn74RGYu677fRwoFIEjxL7qQyy3D sErsRct4pdzzn6Tsh8SS5OKK31u4SOPGusCR4esqzntEpjirxqz3hTkQ.5YydSI147oXVsVyVPKD cDYf1KCdYSBX6v6D5MvOApnwgdHGg3iUAZFc1b5Apw_fa6Q93zwDflT9MpyIOeRJ31eSfUvBPoCd VQP5mR8JrjcWp5sC9Z_vgP3yTZkrAChe6tPdYp1rKEiBuCD_4FfjqBqcf6qACh44MVFw0_OmdtNY gEPj8XXen9P0Oh90ZuA5le4hoyEdMoaDJwctuSSj69Wt91UihtfS45KO69mIHfa7hfy7v07xlKQK e5NFxvATVwas64M6tDzaLDky09obZligSd9RW9YlgZrvQFninPozGUIgl3c3L2rYF0trDQSztBcJ cKApfKtNYXRzouwMvz1Dgy2WtUP5rYh9OnP9MxnK5oTT6hVbyXXtT4_LiUqf5J5EAt7Xp3nKnyE7 DsVxVy0xpr2ERN9Z82vjDiel6zkod5b83x3YgCWN_kxUWXkMQn6nvx.0oHxLz4_O4Puc7slyN2df aj6vsmTvoGazkOh0XMXDxH9UVcDW.Nn7abSwMfGjpANCnrG9K.ovXDv1mCgYHtNokkIvIn1FXm1A eZYvNDFDfjDTQDPEW76cYz2.Wqfw6bqgqaE898fCsxyZUV_L_IE9luRywCkhPkkEYroaoIMfvIfo 1RrOvUahLImJ7.dcCWfy4nk_aqOUabkpH_vlfv.9HXP_x6KIuC2SAeAe0NvaTf2jJu6yy5QwVRbr EU9CZ6yB0yasX4174GJKXiqhYK2anDhdrbCG0aEdti7x2TNwZx9bKU2yYJ.k1Sa5E238oklLXeKs tZnc.sY81R8GMZrvwtGGWo.POyMnMi9uCVcVezZLlxIRlExjyrSjOAH_aPc0TC.zoBc4wDxG13GE ua2K5EjgKWS_gGqkimFWsI5oZyCU_v9ql.D8CnIkux.wVROiqzA4Mofj5yiZ_F0s8fRHY5TMj0wX iFwV_2MRiJRldYGUkDlv0gug9nF.zvby8iJbeWL2qt84gDyp1rwEj4FE0vqnZWmY7WYOEbk8rWjg P X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Jul 2022 18:19:10 +0000 Received: by hermes--production-gq1-56bb98dbc7-b6h6x (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3c61db86134d61df00c898ec645431f2; Sat, 16 Jul 2022 18:19:07 +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: Workaround for a FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220715-831c6b8edda-251792.img (and more) USB3 boot failure on 8 GiByte RPi4B Rev 1.4, B0T SOC [inaccurate timeouts] From: Mark Millard In-Reply-To: <3FBCB064-127B-46BD-B5EB-A628DCD66B2D@yahoo.com> Date: Sat, 16 Jul 2022 11:19:06 -0700 Cc: "manu@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3FBCB064-127B-46BD-B5EB-A628DCD66B2D@yahoo.com> To: freebsd-arm X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Llc1r60Fkz3wtv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="J06NGJ2/"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.36 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; NEURAL_HAM_MEDIUM(-0.87)[-0.871]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_EQ_ADDR_SOME(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.65.30:from]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N [Less invasive workaround and an explanation of what may be going onto mess up (some?) timeouts from be as long as intended, in this case one for USB3 activity.] On 2022-Jul-15, at 23:14, Mark Millard wrote: > I've reported the following boot problem to the lists > before but for older stable/13 and releng/13.1 versions. > I thought it had been fixed but it turns out something > else I had done hid the problem. >=20 > Both before and now, it turns out to fail or not based > on using the original config.txt vs. using one with > at least one specific line added that for some reason > avoids the problem. (I'm not blaming RPi* firmware.) >=20 > The failure looks like: >=20 > . . . > Release APs...done > 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 2 reset failed, error=3DUSB_ERR_TIMEOUT > uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 2 > 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 > Both types of USB3 SSD boot media that I use get the problem. > One type I've used for many years and another for over > a year. Both USB3 ports lead to failure. >=20 > Similarly, more than one U-Boot version makes no difference > to the observed failure. >=20 > The workaround I've found is as shown below: >=20 > root@generic:~ # diff -u /boot/msdos/config.txt.orig = /boot/msdos/config.txt > --- /boot/msdos/config.txt.orig 2022-07-15 02:43:02.000000000 +0000 > +++ /boot/msdos/config.txt 2022-07-15 04:39:30.000000000 +0000 > @@ -9,3 +9,8 @@ > [pi4] > hdmi_safe=3D1 > armstub=3Darmstub8-gic.bin > +# > +# Local addition that avoids USB3 SSD boot failures that look like: > +# uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT > +# uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling = port ? > +force_turbo=3D1 Following the implications in: = https://forums.raspberrypi.com/viewtopic.php?f=3D29&t=3D6201&start=3D425#p= 180099 QUOTE . . . is done early in boot, before the cpufreq driver is loaded, and so measures the stock (700MHz) frequency. Now this is value is used = elsewhere in linux when calibrating delays. E.g. the sdcard driver might call udelay(1) and expect to get a delay of at least one microsecond. However if the ARM is now at 1GHz, it will only get a 0.7 microseconds, which could cause a problem. To help investigate this, I've add a config.txt parameter, = initial_turbo, which means turbo will be enabled from boot for this many seconds (up to 60), or until cpufreq driver sets a frequency. END QUOTE I've switched to trying: # diff -u /boot/msdos/config.txt.orig /boot/msdos/config.txt --- /boot/msdos/config.txt.orig 2022-07-15 02:43:02.000000000 +0000 +++ /boot/msdos/config.txt 2022-07-15 05:10:06.000000000 +0000 @@ -9,3 +9,8 @@ [pi4] hdmi_safe=3D1 armstub=3Darmstub8-gic.bin +# +# Local addition that avoids USB3 SSD boot failures that look like: +# uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT +# uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling = port ? +initial_turbo=3D60 and this was enough to avoid the problems. (I've not tried to find a near minimum for initial_turbo, I just used the maximum.) It looks like stable/13 and releng/13.1 are sensitive to scaling time based on early clock rates that later change to faster rates, making timeouts happen in the wrong time frame. I've not seen evidence of this for main [so: 14]. Or that is my guess at this point, not having driectly verified a time scale difference at the involved code.. I've no clue if it is better for FreeBSD to add-in initial_turbo=3D60 to its contig.txt vs. doing something to avoid the sensitivity to initial and later varying clock rates. Covering releng/13.1 without an EN (or whatever it is called) would happen via initial_turbo=3D60 use in the port's config.txt . I do not know if main [so: 14] has different timeout handling that might explain why I've not found the problem in that context. > I do not claim that is the only possibily, just that it > has sufficient in my context. Turned out initial_turbo=3D60 was another workaround. > As my normal configuration uses "force_turbo=3D1", I would only > have ever noticed the issue if I'd tried to boot before making > the config.txt changes I normally have in place. Thus, the > issue might have been around for a notable time without my > noticing. >=20 >=20 > I've tried my U-Boot based main [so: 14] boot media without > the "force_turbo=3D1". It booted just fine. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com