From nobody Sat Jun 17 22:41:31 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 4Qk9xl66Ylz4fGsf for ; Sat, 17 Jun 2023 22:41:47 +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 4Qk9xl4Vsjz4L2D for ; Sat, 17 Jun 2023 22:41:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687041706; bh=E2/drnzxcfEkNeXYRHd8Si1/cLetU56yL45K5S8j2Uo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Uyyu3V4eAxJMKmYa0Ax520YdibsSaoZlEv5iefmGmp1fCMtaoWh/nuJ1yDhdWWJReCm9ksM6Jctamy36o13RkPUjrD/yDM0TJvD0st7sY42nyVsF4PkhA4wFLBTRebNsBnA2URb/vS7HVNvQ/klOQAkRoDyP5968HjJi5zuyehzUfRjjs9R7ZZIWxWyiO2JT1YpIKt8/MVj4UwbtlT53B+D4Gbdu5R/+RKcR6XcJaPET0f5x5YsU3KTtrwzn6Kx5DPs9Jn5p8TPOJB5PffN5QluleYNPDNyuEFlKsDnuN6D6DXsd2AgATGQ2QIGzLG7JvV8tMmdCVSo3q8G0lczHSQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687041706; bh=AL1tlHOoOcRn/3JA0AF94JCubZ3BnISnPLKRHJQLcqO=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UekVDVSGSYVz3G6pWHktO5/AmQCHfRULOJ3WkCnxcPgHmjlFEJIZFoWpYHwdnVJZm60MKOALMU+SPYDLJrBV3n0sKyLio5ssMWuEYdShHimpoJYSHs8lDarle2zyKgX1KFkyLX/YtePqK+FpFYFk671LLQbxxo+YfO3Tw58y4GvdjGOvB5vPVFDpMCV0iNvrpORBLUaIhCf/rDuEv5ek4GC8l/sQ1ZjyK8MSspmGug4w0lbUg8FQAJmw0gbSYvZhr9j1NaWegbZHtYLS8SM/WF+qPgPom27+a3Xhf33VkUqSu8zfy+dTCmS67qmjKf5vny7O2ZN9voOiKQmKKudR2A== X-YMail-OSG: sddMOjQVM1nyNJ6gfBYwgLoh8j1FY7EAMcz_ILqyTm3dVMABdTXAGrzTT2Pc3E0 mfsMOweQddYhrATekh_FCGOqfFyLfyN5znq6Cmut_LKbhme2DvURKXMCg.D1rxMzbUfSWzjY9kHo qsfX7w4Iiq0LPu2EJC.Pg7hOw7XmgvjgHZ3jFqbbkWwUxGAosEQ9BOSnkNhpWJi_Vk7KJD25cXM1 wjWY2HefTJw0QOgcUtGHAw4AqcqKACZgxuUhuodiK9j42C5NrXJL3IqHJaMf8NHCsUzBVJZbaZ3M tAeC9sLggN9S8bZJpXs26zZ_CbDtTVpKVhSAgva2HHo_gQwGOqWZBPLr0hY.M761B.M.uAJ.KMdd r2Px3YtlpmKgxZOcjPYn8eKnyVevMTbonooMLnikKO6Vvp0reSObhKg4TmzEddsN869u0UXp3iIN L9MG_34.HxVUZ1DopqAyNpTpcJabPOJVzKClXGtWDTkdhr10fqiovhN6hb5LVCNrd_o3Usiqz9Ke LBDW1p_ogzHw25UdcIx12SmnW7xAeZEI0QZhRxK1FHVzeQvlaoIuRQV2d.A_qqr4yNQa7MWVOUJI uwfXq_I8nhMvOZfbws3m0Xl.zdZqEbanlR7Q3RtMKFTlqAlCwWchdMnpA7YDEGkG3shFiSJFlXUS KSVC26XA1yKLyoozMk5NrG1xE_CyHNQ_NCZ_va4D9iA18TdUlMQIPwnurwJKlK12fDtWlZCGB4QY .ODUgaaY2sMhDWhJI0Po1eh8ewIj2DO.ft1c32zZtfJhyjvMab25nt5t6scIs5MpGCFVKLS3KyOl bdNdOuy7UPgGdpzroeib7JkBH2kakrM95cKIUnpxHtHF64x5RBrkqfKYwjO.puLlYRcGu7O1p1dN Pob04c5bOMbWFA.0AIVjjPMs5C54TPma7wq4Es59C_CZ0lctuiqQJhGvj.sYpBR2z6V6KOFO.qq1 yI6iGtHHpvOeV0lf2KINwr6QDSXIm1jVlOe8RUoWE3on5EDyWyqifPCdLTBHeLy3fALoEJ4YFmGT Fxo92F2w54Mu3PCLvuRTOsi6ZQERWspGUxit_.G5tvKVhvLW.7t2jPjW72TJQN6OAl81JvIXh.dC LALkxtF_AqlR4AJsD_74Ilkqu71KGcrvpX6WkDT1GAuhNIzlLKzpHos8p7vnLJJ1UD.d5k_2SZOs Hk1PkPtXYV98iO3jd9xeinWeQIhIjJBIsxEztaAXpuVZVet7Eqgk0tl6IXlhknziC95IgxGSvBop l21AMrK.E4ifrjtfniZaktUTANl_Y2KQhJ3fVEpzFw4_UrfunQ_6m_maWnsq7FQRfP4R0DFx48um 3wkDXDKRewpgUvi3MF5dv7h0pT3XJRhI544IS6.bbbac_7gSc5q_W528yq7P.nuV8zVgJWlkb2T9 Ubf_zCjHd5UOLViWIkbjeatgtwan7UttTucqIggAkx72CE9oVK1Gcn8GU05jDi1MuZzfxfwSWdzz 8zcJqPgl8v4v.oIgSjSOYCP5zZnUeGhaJ1rIYykvhJ7ushDBUtPTuBH6yrTHxzRtoXtwxg8im8Hq eaqp98xHGEbAH4hQB8kvL7ZGz7QQ6jVkSZs1MEnJArlLG4NStw2cz_X85ekxdBg4wmH7Xpuw7cce 2HbDn0Z2j9em4VSmqD40zqMNWCYdDN64AG1r4evBS1iQLnjZ4VtJGnTp1HTWUfZAPd_IUrrVX13m m_6QO4GGjxeKO8noo6oAChWK9F9mxThKZKjHIUyRZQRx4bso6eJePN2zxkP01D_.IskR9R.gUuJ0 gquM.PZG5zSFHTAZnsxiHOswJ9.9QvsYNDCr.YwOfZuaJNW51iKU6nP3PIfF08D9JCzq7_AnmZdM Iz0dRyLgK9HmUgrIFYpwZfazCqS65uFU64b_LdhAB5ELkhwhKZXaq_FcDnU16U5aKxzQ2blSlygW eDCu5ja28ct4f0vSs9oR1OP0PqMsCJh7sZ5dDRVe9oFuD6FSEES5VAtujAcfFBrr0byAyUAx7w9p xsh5jkcSvGmIg5Hrt36UNn9uZyIlodYHBgHJAx7YUFTZC4SWCQvTMeEf2KQ1vIeH91pIYkd_xSsd bK8lzDBvJTzkUrehDNOwVi2FBZeAbdvEdbDgNRFj9TkJIj9eZCc7zG50FWoSM338tPU0NaDpqUvp VKpJBFw_8DVO96t88OTrNgaVs7xJP4xKiWKk.Nw6tbhALzRn6TH_vx1tjqD9gp0nxlsUIYuZTCpV w5KKlptG2IJ51r9lF1MJH4HYAmdGlkLJ1eEzdPpK8t_z2bFnW6DhwddfpYAsd2qE._pEk2u.pSi1 chIspVJA- X-Sonic-MF: X-Sonic-ID: 53589a30-fc9d-4673-8239-86fcafcc6e2f Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 17 Jun 2023 22:41:46 +0000 Received: by hermes--production-gq1-6db989bfb-66nkp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 62cb832d66150dc1240c328a470b2be0; Sat, 17 Jun 2023 22:41:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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: Date: Sat, 17 Jun 2023 15:41:31 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7D1BE218-B8B5-40EB-8CF3-C09CDEABA9C3@yahoo.com> 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-Rspamd-Queue-Id: 4Qk9xl4Vsjz4L2D X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jun 17, 2023, at 15:28, Nuno Teixeira wrote: > I think I found the cause! >=20 > Please take a look at photo. >=20 > "Scanning xhci_pci devices... Failed to get keyboard state..." That message was displayed by U-Boot before the FreeBSD UEFI loader was even loaded to memory. The FreeBSD UEFI loader operates by using U-Boot services. If U-Boot fails to set up the keyboard input, the same would be true in the FreeBSD UEFI loader (beastie or otherwise) until FreeBSD's kernel does its own bindings and things get another chance at working. (A similar point goes for storage media that U-Boot fails to set up.) Is the keyboard plugged into a USB2 port? USB3? Have you tried both ways? It does seem that the system and keyboard are not well matched. > After a while it gets detected during boot. I've pressed enter key and = I saw it creating empty line at boot. > Maybe it's a keyboard problem? I'm using a very cheap one (not = raspberry original) >=20 > Thanks=20 >=20 > Mark Millard escreveu no dia s=C3=A1bado, = 17/06/2023 =C3=A0(s) 23:08: > [Commenting out beastie_disable=3D"YES" and loader_color=3D"NO" > in stable/13.] >=20 > On Jun 17, 2023, at 14:42, Mark Millard wrote: >=20 > > [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? >=20 > [I have also changed the /bin/csh defaults to /bin/sh > (which is my normal context).] >=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 > # shutdown -r now >=20 > And the beastie shows up and works just fine, > operated from the USB RPi keyboard. >=20 >=20 > 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. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com