Date: Wed, 12 Jul 2023 19:09:56 +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: <CAFDf7UL9-SQ-ok_Of6=YsTLN82SJEjnHAdd-3UX8tFsvuhGJ7w@mail.gmail.com> In-Reply-To: <F5CB80D8-3E29-4CF7-B0FB-D93FC74E981B@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> <CAFDf7U%2BbduLFtqgdSnNcT6C6TRsp0tUXdr3aYE2QL2dumXDJjg@mail.gmail.com> <F5CB80D8-3E29-4CF7-B0FB-D93FC74E981B@yahoo.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
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)
[-- Attachment #2 --]
<div dir="ltr"><div>Hello Mark!</div><div><br></div><div>Great news:</div><div><br></div><div>I can confirm that rpi official keyboard works as intended and boot menu works.</div><div><br></div><div>Thanks!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Mark Millard <<a href="mailto:marklmi@yahoo.com">marklmi@yahoo.com</a>> escreveu no dia domingo, 18/06/2023 à(s) 00:36:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Jun 17, 2023, at 16:01, Nuno Teixeira <<a href="mailto:eduardo@freebsd.org" target="_blank">eduardo@freebsd.org</a>> wrote:<br>
<br>
> - tested it on both USB2 and USB3 ports and same error.<br>
> - added a gamer keyboard on all ports and same error.<br>
> - tested with both keyboads connected, but only one get error from the normal keyboard, both failed with same error :)<br>
> <br>
> at boot time, none keyboards work.<br>
> at login time, both works.<br>
> <br>
> I'm very curious about raspberry original keyboard! I will buy it next week.<br>
<br>
Most of the keyboards that I have access to are<br>
much older, many of then from Apple. There is<br>
only one PC USB gaming keyboard and mouse, not<br>
that they were ever used for such. There is<br>
just the one RPi keyboard and mouse.<br>
<br>
I used the more modern, fairly common keyboard<br>
because trying to figure out if old equipment<br>
related failures are actually the same type of<br>
failure did not seem reasonable. Trying to<br>
match old equipment for comparison/contrast<br>
activities did not seem reasonable either.<br>
<br>
That the modern keyboard happens to be an RPi<br>
one is an accident.<br>
<br>
> Thanks very much for this awesome time that I learned more.<br>
> Thanks for your patience!<br>
> <br>
> And I will stay tuned for updates on firmware and continue testing stable/current snapshots to check if boot is fixed.<br>
> <br>
> Cheers,<br>
> <br>
> Mark Millard <<a href="mailto:marklmi@yahoo.com" target="_blank">marklmi@yahoo.com</a>> escreveu no dia sábado, 17/06/2023 à(s) 23:41:<br>
> On Jun 17, 2023, at 15:28, Nuno Teixeira <<a href="mailto:eduardo@freebsd.org" target="_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..."<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="mailto:marklmi@yahoo.com" target="_blank">marklmi@yahoo.com</a>> escreveu no dia sábado, 17/06/2023 à(s) 23:08:<br>
> > [Commenting out beastie_disable="YES" and loader_color="NO"<br>
> > in stable/13.]<br>
> > <br>
> > On Jun 17, 2023, at 14:42, Mark Millard <<a href="mailto:marklmi@yahoo.com" target="_blank">marklmi@yahoo.com</a>> wrote:<br>
> > <br>
> > > [This time I add continuing the sequence to test the stable/13 snapshot.]<br>
> > > <br>
> > > On Jun 17, 2023, at 13:56, Mark Millard <<a href="mailto:marklmi@yahoo.com" target="_blank">marklmi@yahoo.com</a>> wrote:<br>
> > > <br>
> > >> On Jun 17, 2023, at 13:53, Mark Millard <<a href="mailto:marklmi@yahoo.com" target="_blank">marklmi@yahoo.com</a>> wrote:<br>
> > >> <br>
> > >>> I'm just making a status report for my experiments.<br>
> > >>> <br>
> > >>> I did a:<br>
> > >>> <br>
> > >>> dd if=FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img of=/dev/da1 bs=1m conv=fsync,sync status=progress<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=USB_ERR_TIMEOUT<br>
> > >>> uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 3<br>
> > >>> mountroot: waiting for device /dev/ufs/rootfs...<br>
> > >>> Mounting from ufs:/dev/ufs/rootfs failed with error 19.<br>
> > >>> <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>
> > >>> # uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT<br>
> > >>> # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ?<br>
> > >>> initial_turbo=60<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<br>
> > >>> 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<br>
> > >>> 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 keyboard<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=1<br>
> > >>> dtparam=audio=on,i2c_arm=on,spi=on<br>
> > >>> dtoverlay=mmc<br>
> > >>> dtoverlay=disable-bt<br>
> > >>> device_tree_address=0x4000<br>
> > >>> kernel=u-boot.bin<br>
> > >>> <br>
> > >>> [pi4]<br>
> > >>> hdmi_safe=1<br>
> > >>> armstub=armstub8-gic.bin<br>
> > >>> <br>
> > >>> [all]<br>
> > >>> #<br>
> > >>> # Local addition that avoids USB3 SSD boot failures that look like:<br>
> > >>> # uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT<br>
> > >>> # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ?<br>
> > >>> initial_turbo=60<br>
> > >>> <br>
> > >>> # more /boot/loader.conf<br>
> > >>> # Configure USB OTG; see usb_template(4).<br>
> > >>> hw.usb.template=3<br>
> > >>> umodem_load="YES"<br>
> > >>> # Multiple console (serial+efi gop) enabled.<br>
> > >>> boot_multicons="YES"<br>
> > >>> boot_serial="YES"<br>
> > >>> # Disable the beastie menu and color<br>
> > >>> beastie_disable="YES"<br>
> > >>> loader_color="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-boot.bin<br>
> > >>> substitution.<br>
> > >>> <br>
> > >>> <br>
> > >>> Side note: I've other USB3 boot media for which having<br>
> > >>> usb_pgood_delay=2000 in U-Boot is sufficient but default<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:<br>
> > >>> sufficient but possibly not necessary.)<br>
> > > <br>
> > > This is based on:<br>
> > > <br>
> > > dd if=FreeBSD-13.2-STABLE-arm64-aarch64-RPI-20230615-894492f5bf4e-255597.img of=/dev/da0 bs=1m conv=fsync,sync status=progress<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 1 root wheel 601096 Apr 6 19:47:52 2023 /media/u-boot.bin<br>
> > > -rwxr-xr-x 1 root wheel 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>
> > > < < [all]<br>
> > > < #<br>
> > > < # Local addition that avoids USB3 SSD boot failures that look like:<br>
> > > < # uhub_reattach_port: port ? reset failed, error=USB_ERR_TIMEOUT<br>
> > > < # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port ?<br>
> > > < initial_turbo=60<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 1 root wheel 1180860 Apr 6 20:48:14 2023 /media/EFI/BOOT/bootaa64.efi<br>
> > > -rwxr-xr-x 1 root wheel 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 ,<br>
> > > I'll go back and look at your notes about file content and the<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: 17:40:52<br>
> > > BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=1673458852 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=3<br>
> > umodem_load="YES"<br>
> > # Multiple console (serial+efi gop) enabled.<br>
> > boot_multicons="YES"<br>
> > boot_serial="YES"<br>
> > # Disable the beastie menu and color<br>
> > # beastie_disable="YES"<br>
> > # loader_color="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>
===<br>
Mark Millard<br>
marklmi at <a href="http://yahoo.com" rel="noreferrer" target="_blank">yahoo.com</a><br>
<br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><span style="color:rgb(102,102,102)">Nuno Teixeira<br>FreeBSD Committer (ports)</span></div></div>
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFDf7UL9-SQ-ok_Of6=YsTLN82SJEjnHAdd-3UX8tFsvuhGJ7w>