Re: keyboard doesn't work at Boot Menu

Reply: Nuno Teixeira : "Re: keyboard doesn't work at Boot Menu"
Reply: Mark Millard : "Re: keyboard doesn't work at Boot Menu"
In reply to: Mark Millard : "Re: keyboard doesn't work at Boot Menu"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Sat, 17 Jun 2023 21:42:58 UTC
[This time I add continuing the sequence to test the stable/13 snapshot.]

On Jun 17, 2023, at 13:56, Mark Millard <marklmi@yahoo.com> wrote:

> On Jun 17, 2023, at 13:53, Mark Millard <marklmi@yahoo.com> 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.)

This is based on:

dd if=FreeBSD-13.2-STABLE-arm64-aarch64-RPI-20230615-894492f5bf4e-255597.img of=/dev/da0 bs=1m conv=fsync,sync status=progress

First dealing with the U-Boot vintage-avoidance issue:

# mount -onoatime -tmsdosfs /dev/da1s1 /media
# mount -onoatime -tmsdosfs /dev/da0s1 /mnt

# 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

# cp -aRx /media/u-boot.bin /mnt/

Then dealing with the initial_turbo issue:

# diff /media/config.txt /mnt/config.txt 
12,18d11
<  < [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
# cp -aRx /media/config.txt /mnt/

Finally, checking things overall in the msdosfs:

# diff -rq /media/ /mnt/
Files /media/EFI/BOOT/bootaa64.efi and /mnt/EFI/BOOT/bootaa64.efi differ

# 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

So: No other differences than the vintage of the FreeBSD UEFI
loader.

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.

FYI:

# uname -apKU
FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n255597-894492f5bf4e GENERIC arm64 aarch64 1302505 1302505

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.


Notes:

I doubt that the RPi4B EEPROM image vintage would contribute, but
it is something we have not been explicit about.

I do have various debug outputs enabled, including for
the EEPROM stage. The following is what it reports 
about the EEPROM content ("BOOTLOADER release") at
power down after FreeBSD is done:

RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: 17:40:52
BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=1673458852 serial c740af3c boardrev d03115 stc 421180
Halt: wake: 1 power_off: 0

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

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.


A you sure you have the HDMI plugged into the correct HDMI
port on the RPi4B, the one closest to the USB3 power
connection?

===
Mark Millard
marklmi at yahoo.com