From nobody Sat Jun 17 21:42:58 2023 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 4Qk8f92B0Kz4dx8J for ; Sat, 17 Jun 2023 21:43:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4Qk8f828xHz47qr for ; Sat, 17 Jun 2023 21:43:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=IEeU9MSD; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687038190; bh=A5ELK1V42QkDgZv69r6+96ogN8O4Hzib6lDWvijc7ow=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IEeU9MSD/dckyCDd2i75OoHaeDrNj9b886G5SS+f4ylNuqHajvw3E0CJxynGEt1zakNkzDNYZ6XV69oU97PH2uyv60rAJNfcLdL248JQvii6w0HPFyMJrIoKQhxCpNxwOHkxPswA/Sk+JZAmteyp1ZeotDd3rDOwk5vBjl9396qBAjJ2oZFHAVw9E2FVDgp9dl4rotPtFWWvC6mUJiI6tSTh7fhGceQG7hKAT1dTs/z4GEkA2hoqHWn3ZZEVStbBokFlQSStvzR2BAzCAFkHdaxpXbGIgrHwMuVi4lhvm70KymF5Ss42l11fM/GDk9xJazqiEeHkM5IAUElhwcCi2A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687038190; bh=WDpjOVM02vxLSHzWwgWBuxWbbmqONGL4dyv0xQAI2eP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=g03Ty35AK6oRyqgfbaZ0SNZ3ykUB0o3FDYHdD4dlzvC1hUrs+70zl59zzH1uwV4mQ3VnXOwyKeIeBaOrReBNitDtHdn4z/IU/SlyH+MrQTK4Y5lCXr7X3lroPT2/Awae4prCKN1NuAxPq9keIhQKdbq7TZWSJq0LLfEfpHawzjBEs81Fl/VMbsbRBKW63zO1jfYhPGJ7OjOgRl3q9+LsySgNpnUiyYGITCJlXvmQMHfu+Lyid9+4YxhXJOHsnaJLLTDIhz0z6hKKexWqv530YAsVKSQ/ZdGzra3cY7NVHc+MCWdXW5w/2zRIHWUaazo2B7FTzcx5v9fMZdIxtdQ6Iw== X-YMail-OSG: ZTyUHocVM1kfL7wHsmtYlxYTTmOX9hXhJ1DSA2IgV2jaM4bRUAiJhIRbGS1i3f2 Tn3XaiRS2VqWgXLdSpvedFFv8zGoGJJ0em2yQBeEbT7gBe5nVvNl3EcDKl_d.phiDjROHXflbIkr TgVs3kwSL6N_p75bcRVLcwOKbL87yq3jQSSgPNk87_LvPXYCQAGcq65PYvIfGBHw56dJTQGzUFTa KK.1wTaerMkcPvTqJa.nieXpD_WwTZ_pVcnwxCZNy4uDhqfiIIi1voikU3skH4NLytfTmmiTAurx i5dTO9RCpeRw2aFnQI.LLgk2pOp7H9_R5XxKtliKnBImh1Lu2o9IlV3m2wTkLOAD.pZ6HaIqvMuY _13G5sGKWz6i7xx_bJ4_4BvohVhHRNDEJtDunYn6xq9zyFo35KjTkKjv_2mecJB0eX8IwNCA85lw .kazF9ZA36sXYV14Ju.C4QPKZtUcyqDKVCXhXILIPmsRWh8JoL516QoGgoeeo88h_9K7S868T0Tg ibnDe2FaBNhh0olsofQ5s6Wld2axx1wGQo_xLQM6jEPCl1lbF_fcwIcNF.XrPzAWXVRfO6SjjxHV g5vyGrGpgQ33IpwTYtSF7568k7bWRmI8BaIqSsxp9wo9FFUGV7Hhm0dZ_Evk6k6c1vZGOw24_QD7 ASg7h.zA2boJKSNVq9jqOEiYtbdVi5mAXoU1xb7kNKEWD8m129AjSUz2J04Li3I5wRu0LYCVaZ1L Y9KmrpntPPxGSN.4qg.XyzmNvz_yDm77NU7t_aNDFoJnXLUK1PLDAuciGziB0Tpca1EL4JZSyF.a nDWAiEE4x9IiFuEx09BomK5m.2Cpna9rXQmPe3nDMNnOVVxYdaICuG7IFW_eUFtHUIZle1Szrz5v 3RS17CmsazndbvRlJnudO2WMffHJv0UZtgdwKy4oiX8z6WYVvVhhIvkYKX1tkRz2Czn7wD9Gy8hk Z76oOPG9PebkFuilYXy0liigKYy0P2WpSooiIcZOnLm2Ye2QRmZxrqOls_TLKwP_DRwzw_0boDtu AK0a2LNLUeSmU_l_OXVtc5j0sDhf3RRBT440Uiwy_QIx679ozYOocOE9tCRMLtFaBmiIc6_pvEVg Es9hzst0.5EqF4N6x8muWlMDaT5deeKrhj8Lnqd_EvI.fwzf6f6COWHi3WZXTvqRzXHTego3uiX6 LYnWgCyLvDm43o2pK3WQEzDJEGsfpApg_iUVXphacnD8VNrsI4H_I7sJuSmM2mx3BVUvxniEHjy0 ZAANwtPhVr5oM294eQ9tiR6fVAxVFLeI023FS8Rd_Y65xqhlG38LVJa5fhDLLNgICmjI_bxByu9x mDcOFvbdxOUL35qwDuNrxWEoOSH1E4GXCS4UIhu2bkTCZ5XzW1kiEhbUS4RY8K5K48ZPCxwvsvOS rEJ.p2tVHdAfP6TM6kle4IXc6oiPysaMg72Zzp1JoUumy8bJC7QGjVkUMZrWrbV55YuS1VGgxyrW r9Urmj1vDykqc0iTGB6Hy_HWSz.ytFmrfF83i1WyDNf2YXHxpnDp9VNxghpb0cYHcom687.9Lejh SyhznrS26ay.iGmtsxJlOVmtUswrbIDD1i4CoMSfC.9B.pOHHYTKQRELGzfvtoSRZAXvOR4Smkfs eZuPg0eJo_uUemEh6Kerq4i3Rj6tPRrTjbAGRUlaDhxXAIlnA2LkFTyXBaBXgzZYEOMWKGeNGMIV JTccMHat.GEOFGdp6d72WbfA1ehjKJu_u_gi.Xa.9y8Nb53EgbZ359jFogqXe20SdeetJ0IpXGFA MCw9Am0tVK4dtCQHOsHqb31RofaGHojC4Zstafy.PY8fBLip2PaXxXAD4_7Sa6CHaSVjYK23tcXC 2V4sumSgn31HldeWHkilvTOFYMHD4WYX4Gx3sSedLFk98I0sYMYRSgJhLvz20WlMiHudxlYwUKFD JPtd0cRhtFzItmWozOXpAsIyxc1mN2Y0X8Js8BsZywZeet4k.J8pOScXMIY5GyJPBP1kNv5QzYUB 6HNZPhXY3qvl1Ms2uyjl_eK1ijlwkI185wu6fFXg__qFUOmBgsw._Dz5bBhgqNKEfI1nAEQ9ELGe QHMxMD.c2RosxTfEmBWb6ErynR0ONF1uvrxOcYV7um0N9ZPZS7Ol1.oh6n3n0ZgD4wH7ZLssn2ld 8FIccBa7C4v3Q_.aGG3wFlZTE.nPkWbFnrVDhUji.rCW5_dMM4If7LgijZcaqQ174dpEjTXz.eT0 5fj9QnIKnzQgdHZ_DYOoLiuYnBESKyO.HnweUei4w6LOEKLqJeTtPBQbMEddegNtv5ObtN5c5kXW CFyYDNg-- X-Sonic-MF: X-Sonic-ID: 3ba233b9-dc17-4bf0-8bcb-cfe960f14f22 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 17 Jun 2023 21:43:10 +0000 Received: by hermes--production-gq1-6db989bfb-4sk72 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID fa5577366213321f97ef90b81990b36c; Sat, 17 Jun 2023 21:43:09 +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 16.0 \(3731.600.7\)) Subject: Re: keyboard doesn't work at Boot Menu From: Mark Millard In-Reply-To: <70CC43FC-2055-409E-A94E-76F934C14AE2@yahoo.com> Date: Sat, 17 Jun 2023 14:42:58 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5875BDD2-B792-4FE1-8F42-99D996CAE71D@yahoo.com> References: <99542360-6350-4636-A9EA-CA9BBCC93C60@yahoo.com> <5D8D94E2-781D-4945-B721-EDD0BF56A8F2@yahoo.com> <70CC43FC-2055-409E-A94E-76F934C14AE2@yahoo.com> To: Nuno Teixeira X-Mailer: Apple Mail (2.3731.600.7) X-Spamd-Result: default: False [-2.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.93)[-0.927]; 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]; NEURAL_SPAM_SHORT(0.12)[0.123]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from] X-Rspamd-Queue-Id: 4Qk8f828xHz47qr X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N [This time I add continuing the sequence to test the stable/13 = snapshot.] On Jun 17, 2023, at 13:56, Mark Millard wrote: > On Jun 17, 2023, at 13:53, Mark Millard wrote: >=20 >> I'm just making a status report for my experiments. >>=20 >> I did a: >>=20 >> dd if=3DFreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da1 = bs=3D1m conv=3Dfsync,sync status=3Dprogress >>=20 >> I made no adjustments. >>=20 >> I then tried using the USB3 media to start a boot of >> a 8 GiByte RPi4B. It took my typing to the RPi >> keyboard just fine: I did not have to wait for >> the timeout when I hit . The (official) RPi >> keyboard was plugged into a USB2 port. >>=20 >> Unfortunately there is a known issue for my context where it >> gets: >>=20 >> 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 >> So booting all the way requires me to make an adjustment >> in the config.txt by adding at the end something like: >>=20 >>=20 >> [all] >> # >> # 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 >>=20 >> [It appears that with modern EEPROM context, the RPi* is >> dynamically adjusting the frequency/voltage combinations >> even during early booting. The initial_turbo use delays >> that for the indicated number of seconds (up to 60 sec). >> FreeBSD seems to not handle the variability and the above >> gives FreeBSD a stable context for such properties for >> early booting.] >>=20 >> I conclude that there is nothing about use of the RPi >> keyboard that stops it from working during early booting >> of 13.2-RELEASE. The RPi* firmware, U-Boot, and FreeBSD >> UEFI loader all work, other than possibly needing a >> initial_turbo addition (or analogous that would span >> at least that early boot time frame). >>=20 >> If you had/have problems for the 13.2-RELEASE context, >> they are likely somehow specific to your context in some >> respect that deviates from the above. >>=20 >> In some respects, investigating in the older context may >> be better than dealing with stable/13 . It may be keyboard >> specific in some way if the keyboard is not an RPi >> keyboard. I did not have a mouse plugged in. An Ethernet >> cable was plugged in for the booting. >=20 > I forgot to mention having the HDMI connection plugged > into the HDMI port nearest the USB3 power connector. >=20 > As I remember, the other port stops updating its display > at some point during the boot. >=20 >> I just retried with the RPi keyboard plugged into a USB3 >> port instead. It worked the same. (The boot media is also >> plugged into a USB3 port and is USB3 capable SSD media.) >>=20 >> FYI: >>=20 >> # more /boot/msdos/config.txt=20 >> [all] >> arm_64bit=3D1 >> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don >> dtoverlay=3Dmmc >> dtoverlay=3Ddisable-bt >> device_tree_address=3D0x4000 >> kernel=3Du-boot.bin >>=20 >> [pi4] >> hdmi_safe=3D1 >> armstub=3Darmstub8-gic.bin >>=20 >> [all] >> # >> # 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 >>=20 >> # more /boot/loader.conf >> # Configure USB OTG; see usb_template(4). >> hw.usb.template=3D3 >> umodem_load=3D"YES" >> # Multiple console (serial+efi gop) enabled. >> boot_multicons=3D"YES" >> boot_serial=3D"YES" >> # Disable the beastie menu and color >> beastie_disable=3D"YES" >> loader_color=3D"NO" >>=20 >> (That is unchanged from the image's /boot/loader.conf content.) >>=20 >>=20 >> I'll see about stable/13's snapshot with the u-boot.bin >> substitution. >>=20 >>=20 >> Side note: I've other USB3 boot media for which having >> usb_pgood_delay=3D2000 in U-Boot is sufficient but default >> U-Boot contexts do not find the media suring the USB scan. >> (There could be a better setting to use for all I know: >> sufficient but possibly not necessary.) This is based on: dd = if=3DFreeBSD-13.2-STABLE-arm64-aarch64-RPI-20230615-894492f5bf4e-255597.im= g of=3D/dev/da0 bs=3D1m conv=3Dfsync,sync status=3Dprogress First dealing with the U-Boot vintage-avoidance issue: # mount -onoatime -tmsdosfs /dev/da1s1 /media # mount -onoatime -tmsdosfs /dev/da0s1 /mnt # ls -Tld /media/u-boot.bin /mnt/u-boot.bin -rwxr-xr-x 1 root wheel 601096 Apr 6 19:47:52 2023 /media/u-boot.bin -rwxr-xr-x 1 root wheel 602552 Jun 14 19:43:46 2023 /mnt/u-boot.bin # cp -aRx /media/u-boot.bin /mnt/ Then dealing with the initial_turbo issue: # diff /media/config.txt /mnt/config.txt=20 12,18d11 < < [all] < # < # 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 # cp -aRx /media/config.txt /mnt/ Finally, checking things overall in the msdosfs: # diff -rq /media/ /mnt/ Files /media/EFI/BOOT/bootaa64.efi and /mnt/EFI/BOOT/bootaa64.efi differ # ls -Tld /media/EFI/*/* /mnt/EFI/*/* -rwxr-xr-x 1 root wheel 1180860 Apr 6 20:48:14 2023 = /media/EFI/BOOT/bootaa64.efi -rwxr-xr-x 1 root wheel 1182604 Jun 14 20:47:12 2023 = /mnt/EFI/BOOT/bootaa64.efi So: No other differences than the vintage of the FreeBSD UEFI loader. This also booted just fine, taking my input to avoid having to wait for the timeout. The only difference is which USB3 SSD was plugged in (the boot drive), in this case the one with a stable/13 snapshot instead of a releng/13.2 snapshot. The rest of the ports were as they had been. FYI: # uname -apKU FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE = stable/13-n255597-894492f5bf4e GENERIC arm64 aarch64 1302505 1302505 Having confirmed this much for both releng/13.2 and stable.13 , I'll go back and look at your notes about file content and the like and see if I notice any distinctions vs. the above that might be important. Notes: I doubt that the RPi4B EEPROM image vintage would contribute, but it is something we have not been explicit about. I do have various debug outputs enabled, including for the EEPROM stage. The following is what it reports=20 about the EEPROM content ("BOOTLOADER release") at power down after FreeBSD is done: RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: 17:40:52 BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=3D1673458852 serial = c740af3c boardrev d03115 stc 421180 Halt: wake: 1 power_off: 0 The "boardrev d03115" indicates a "C0T" Rev1.5 vintage part that does not require the bounce buffer work around since the wrapper logic is fixed. (FreeBSD keeps working as if the bounce buffer was required: it is the only style of operation the kernel code has for the category of part.) I have access to a 8 GiByte Rev 1.4 RPi4B and a Rev 1.1 4 GiByte RPi4B and could test those with the same media and such. All would have the same "BOOTLOADER release" as above, as I remember. A you sure you have the HDMI plugged into the correct HDMI port on the RPi4B, the one closest to the USB3 power connection? =3D=3D=3D Mark Millard marklmi at yahoo.com