Date: Sat, 17 Jun 2023 13:53:16 -0700 From: Mark Millard <marklmi@yahoo.com> To: Nuno Teixeira <eduardo@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: keyboard doesn't work at Boot Menu Message-ID: <D29F33D9-DF25-4BD7-853D-50DED525C4FF@yahoo.com> In-Reply-To: <C3CF38DD-A4F9-430F-9FD4-8BA6E5FCB2EA@yahoo.com> References: <CAFDf7ULWff1YNA675-0ZdSgRM-t6RnCHO9RSTshPS0k8xfc6xw@mail.gmail.com> <99542360-6350-4636-A9EA-CA9BBCC93C60@yahoo.com> <CAFDf7U%2B3NR8ETaxg2W9j%2BXkm-sNaCdFSCXNMLA_GmxnRayeZuQ@mail.gmail.com> <5D8D94E2-781D-4945-B721-EDD0BF56A8F2@yahoo.com> <CAFDf7UKZmZZS6aKf=43-A_2eXDHq3%2BPcC3Hqbp1s7umrcJDA_g@mail.gmail.com> <C3CF38DD-A4F9-430F-9FD4-8BA6E5FCB2EA@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm just making a status report for my experiments. I did a: dd if=3DFreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da1 bs=3D1m = conv=3Dfsync,sync status=3Dprogress I made no adjustments. 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 <return>. The (official) RPi keyboard was plugged into a USB2 port. Unfortunately there is a known issue for my context where it gets: 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. So booting all the way requires me to make an adjustment in the config.txt by adding at the end something like: [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 [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.] 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). 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. 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. 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.) FYI: # 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 [pi4] hdmi_safe=3D1 armstub=3Darmstub8-gic.bin [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 # 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" (That is unchanged from the image's /boot/loader.conf content.) I'll see about stable/13's snapshot with the u-boot.bin substitution. 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.) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D29F33D9-DF25-4BD7-853D-50DED525C4FF>