Re: keyboard doesn't work at Boot Menu

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 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