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>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000039817e06004e20f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =C3=A0= (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=C3=A1bado, 17/06/202= 3 > =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 an= d > 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=C3=A1bado, 17/06/2= 023 > =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 > 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 lik= e: > > > >>> # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIME= OUT > > > >>> # 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 lik= e: > > > >>> # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIME= OUT > > > >>> # 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.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 lik= e: > > > > < # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIME= OUT > > > > < # 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 > 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=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) --00000000000039817e06004e20f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"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 inte= nded and boot menu works.</div><div><br></div><div>Thanks!<br></div></div><= br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Mark Mi= llard <<a href=3D"mailto:marklmi@yahoo.com">marklmi@yahoo.com</a>> es= creveu no dia domingo, 18/06/2023 =C3=A0(s) 00:36:<br></div><blockquote cla= ss=3D"gmail_quote" style=3D"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=3D"mailto:eduardo@freebsd.org" target=3D"_blank">eduardo@freeb= sd.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 sta= ble/current snapshots to check if boot is fixed.<br> > <br> > Cheers,<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:41:<br> > On Jun 17, 2023, at 15:28, Nuno Teixeira <<a href=3D"mailto:eduardo= @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..= ."<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 ente= r 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_colo= r=3D"NO"<br> > > in stable/13.]<br> > > <br> > > On Jun 17, 2023, at 14:42, Mark Millard <<a href=3D"mailto:mar= klmi@yahoo.com" target=3D"_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=3D"mailt= o:marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br> > > > <br> > > >> On Jun 17, 2023, at 13:53, Mark Millard <<a href=3D"m= ailto:marklmi@yahoo.com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:= <br> > > >> <br> > > >>> I'm just making a status report for my experimen= ts.<br> > > >>> <br> > > >>> I did a:<br> > > >>> <br> > > >>> dd if=3DFreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img o= f=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)= , 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 adjust= ment<br> > > >>> in the config.txt by adding at the end something lik= e:<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 faile= d, error=3DUSB_ERR_TIMEOUT<br> > > >>> #=C2=A0 =C2=A0uhub_reattach_port: device problem (US= B_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 combinat= ions<br> > > >>> even during early booting. The initial_turbo use del= ays<br> > > >>> that for the indicated number of seconds (up to 60 s= ec).<br> > > >>> FreeBSD seems to not handle the variability and the = above<br> > > >>> gives FreeBSD a stable context for such properties f= or<br> > > >>> early booting.]<br> > > >>> <br> > > >>> I conclude that there is nothing about use of the RP= i<br> > > >>> keyboard that stops it from working during early boo= ting<br> > > >>> of 13.2-RELEASE. The RPi* firmware, U-Boot, and Free= BSD<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 contex= t,<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 ke= yboard<br> > > >>> specific in some way if the keyboard is not an RPi<b= r> > > >>> keyboard. I did not have a mouse plugged in. An Ethe= rnet<br> > > >>> cable was plugged in for the booting.<br> > > >> <br> > > >> I forgot to mention having the HDMI connection plugged<b= r> > > >> 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 med= ia.)<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 faile= d, error=3DUSB_ERR_TIMEOUT<br> > > >>> #=C2=A0 =C2=A0uhub_reattach_port: device problem (US= B_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-boot.bin<br> > > >>> substitution.<br> > > >>> <br> > > >>> <br> > > >>> Side note: I've other USB3 boot media for which = having<br> > > >>> usb_pgood_delay=3D2000 in U-Boot is sufficient but d= efault<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 kn= ow:<br> > > >>> sufficient but possibly not necessary.)<br> > > > <br> > > > This is based on:<br> > > > <br> > > > dd if=3DFreeBSD-13.2-STABLE-arm64-aarch64-RPI-20230615-89449= 2f5bf4e-255597.img of=3D/dev/da0 bs=3D1m conv=3Dfsync,sync status=3Dprogres= s<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:47:52 2023 /media/u-boot.bin<br> > > > -rwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 602552 Jun 14 19:4= 3: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 tha= t look 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_E= RR_TIMEOUT), 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/bootaa6= 4.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 UEF= I<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<b= r> > > > 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-n2= 55597-894492f5bf4e GENERIC arm64 aarch64 1302505 1302505<br> > > > <br> > > > Having confirmed this much for both releng/13.2 and stable.1= 3 ,<br> > > > I'll go back and look at your notes about file content a= nd 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 TI= ME: 17:40:52<br> > > > BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=3D16734= 58852 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&q= uot;<br> > > > as above, as I remember.<br> > > > <br> > > > <br> > > > A you sure you have the HDMI plugged into the correct HDMI<b= r> > > > 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> --00000000000039817e06004e20f0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFDf7UL9-SQ-ok_Of6=YsTLN82SJEjnHAdd-3UX8tFsvuhGJ7w>