Date: Sun, 18 Jun 2023 00:01:53 +0100 From: Nuno Teixeira <eduardo@freebsd.org> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org Subject: Re: keyboard doesn't work at Boot Menu Message-ID: <CAFDf7U%2BbduLFtqgdSnNcT6C6TRsp0tUXdr3aYE2QL2dumXDJjg@mail.gmail.com> In-Reply-To: <7D1BE218-B8B5-40EB-8CF3-C09CDEABA9C3@yahoo.com> References: <CAFDf7ULWff1YNA675-0ZdSgRM-t6RnCHO9RSTshPS0k8xfc6xw@mail.gmail.com> <99542360-6350-4636-A9EA-CA9BBCC93C60@yahoo.com> <CAFDf7U%2B3NR8ETaxg2W9j%2BXkm-sNaCdFSCXNMLA_GmxnRayeZuQ@mail.gmail.com> <5D8D94E2-781D-4945-B721-EDD0BF56A8F2@yahoo.com> <CAFDf7UKZmZZS6aKf=43-A_2eXDHq3%2BPcC3Hqbp1s7umrcJDA_g@mail.gmail.com> <C3CF38DD-A4F9-430F-9FD4-8BA6E5FCB2EA@yahoo.com> <D29F33D9-DF25-4BD7-853D-50DED525C4FF@yahoo.com> <70CC43FC-2055-409E-A94E-76F934C14AE2@yahoo.com> <5875BDD2-B792-4FE1-8F42-99D996CAE71D@yahoo.com> <EB48AEA2-7027-4576-9A7D-F74BA9CF0912@yahoo.com> <CAFDf7UKwGCxfvQQ9khdBaiiBNFvVSO71ZtRPr7iDMQ6=sheunA@mail.gmail.com> <7D1BE218-B8B5-40EB-8CF3-C09CDEABA9C3@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000003c769005fe5b4a2e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
- 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=C3=A1bado, 17/06/2023 =
=C3=A0(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 raspberr=
y
> original)
> >
> > Thanks
> >
> > Mark Millard <marklmi@yahoo.com> escreveu no dia s=C3=A1bado, 17/06/202=
3
> =C3=A0(s) 23:08:
> > [Commenting out beastie_disable=3D"YES" and loader_color=3D"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=3DFreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img of=3D/dev/da1 bs=
=3D1m
> conv=3Dfsync,sync status=3Dprogress
> > >>>
> > >>> 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=3DUSB_ERR_TIMEOUT
> > >>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling por=
t
> 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=3DUSB_ERR_TIMEOU=
T
> > >>> # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling
> port ?
> > >>> initial_turbo=3D60
> > >>>
> > >>> [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=3D1
> > >>> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don
> > >>> dtoverlay=3Dmmc
> > >>> dtoverlay=3Ddisable-bt
> > >>> device_tree_address=3D0x4000
> > >>> kernel=3Du-boot.bin
> > >>>
> > >>> [pi4]
> > >>> hdmi_safe=3D1
> > >>> armstub=3Darmstub8-gic.bin
> > >>>
> > >>> [all]
> > >>> #
> > >>> # Local addition that avoids USB3 SSD boot failures that look like:
> > >>> # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOU=
T
> > >>> # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling
> port ?
> > >>> initial_turbo=3D60
> > >>>
> > >>> # more /boot/loader.conf
> > >>> # Configure USB OTG; see usb_template(4).
> > >>> hw.usb.template=3D3
> > >>> umodem_load=3D"YES"
> > >>> # Multiple console (serial+efi gop) enabled.
> > >>> boot_multicons=3D"YES"
> > >>> boot_serial=3D"YES"
> > >>> # Disable the beastie menu and color
> > >>> beastie_disable=3D"YES"
> > >>> loader_color=3D"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=3D2000 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=3DFreeBSD-13.2-STABLE-arm64-aarch64-RPI-20230615-894492f5bf4e-255597.i=
mg
> of=3D/dev/da0 bs=3D1m conv=3Dfsync,sync status=3Dprogress
> > >
> > > 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.bi=
n
> > >
> > > # 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=3DUSB_ERR_TIMEOU=
T
> > > < # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling
> port ?
> > > < initial_turbo=3D60
> > > # 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=3D1673458852 ser=
ial
> 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=3D3
> > umodem_load=3D"YES"
> > # Multiple console (serial+efi gop) enabled.
> > boot_multicons=3D"YES"
> > boot_serial=3D"YES"
> > # Disable the beastie menu and color
> > # beastie_disable=3D"YES"
> > # loader_color=3D"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.
> >
>
>
> =3D=3D=3D
> Mark Millard
> marklmi at yahoo.com
>
>
--=20
Nuno Teixeira
FreeBSD Committer (ports)
--0000000000003c769005fe5b4a2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>- tested it on both USB2 and USB3 ports and same erro=
r.</div><div>- added a gamer keyboard on all ports and same error.</div><di=
v>- tested with both keyboads connected, but only one get error from the no=
rmal keyboard, both failed with same error :)<br></div><div><br></div><div>=
at boot time, none keyboards work.</div><div>at login time, both works.</di=
v><div><br></div><div>I'm very curious about raspberry original keyboar=
d! I will buy it next week.</div><div><br></div><div>Thanks very much for t=
his awesome time that I learned more.</div><div>Thanks for your patience!</=
div><div><br></div><div>And I will stay tuned for updates on firmware and c=
ontinue testing stable/current snapshots to check if boot is fixed.</div><d=
iv><br></div><div>Cheers,<br></div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">Mark Millard <<a href=3D"mailto:markl=
mi@yahoo.com">marklmi@yahoo.com</a>> escreveu no dia s=C3=A1bado, 17/06/=
2023 =C3=A0(s) 23:41:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">On Jun 17, 2023, at 15:28, Nuno Teixeira <<a href=3D"mailto:eduard=
o@freebsd.org" target=3D"_blank">eduardo@freebsd.org</a>> wrote:<br>
<br>
> I think I found the cause!<br>
> <br>
> Please take a look at photo.<br>
> <br>
> "Scanning xhci_pci devices... Failed to get keyboard state...&quo=
t;<br>
<br>
That message was displayed by U-Boot before the<br>
FreeBSD UEFI loader was even loaded to memory.<br>
<br>
The FreeBSD UEFI loader operates by using U-Boot<br>
services. If U-Boot fails to set up the keyboard<br>
input, the same would be true in the FreeBSD UEFI<br>
loader (beastie or otherwise) until FreeBSD's<br>
kernel does its own bindings and things get another<br>
chance at working.<br>
<br>
(A similar point goes for storage media that U-Boot<br>
fails to set up.)<br>
<br>
Is the keyboard plugged into a USB2 port? USB3? Have<br>
you tried both ways?<br>
<br>
It does seem that the system and keyboard are not<br>
well matched.<br>
<br>
> After a while it gets detected during boot. I've pressed enter key=
and I saw it creating empty line at boot.<br>
> Maybe it's a keyboard problem? I'm using a very cheap one (not=
raspberry original)<br>
> <br>
> Thanks <br>
> <br>
> Mark Millard <<a href=3D"mailto:marklmi@yahoo.com" target=3D"_blank=
">marklmi@yahoo.com</a>> escreveu no dia s=C3=A1bado, 17/06/2023 =C3=A0(=
s) 23:08:<br>
> [Commenting out beastie_disable=3D"YES" and loader_color=3D&=
quot;NO"<br>
> in stable/13.]<br>
> <br>
> On Jun 17, 2023, at 14:42, Mark Millard <<a href=3D"mailto:marklmi@=
yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br>
> <br>
> > [This time I add continuing the sequence to test the stable/13 sn=
apshot.]<br>
> > <br>
> > On Jun 17, 2023, at 13:56, Mark Millard <<a href=3D"mailto:mar=
klmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br>
> > <br>
> >> On Jun 17, 2023, at 13:53, Mark Millard <<a href=3D"mailto=
:marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br>
> >> <br>
> >>> I'm just making a status report for my experiments.<b=
r>
> >>> <br>
> >>> I did a:<br>
> >>> <br>
> >>> dd if=3DFreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img of=3D/=
dev/da1 bs=3D1m conv=3Dfsync,sync status=3Dprogress<br>
> >>> <br>
> >>> I made no adjustments.<br>
> >>> <br>
> >>> I then tried using the USB3 media to start a boot of<br>
> >>> a 8 GiByte RPi4B. It took my typing to the RPi<br>
> >>> keyboard just fine: I did not have to wait for<br>
> >>> the timeout when I hit <return>. The (official) RPi=
<br>
> >>> keyboard was plugged into a USB2 port.<br>
> >>> <br>
> >>> Unfortunately there is a known issue for my context where=
it<br>
> >>> gets:<br>
> >>> <br>
> >>> uhub_reattach_port: port 3 reset failed, error=3DUSB_ERR_=
TIMEOUT<br>
> >>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), dis=
abling port 3<br>
> >>> mountroot: waiting for device /dev/ufs/rootfs...<br>
> >>> Mounting from ufs:/dev/ufs/rootfs failed with error 19.<b=
r>
> >>> <br>
> >>> So booting all the way requires me to make an adjustment<=
br>
> >>> in the config.txt by adding at the end something like:<br=
>
> >>> <br>
> >>> <br>
> >>> [all]<br>
> >>> #<br>
> >>> # Local addition that avoids USB3 SSD boot failures that =
look like:<br>
> >>> #=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, er=
ror=3DUSB_ERR_TIMEOUT<br>
> >>> #=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR=
_TIMEOUT), disabling port ?<br>
> >>> initial_turbo=3D60<br>
> >>> <br>
> >>> [It appears that with modern EEPROM context, the RPi* is<=
br>
> >>> dynamically adjusting the frequency/voltage combinations<=
br>
> >>> even during early booting. The initial_turbo use delays<b=
r>
> >>> that for the indicated number of seconds (up to 60 sec).<=
br>
> >>> FreeBSD seems to not handle the variability and the above=
<br>
> >>> gives FreeBSD a stable context for such properties for<br=
>
> >>> early booting.]<br>
> >>> <br>
> >>> I conclude that there is nothing about use of the RPi<br>
> >>> keyboard that stops it from working during early booting<=
br>
> >>> of 13.2-RELEASE. The RPi* firmware, U-Boot, and FreeBSD<b=
r>
> >>> UEFI loader all work, other than possibly needing a<br>
> >>> initial_turbo addition (or analogous that would span<br>
> >>> at least that early boot time frame).<br>
> >>> <br>
> >>> If you had/have problems for the 13.2-RELEASE context,<br=
>
> >>> they are likely somehow specific to your context in some<=
br>
> >>> respect that deviates from the above.<br>
> >>> <br>
> >>> In some respects, investigating in the older context may<=
br>
> >>> be better than dealing with stable/13 . It may be keyboar=
d<br>
> >>> specific in some way if the keyboard is not an RPi<br>
> >>> keyboard. I did not have a mouse plugged in. An Ethernet<=
br>
> >>> cable was plugged in for the booting.<br>
> >> <br>
> >> I forgot to mention having the HDMI connection plugged<br>
> >> into the HDMI port nearest the USB3 power connector.<br>
> >> <br>
> >> As I remember, the other port stops updating its display<br>
> >> at some point during the boot.<br>
> >> <br>
> >>> I just retried with the RPi keyboard plugged into a USB3<=
br>
> >>> port instead. It worked the same. (The boot media is also=
<br>
> >>> plugged into a USB3 port and is USB3 capable SSD media.)<=
br>
> >>> <br>
> >>> FYI:<br>
> >>> <br>
> >>> # more /boot/msdos/config.txt <br>
> >>> [all]<br>
> >>> arm_64bit=3D1<br>
> >>> dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don<br>
> >>> dtoverlay=3Dmmc<br>
> >>> dtoverlay=3Ddisable-bt<br>
> >>> device_tree_address=3D0x4000<br>
> >>> kernel=3Du-boot.bin<br>
> >>> <br>
> >>> [pi4]<br>
> >>> hdmi_safe=3D1<br>
> >>> armstub=3Darmstub8-gic.bin<br>
> >>> <br>
> >>> [all]<br>
> >>> #<br>
> >>> # Local addition that avoids USB3 SSD boot failures that =
look like:<br>
> >>> #=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, er=
ror=3DUSB_ERR_TIMEOUT<br>
> >>> #=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR=
_TIMEOUT), disabling port ?<br>
> >>> initial_turbo=3D60<br>
> >>> <br>
> >>> # more /boot/loader.conf<br>
> >>> # Configure USB OTG; see usb_template(4).<br>
> >>> hw.usb.template=3D3<br>
> >>> umodem_load=3D"YES"<br>
> >>> # Multiple console (serial+efi gop) enabled.<br>
> >>> boot_multicons=3D"YES"<br>
> >>> boot_serial=3D"YES"<br>
> >>> # Disable the beastie menu and color<br>
> >>> beastie_disable=3D"YES"<br>
> >>> loader_color=3D"NO"<br>
> >>> <br>
> >>> (That is unchanged from the image's /boot/loader.conf=
content.)<br>
> >>> <br>
> >>> <br>
> >>> I'll see about stable/13's snapshot with the u-bo=
ot.bin<br>
> >>> substitution.<br>
> >>> <br>
> >>> <br>
> >>> Side note: I've other USB3 boot media for which havin=
g<br>
> >>> usb_pgood_delay=3D2000 in U-Boot is sufficient but defaul=
t<br>
> >>> U-Boot contexts do not find the media suring the USB scan=
.<br>
> >>> (There could be a better setting to use for all I know:<b=
r>
> >>> sufficient but possibly not necessary.)<br>
> > <br>
> > This is based on:<br>
> > <br>
> > dd if=3DFreeBSD-13.2-STABLE-arm64-aarch64-RPI-20230615-894492f5bf=
4e-255597.img of=3D/dev/da0 bs=3D1m conv=3Dfsync,sync status=3Dprogress<br>
> > <br>
> > First dealing with the U-Boot vintage-avoidance issue:<br>
> > <br>
> > # mount -onoatime -tmsdosfs /dev/da1s1 /media<br>
> > # mount -onoatime -tmsdosfs /dev/da0s1 /mnt<br>
> > <br>
> > # ls -Tld /media/u-boot.bin /mnt/u-boot.bin<br>
> > -rwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 601096 Apr=C2=A0 6 19:4=
7:52 2023 /media/u-boot.bin<br>
> > -rwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 602552 Jun 14 19:43:46 =
2023 /mnt/u-boot.bin<br>
> > <br>
> > # cp -aRx /media/u-boot.bin /mnt/<br>
> > <br>
> > Then dealing with the initial_turbo issue:<br>
> > <br>
> > # diff /media/config.txt /mnt/config.txt <br>
> > 12,18d11<br>
> > <=C2=A0 < [all]<br>
> > < #<br>
> > < # Local addition that avoids USB3 SSD boot failures that loo=
k like:<br>
> > < #=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, error=
=3DUSB_ERR_TIMEOUT<br>
> > < #=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_ERR_TI=
MEOUT), disabling port ?<br>
> > < initial_turbo=3D60<br>
> > # cp -aRx /media/config.txt /mnt/<br>
> > <br>
> > Finally, checking things overall in the msdosfs:<br>
> > <br>
> > # diff -rq /media/ /mnt/<br>
> > Files /media/EFI/BOOT/bootaa64.efi and /mnt/EFI/BOOT/bootaa64.efi=
differ<br>
> > <br>
> > # ls -Tld /media/EFI/*/* /mnt/EFI/*/*<br>
> > -rwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 1180860 Apr=C2=A0 6 20:=
48:14 2023 /media/EFI/BOOT/bootaa64.efi<br>
> > -rwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 1182604 Jun 14 20:47:12=
2023 /mnt/EFI/BOOT/bootaa64.efi<br>
> > <br>
> > So: No other differences than the vintage of the FreeBSD UEFI<br>
> > loader.<br>
> > <br>
> > This also booted just fine, taking my input to avoid having<br>
> > to wait for the timeout. The only difference is which USB3<br>
> > SSD was plugged in (the boot drive), in this case the one<br>
> > with a stable/13 snapshot instead of a releng/13.2 snapshot.<br>
> > The rest of the ports were as they had been.<br>
> > <br>
> > FYI:<br>
> > <br>
> > # uname -apKU<br>
> > FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n255597=
-894492f5bf4e GENERIC arm64 aarch64 1302505 1302505<br>
> > <br>
> > Having confirmed this much for both releng/13.2 and stable.13 ,<b=
r>
> > I'll go back and look at your notes about file content and th=
e<br>
> > like and see if I notice any distinctions vs. the above that<br>
> > might be important.<br>
> > <br>
> > <br>
> > Notes:<br>
> > <br>
> > I doubt that the RPi4B EEPROM image vintage would contribute, but=
<br>
> > it is something we have not been explicit about.<br>
> > <br>
> > I do have various debug outputs enabled, including for<br>
> > the EEPROM stage. The following is what it reports <br>
> > about the EEPROM content ("BOOTLOADER release") at<br>
> > power down after FreeBSD is done:<br>
> > <br>
> > RPi: BOOTLOADER release VERSION:8ba17717 DATE: 2023/01/11 TIME: 1=
7:40:52<br>
> > BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=3D1673458852=
serial c740af3c boardrev d03115 stc 421180<br>
> > Halt: wake: 1 power_off: 0<br>
> > <br>
> > The "boardrev d03115" indicates a "C0T" Rev1.=
5 vintage part<br>
> > that does not require the bounce buffer work around since<br>
> > the wrapper logic is fixed. (FreeBSD keeps working as if<br>
> > the bounce buffer was required: it is the only style of<br>
> > operation the kernel code has for the category of part.)<br>
> > <br>
> > I have access to a 8 GiByte Rev 1.4 RPi4B and a Rev 1.1<br>
> > 4 GiByte RPi4B and could test those with the same media<br>
> > and such. All would have the same "BOOTLOADER release"<=
br>
> > as above, as I remember.<br>
> > <br>
> > <br>
> > A you sure you have the HDMI plugged into the correct HDMI<br>
> > port on the RPi4B, the one closest to the USB3 power<br>
> > connection?<br>
> <br>
> [I have also changed the /bin/csh defaults to /bin/sh<br>
> (which is my normal context).]<br>
> <br>
> # more /boot/loader.conf<br>
> # Configure USB OTG; see usb_template(4).<br>
> hw.usb.template=3D3<br>
> umodem_load=3D"YES"<br>
> # Multiple console (serial+efi gop) enabled.<br>
> boot_multicons=3D"YES"<br>
> boot_serial=3D"YES"<br>
> # Disable the beastie menu and color<br>
> # beastie_disable=3D"YES"<br>
> # loader_color=3D"NO"<br>
> <br>
> # shutdown -r now<br>
> <br>
> And the beastie shows up and works just fine,<br>
> operated from the USB RPi keyboard.<br>
> <br>
> <br>
> My bias here is to have minimal differences from<br>
> the RELEASE and snapshot builds relative to the<br>
> reported problem. I still see no evidence of any<br>
> problem with use of the RPi keyboard to control<br>
> booting.<br>
> <br>
<br>
<br>
=3D=3D=3D<br>
Mark Millard<br>
marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target=3D"_blank=
">yahoo.com</a><br>
<br>
</blockquote></div><br clear=3D"all"><br><span class=3D"gmail_signature_pre=
fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"l=
tr"><span style=3D"color:rgb(102,102,102)">Nuno Teixeira<br>FreeBSD Committ=
er (ports)</span></div></div>
--0000000000003c769005fe5b4a2e--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFDf7U%2BbduLFtqgdSnNcT6C6TRsp0tUXdr3aYE2QL2dumXDJjg>