Re: keyboard doesn't work at Boot Menu

On Jun 17, 2023, at 13:53, Mark Millard <[email protected]> wrote:

> I'm just making a status report for my experiments.
> 
> I did a:
> 
> dd if=FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img of=/dev/da1 bs=1m conv=fsync,sync status=progress
> 
> 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=USB_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=USB_ERR_TIMEOUT
> #   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ?
> initial_turbo=60
> 
> [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 forgot to mention having the HDMI connection plugged
into the HDMI port nearest the USB3 power connector.

As I remember, the other port stops updating its display
at some point during the boot.

> 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 
> [all]
> arm_64bit=1
> dtparam=audio=on,i2c_arm=on,spi=on
> dtoverlay=mmc
> dtoverlay=disable-bt
> device_tree_address=0x4000
> kernel=u-boot.bin
> 
> [pi4]
> hdmi_safe=1
> armstub=armstub8-gic.bin
> 
> [all]
> #
> # Local addition that avoids USB3 SSD boot failures that look like:
> #   uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT
> #   uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ?
> initial_turbo=60
> 
> # more /boot/loader.conf
> # Configure USB OTG; see usb_template(4).
> hw.usb.template=3
> umodem_load="YES"
> # Multiple console (serial+efi gop) enabled.
> boot_multicons="YES"
> boot_serial="YES"
> # Disable the beastie menu and color
> beastie_disable="YES"
> loader_color="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=2000 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.)



===
Mark Millard
marklmi at yahoo.com