Re: keyboard doesn't work at Boot Menu

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

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)