From nobody Sat Jun 17 22:08:00 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 4Qk9C65VFGz4f0Cq for ; Sat, 17 Jun 2023 22:08:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4Qk9C53sLBz4C8l for ; Sat, 17 Jun 2023 22:08:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KImQ8ig7; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 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=1687039694; bh=4H6JjxWuZCGZNHauyEnxWQEThRUnPjsqmo35s3tuxN8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KImQ8ig7eMgb2U8n5OxyWpBHYGN8AvTOL6C2186iwX6s+D3U8WLB2Xat9Q7jvHvJ2hlurjUrE9FvYsR7lW5Gc/cP0TMLVFoDsiqeP5fxEh5YYFBAhX08pXqznY5E23sCTmeoRKFBKPqlbN6rUP4nWO3PFC6VbEgpDpsxtd0UxLdwetH9aywRjySBvl4r5SA2FpGYFAAC0zNCP13xb+0wsQi1yyuVAp6KW9qW3dOHPRAHfBk8xOVNEY2NIZf9Iv/ctUVf+4ttn3VA8NVzohM1wlLBRDGPwASjHlw5E+XA+sWP+zBOTbZZgrlPOh8ZhTXZUNc1cl+RvEWbdKNscXPhIQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687039694; bh=grEcOmRg/yjOR2WvrwlVEM8PYz7QHxtHRTeKu6nQ8b3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qWC7OBQ8XlJB+4jst8KWKWFNWotRiHDvAeaea/jLHtMck9o1ZeKb9lOBqbczBdDYp9Usd3tHPE54ZWk+YxBmzfprKCQ0UmVSOtBdC5hHyQXvHr+jdlewhoCS+9IAxITanaQsdEFRq1ViYRK4PKGRr7kTrt9cXN1zZNdHmT+SZ1hIMaQOmr7g0biMlbLZhHRGfBuY1TSXRYVqFnwfmAYDBDR5mVEiZK58MtA1yeRs8eFVVmcm83oZEERNeNa9hQjmhZmX+ifddSm4S9lvliH04hOU5wfEnCiPTUoc4Y9VenALn1S7yWJrEDJev3o+15dvxyZqPfYpoH7SzMbFk2v0Gw== X-YMail-OSG: w_lDSlAVM1laSYdaqPJ0yKjwNXnUKsfSe2fsFiG0MlrX.SFy.57M.T7DzuZ8qjo sU0ELzQgas9W9QX_UI9ieenw0_TdOu5tu7KuEMyhBf7bLe85QX671agJ1mVzSOUNm7UmrTjv1P7I Z16l6hGsT0Z0RlXj5ZaZd..gtvrLd4fI._fhg6zW6LrwlCiRI7.0YJXHDHBnv8U3z5rYftwW2rWC P4.m86DfId62xQ5c_dMDZ9ZVse4It1TQp86x1pCJWpfUnc6ExMY9yeiSF0KigIV0qhycrJcjJdJ4 6ZxYvkauHWAxRbAA.8PvNYrawf8G2PtnQlECFixm6X.yM7KN1n9veVcpm72lONpzllwKXTcxNABv 7oYvXYdwgrjXGOWiqmuE02QukCH_bop9qAIkUk1vyc8N0kcF8b1Gw2sWrK0S.cHo__puarKJv6mc ZljzWh.Zx_jY1CMfajgFUPhoQNjMQl7XgKlbY1ZWpu7WxML0C7CtlR1_k.i4azlzA39pBkgfSHnY KW8jsRi.JXgy2.A0f9JzV4WRHjy.rhELqzzujbqsEcAtHAp39iX7pdgrqrXFTIxkebpG8gOvHS.L ULgKZxlfbyTtKz72wTRvD3WqJVNU0SHpA5RYDaEQd.eQyAZd5UZvOqDOL29a.TuRVURdtb_QwxVM MOcGIiged60i5iDyTYmH7L5VRoQkY0H2XjOXz4jvU5KeXN2fvzIKEgqqXFYmfHtMmfE5_hB6ROvI 4MSwdQL1I_94thEGr2ZCq_DsVYEAWRcqTfDed0sh.f8JCDljolvuZFB1qLGNGbZLCxGp7vJY4oo5 0_qCCnehJCz4UwBxGVzouhaoYg2M_JKLJqK2syXVl6o8l8jsSsnkYChfdufHT5u7wXDuJztW6Uc2 QwtFXd9F3EgcqrBGNShwzj0kn7vBehXf2Oc.lx4.a9puGD5vzT0Up0fuMljABjph6jkRJAJALG9e x1AkwjWHxfNGFibKkTvJKIouwAOXzNnVNadxC.6bX4e2Grlrm7XFs902FWTg5pl341HM7E.hmWAp XIGPoFlba19.hjG5aDKNY23F5fjbkyUYpEocTSSwtxaIhQAUjrzH_vdOkSLasjkrGQuG31UmDiQO C2eJNZK8hBDLm8bzUmV_gX7x4YXBTBMNdpCqr5Qj_YjGyoakHh5ohT6Ww6Sbu3KTB2YMcNHppM6U p1drQL4Cek3lece1cnqRvWMIUfw4WzuIDLbzvO_0WYhnnSAkSQ_1x.Ox72fCkjy9HR27vzO7JriJ Xu6QEoglUUKPi7YsUT.WhiG9wGe_qwvkFvD24GQRboZ_qyzVmw.u6hu5Lb0ahHhGYsKO8NU25XmR 5_sLTZk6Re7pk11tgzYRLVBrqxSnT7PZPlC326_6mYOQf9SzT0hnxj0o5WLL8_fIhMcKHS.GS7Yj KBpXFvJzYcxEYTmnEHjltLKt40S6_.3aOK7ZdS_ViMw0NWbNd8k_L6NxVMvUewA1odHFd5eR1bzN VgVGwsMrUB0m12qT.8ji5iaJ5rXgUhhsHuNLeYtvNMRejUD1PFbWumDbnKjEXK0UjpVpRB2kgSr0 ieAjuMvaEe5cQYVBF_oCjtJ6SuD8FIl0.v1juSC5QBpDfFInynOoGwpRco3m1tFd8ZW_xwK8uxQQ yN8ZTb9FOm9Xwe3qMZ.uzhhsaIyE89dH1USrKmzojbDESusOOrSUyaWDJbhZtnbAArI26Ez3r5KJ v_R6HblkvLOx_a_yPT7X08XEauNhLB0p8hajRGNW2gu8j2v9s.UTR.ggwdVIJAcBX63fcQXpbBZp KTWWs5bjpnL1bNArq.bXwcbcGBobGOvZ7XMpNcQ3ibbZ6uy1cWMvHjw7XGiYD5mVcsDkm7MkDF5W YdhPEF2MrK333M4xZK2LyITsY6o.RBXA082cmQwHLIQfqOHhmywW.wDnMcd2p_MT9IjmcTOXHNAm PM1k_ouMqfDWpGHoKT6CUjRyyQw05QiL_6KtHG7TSBGryIeGZ_f3bKE_5DNYfrHzlsAB3POvKbhc AkxCqPsnGN32LDSIPjnk41MUzevjotOM63AXlOdI3bGW5lVL.sdkrdzKGSLaQ8cj53tq5RhZ.cW1 00zO2Vpi2cNOjS_YRj8Fwm1oJ6IsWVpVzlNzh_P47K7.7ShZTCpC.eup8fFbFEc_.70.UlB.i8xg jekMT8P8z8KJ139FMNQMXZjo0kYDMiFUU1ipvpMik0E9CnwDGuoakSSq..Z.aQOurZIKHczeauxZ zejZriP3Oy0hDSbJiPL4yIVt8zRr2nTU91qMQvFnjLj_Qu5UH8yQqGFmhLV3A1a_f9YWliL7GGoG tePO7MJrg X-Sonic-MF: X-Sonic-ID: 5b029f68-baaa-4b59-afd2-53b0913e629d Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 17 Jun 2023 22:08:14 +0000 Received: by hermes--production-gq1-6db989bfb-66nkp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 15322c6b0c86f3aa42ff44fd80f1b253; Sat, 17 Jun 2023 22:08:11 +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: <5875BDD2-B792-4FE1-8F42-99D996CAE71D@yahoo.com> Date: Sat, 17 Jun 2023 15:08:00 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <99542360-6350-4636-A9EA-CA9BBCC93C60@yahoo.com> <5D8D94E2-781D-4945-B721-EDD0BF56A8F2@yahoo.com> <70CC43FC-2055-409E-A94E-76F934C14AE2@yahoo.com> <5875BDD2-B792-4FE1-8F42-99D996CAE71D@yahoo.com> To: Nuno Teixeira X-Mailer: Apple Mail (2.3731.600.7) X-Spamd-Result: default: False [-2.32 / 15.00]; NEURAL_HAM_LONG(-0.99)[-0.990]; NEURAL_HAM_MEDIUM(-0.86)[-0.863]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.03)[0.030]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; BLOCKLISTDE_FAIL(0.00)[98.137.65.147:server fail]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; 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.65.147:from] X-Rspamd-Queue-Id: 4Qk9C53sLBz4C8l X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N [Commenting out beastie_disable=3D"YES" and loader_color=3D"NO" in stable/13.] On Jun 17, 2023, at 14:42, Mark Millard wrote: > [This time I add continuing the sequence to test the stable/13 = snapshot.] >=20 > On Jun 17, 2023, at 13:56, Mark Millard wrote: >=20 >> 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.) >=20 > This is based on: >=20 > 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 >=20 > First dealing with the U-Boot vintage-avoidance issue: >=20 > # mount -onoatime -tmsdosfs /dev/da1s1 /media > # mount -onoatime -tmsdosfs /dev/da0s1 /mnt >=20 > # 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 >=20 > # cp -aRx /media/u-boot.bin /mnt/ >=20 > Then dealing with the initial_turbo issue: >=20 > # 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/ >=20 > Finally, checking things overall in the msdosfs: >=20 > # diff -rq /media/ /mnt/ > Files /media/EFI/BOOT/bootaa64.efi and /mnt/EFI/BOOT/bootaa64.efi = differ >=20 > # 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 >=20 > So: No other differences than the vintage of the FreeBSD UEFI > loader. >=20 > 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. >=20 > FYI: >=20 > # uname -apKU > FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE = stable/13-n255597-894492f5bf4e GENERIC arm64 aarch64 1302505 1302505 >=20 > 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. >=20 >=20 > Notes: >=20 > I doubt that the RPi4B EEPROM image vintage would contribute, but > it is something we have not been explicit about. >=20 > 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: >=20 > 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 >=20 > 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.) >=20 > 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. >=20 >=20 > A you sure you have the HDMI plugged into the correct HDMI > port on the RPi4B, the one closest to the USB3 power > connection? [I have also changed the /bin/csh defaults to /bin/sh (which is my normal context).] # 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" # shutdown -r now And the beastie shows up and works just fine, operated from the USB RPi keyboard. My bias here is to have minimal differences from the RELEASE and snapshot builds relative to the reported problem. I still see no evidence of any problem with use of the RPi keyboard to control booting. =3D=3D=3D Mark Millard marklmi at yahoo.com