From nobody Wed Jul 12 18:09:56 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R1Qkn1xZ8z4mmbb for ; Wed, 12 Jul 2023 18:10:09 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R1Qkn1lKfz4Wgy for ; Wed, 12 Jul 2023 18:10:09 +0000 (UTC) (envelope-from eduardo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689185409; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BphJpEvyPDgp2SCl9e8W2/96XYLU3AXY6dQ/kD+ixbc=; b=MQNgRewVFBGGUCgr+bKL45l/WOfxcDk1aaS9T94BeQIhryOMBkM8kXMddd1rx3icOxGZqn jjUCJpr4xHzeHDwinKHqnlut/Q7cn5wIh72Hx1Spqlah3BOJ61HQM5j0+kQNW+iwCKTLrq /qFbJxa1eYUQGyv6q0KSAJ0KGLeChELhFOwzt4U5sDQJyP4WkWE9IPlyJK0ZbYSJrr4Xbo pzbmjdJ7nlqxyEYqawOaotT2/XA6CUP0SRMjhVwfXbcef+7G8A527ucgcbACV9RS7XtmK9 NwhztfsddEzxlfe1HBpXgMUew6XJWYF0BjcKguVX9cLPycvnLm4tvq0kuKIYTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689185409; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BphJpEvyPDgp2SCl9e8W2/96XYLU3AXY6dQ/kD+ixbc=; b=RbfEQJn7GB5BacvcC1ThCoMPOVVMUXEc81rO4EBJU/dAyiZVS2s1TRQeOXrbtZcMwCF7Hp FEJ+SjJk+obWRpchw1pynx7DGZBU79Ky38yMBQZIk4moyrQsK0EJoGYK5zTo8Buc3RvWS+ HKMjmojQWNTp9o5J3oIitrdsbMdAE2cImzLRBdg6vFmGnT7CK3X5Ddw0a+Ob8Ttqc91jp7 ZRLfx0PXkA3RHQSXB1Dk78JGXD7dh4YZgkLV9QxtQmffJ9nWL2gUq3rtpme0Hp1Y1yx1HL LYz1uHRvPP4QwlS7RS6TLqe+8kayQyTGKjgLIRG608Rs1Pnszuyv20Z/78GP2g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689185409; a=rsa-sha256; cv=none; b=xqBCAzS5mgUXpa5RXbr6RJ5lr5q/N7ViYAUZJi/fN2P29tTwvbTrGuuJZyiXK6XUKtu7Sc vESytPK7iGQ+T3eAGzYxQwHDjh9UvgwXvX9163qD28Dn+fGOCGmlSTF8ZK5iHWaLGCTqpG szqVhYvYzwBE8kOC45sK+vWYiIH0cAQryprhyp8Qzlc0ydEHAba6QQnbtRm9+Gj6bDrqse 0DE8pfMKjU84Fvz3ElbEI0j7KJSJ51TI1NQ7jhBNFW+p+MaqTnT0aPVKMI7c7Jr8oax1Ne YGFIAZSsxJmaoCdqiHzvG/Qp9AInaLmJNRNfCceZVNT45nioFMO9Y5+y8bsb1w== Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: eduardo) by smtp.freebsd.org (Postfix) with ESMTPSA id 4R1Qkn0gg2z10RH for ; Wed, 12 Jul 2023 18:10:09 +0000 (UTC) (envelope-from eduardo@freebsd.org) Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-403a7066d9bso28418161cf.3 for ; Wed, 12 Jul 2023 11:10:09 -0700 (PDT) X-Gm-Message-State: ABy/qLZHx2dGS0k1wU+kY/cOw0+3s3gpamjwLnAr+jA7K9BTXzNw0ohL iEUnRx+BQmG0e3vVDUR5TNR+ZbBXcIhrMAJ76ag= X-Google-Smtp-Source: APBJJlGKrUu+M2xAKqAmJBlPpDRPa7eQiOafG44DYld43ijJMWGF1o2Uet+R5XLo1sbBmGSwj4j7d9Wb1o8Ca49H8Sg= X-Received: by 2002:a05:622a:486:b0:3ff:407e:12 with SMTP id p6-20020a05622a048600b003ff407e0012mr21680309qtx.25.1689185408347; Wed, 12 Jul 2023 11:10:08 -0700 (PDT) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 References: <99542360-6350-4636-A9EA-CA9BBCC93C60@yahoo.com> <5D8D94E2-781D-4945-B721-EDD0BF56A8F2@yahoo.com> <70CC43FC-2055-409E-A94E-76F934C14AE2@yahoo.com> <5875BDD2-B792-4FE1-8F42-99D996CAE71D@yahoo.com> <7D1BE218-B8B5-40EB-8CF3-C09CDEABA9C3@yahoo.com> In-Reply-To: From: Nuno Teixeira Date: Wed, 12 Jul 2023 19:09:56 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: keyboard doesn't work at Boot Menu To: Mark Millard Cc: freebsd-arm@freebsd.org Content-Type: multipart/alternative; boundary="00000000000039817e06004e20f0" X-ThisMailContainsUnwantedMimeParts: N --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 escreveu no dia domingo, 18/06/2023 =C3=A0= (s) 00:36: > On Jun 17, 2023, at 16:01, Nuno Teixeira 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 escreveu no dia s=C3=A1bado, 17/06/202= 3 > =C3=A0(s) 23:41: > > On Jun 17, 2023, at 15:28, Nuno Teixeira 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 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 wrote: > > > > > > > [This time I add continuing the sequence to test the stable/13 > snapshot.] > > > > > > > > On Jun 17, 2023, at 13:56, Mark Millard wrote: > > > > > > > >> On Jun 17, 2023, at 13:53, Mark Millard 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 . 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
Hello Mark!

Great news:

I can confirm that rpi official keyboard works as inte= nded and boot menu works.

Thanks!
<= br>
Mark Mi= llard <marklmi@yahoo.com> es= creveu no dia domingo, 18/06/2023 =C3=A0(s) 00:36:
On Jun 17, 2023, at 16:01, Nuno Teixeira= <eduardo@freeb= sd.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 sta= ble/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 ente= r 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=C3=A1bado, 17/06/2023 = =C3=A0(s) 23:08:
> > [Commenting out beastie_disable=3D"YES" and loader_colo= r=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 experimen= ts.
> > >>>
> > >>> I did a:
> > >>>
> > >>> dd if=3DFreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img o= f=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 adjust= ment
> > >>> in the config.txt by adding at the end something lik= e:
> > >>>
> > >>>
> > >>> [all]
> > >>> #
> > >>> # Local addition that avoids USB3 SSD boot failures = that look like:
> > >>> #=C2=A0 =C2=A0uhub_reattach_port: port ? reset faile= d, error=3DUSB_ERR_TIMEOUT
> > >>> #=C2=A0 =C2=A0uhub_reattach_port: device problem (US= B_ERR_TIMEOUT), disabling port ?
> > >>> initial_turbo=3D60
> > >>>
> > >>> [It appears that with modern EEPROM context, the RPi= * is
> > >>> dynamically adjusting the frequency/voltage combinat= ions
> > >>> even during early booting. The initial_turbo use del= ays
> > >>> that for the indicated number of seconds (up to 60 s= ec).
> > >>> FreeBSD seems to not handle the variability and the = above
> > >>> gives FreeBSD a stable context for such properties f= or
> > >>> early booting.]
> > >>>
> > >>> I conclude that there is nothing about use of the RP= i
> > >>> keyboard that stops it from working during early boo= ting
> > >>> of 13.2-RELEASE. The RPi* firmware, U-Boot, and Free= BSD
> > >>> UEFI loader all work, other than possibly needing a<= br> > > >>> 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 contex= t,
> > >>> 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 ke= yboard
> > >>> specific in some way if the keyboard is not an RPi > > >>> keyboard. I did not have a mouse plugged in. An Ethe= rnet
> > >>> 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 med= ia.)
> > >>>
> > >>> 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:
> > >>> #=C2=A0 =C2=A0uhub_reattach_port: port ? reset faile= d, error=3DUSB_ERR_TIMEOUT
> > >>> #=C2=A0 =C2=A0uhub_reattach_port: device problem (US= B_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 d= efault
> > >>> U-Boot contexts do not find the media suring the USB= scan.
> > >>> (There could be a better setting to use for all I kn= ow:
> > >>> sufficient but possibly not necessary.)
> > >
> > > This is based on:
> > >
> > > 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
> > >
> > > 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=C2=A0 1 root=C2=A0 wheel=C2=A0 601096 Apr=C2=A0 6= 19:47:52 2023 /media/u-boot.bin
> > > -rwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 602552 Jun 14 19:4= 3: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
> > > <=C2=A0 < [all]
> > > < #
> > > < # Local addition that avoids USB3 SSD boot failures tha= t look like:
> > > < #=C2=A0 =C2=A0uhub_reattach_port: port ? reset failed, = error=3DUSB_ERR_TIMEOUT
> > > < #=C2=A0 =C2=A0uhub_reattach_port: device problem (USB_E= RR_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/bootaa6= 4.efi differ
> > >
> > > # ls -Tld /media/EFI/*/* /mnt/EFI/*/*
> > > -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
> > > -rwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 1182604 Jun 14 20:= 47:12 2023 /mnt/EFI/BOOT/bootaa64.efi
> > >
> > > So: No other differences than the vintage of the FreeBSD UEF= I
> > > loader.
> > >
> > > This also booted just fine, taking my input to avoid having<= br> > > > 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-n2= 55597-894492f5bf4e GENERIC arm64 aarch64 1302505 1302505
> > >
> > > Having confirmed this much for both releng/13.2 and stable.1= 3 ,
> > > I'll go back and look at your notes about file content a= nd 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 TI= ME: 17:40:52
> > > BOOTMODE: 0x06 partition 63 build-ts BUILD_TIMESTAMP=3D16734= 58852 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&q= uot;
> > > 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



--
Nuno Teixeira
FreeBSD Committ= er (ports)
--00000000000039817e06004e20f0--