Re: keyboard doesn't work at Boot Menu

Hello Mark!

Great news:

I can confirm that rpi official keyboard works as intended and boot menu
works.

Thanks!

Mark Millard <marklmi@yahoo.com> escreveu no dia domingo, 18/06/2023 à(s)
00:36:

> On Jun 17, 2023, at 16:01, Nuno Teixeira <eduardo@freebsd.org> wrote:
>
> > - tested it on both USB2 and USB3 ports and same error.
> > - added a gamer keyboard on all ports and same error.
> > - tested with both keyboads connected, but only one get error from the
> normal keyboard, both failed with same error :)
> >
> > at boot time, none keyboards work.
> > at login time, both works.
> >
> > I'm very curious about raspberry original keyboard! I will buy it next
> week.
>
> Most of the keyboards that I have access to are
> much older, many of then from Apple. There is
> only one PC USB gaming keyboard and mouse, not
> that they were ever used for such. There is
> just the one RPi keyboard and mouse.
>
> I used the more modern, fairly common keyboard
> because trying to figure out if old equipment
> related failures are actually the same type of
> failure did not seem reasonable. Trying to
> match old equipment for comparison/contrast
> activities did not seem reasonable either.
>
> That the modern keyboard happens to be an RPi
> one is an accident.
>
> > Thanks very much for this awesome time that I learned more.
> > Thanks for your patience!
> >
> > And I will stay tuned for updates on firmware and continue testing
> stable/current snapshots to check if boot is fixed.
> >
> > Cheers,
> >
> > Mark Millard <marklmi@yahoo.com> escreveu no dia sábado, 17/06/2023
> à(s) 23:41:
> > On Jun 17, 2023, at 15:28, Nuno Teixeira <eduardo@freebsd.org> wrote:
> >
> > > I think I found the cause!
> > >
> > > Please take a look at photo.
> > >
> > > "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)
> > >
> > > Thanks
> > >
> > > Mark Millard <marklmi@yahoo.com> escreveu no dia sábado, 17/06/2023
> à(s) 23:08:
> > > [Commenting out beastie_disable="YES" and loader_color="NO"
> > > in stable/13.]
> > >
> > > On Jun 17, 2023, at 14:42, Mark Millard <marklmi@yahoo.com> wrote:
> > >
> > > > [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?
> > >
> > > [I have also changed the /bin/csh defaults to /bin/sh
> > > (which is my normal context).]
> > >
> > > # 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"
> > >
> > > # shutdown -r now
> > >
> > > And the beastie shows up and works just fine,
> > > operated from the USB RPi keyboard.
> > >
> > >
> > > 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.
> > >
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>

-- 
Nuno Teixeira
FreeBSD Committer (ports)