Date: Sat, 17 Jun 2023 21:35:52 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org>, Nuno Teixeira <eduardo@freebsd.org> Subject: Re: keyboard doesn't work at Boot Menu Message-ID: <AE7937D2-1639-433B-9244-E7D2DD427243@yahoo.com> In-Reply-To: <45029007-99E4-4A6B-A0C1-6DFBF1CB0565@yahoo.com> References: <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> <ZI5nciOWhWmoOZE4@www.zefox.net> <7D97AA65-3D7F-456B-8279-B987606EB8C6@yahoo.com> <45029007-99E4-4A6B-A0C1-6DFBF1CB0565@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 17, 2023, at 21:13, Mark Millard <marklmi@yahoo.com> wrote: > On Jun 17, 2023, at 20:08, Mark Millard <marklmi@yahoo.com> wrote: >=20 >> On Jun 17, 2023, at 19:09, bob prohaska <fbsd@www.zefox.net> wrote: >>=20 >>> [apologies if I'm barging in] >>>=20 >>> Just for fun I tried rebooting my 8GB Pi4 running -current >>> from the video console and USB keyboard (old Logitec).=20 >>>=20 >>> On reboot there was no beastie menu (maybe it was turned off) >>=20 >> You later show /boot/loader.conf as having: >>=20 >> beastie_disable=3D"YES" >>=20 >> So: turned off. >>=20 >>> but the loader responded to the USB keyboard to allow boot to >>> single user mode. >>=20 >> So you entered "boot -s" as a loader command? >>=20 >>> The HDMI output ended with >>> .... >>> Dual Console: Serial Primary, Video Secondary >>> and after that the keyboard became unresponsive, >>=20 >> USB keyboard specifically (not serial console)? >> Serial console? >>=20 >> Also, does "unresponsive" mean that neither the >> serial console output nor the HDMI display showed >> evidence of progress? Did you look in both places? >>=20 >> And which HDMI port was in use, the one nearer to >> the USB3 power port? >>=20 >>> although the caps lock key still toggled the light. >>>=20 >>> Meanwhile the serial console reported: >>=20 >> Was there serial console output between the "Dual >> Console" line and the below that you have not >> reported? >>=20 >>>=20 >>> Enter full pathname of shell or RETURN for /bin/sh: >>> After hitting return, >>=20 >> USB keyboard specifically (not serial console)? >> Serial console? >>=20 >>> it continued=20 >>> Cannot read termcap database; >>> using dumb terminal settings. >>> Cannot read termcap database; >>> using dumb terminal settings. >>>=20 >>> Issuing exit to the root shell on the serial >>> console brought up a login prompt on the video >>> console and it worked as normal.=20 >>>=20 >>> At this point /boot/msdos/config.txt contains >>> [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 >>>=20 >>> [pi4] >>> #hdmi_safe=3D1 >>> armstub=3Darmstub8-gic.bin >>> gpio=3D2,3=3Da0 >>=20 >> Having hdmi_safe=3D1 commented out is not default >> content but likely is very common to improve what >> is displayed. An alernative is to have a separate, >> later line that has "hdmi_safe=3D0" if you want the >> first part of the file to match the default >> content exactly. >>=20 >> The gpio line is not default content. >>=20 >> I'm not aware of any of this being a problem. >>=20 >>> which I think haven't been tampered with. >>>=20 >>> /boot/loader.conf contains >>> # 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" >>> filemon_load=3D"YES" >>> # net.inet.tcp.tolerate_missing_ts=3D"1" >>> #hw.usb.debug=3D1 >>> vm.pageout_oom_seq=3D"4096" >>=20 >> Having a figure bigger than the default >> vm.pageout_oom_seq=3D12 may well be >> important. I've never needed more than >> 120. >>=20 >>> vm.pfault_oom_attempts=3D"120" >>> vm.pfault_oom_wait=3D"20" >>=20 >> That is 20 seconds * 120 =3D=3D 2400 seconds, >> i.e., 40 minutes being allowed overall for >> trying a specific page fault up to 120 >> times. >>=20 >> This seems oddly large. The defaults are: >>=20 >> vm.pfault_oom_attempts=3D 3 >> vm.pfault_oom_wait=3D 10 >>=20 >> so 30 seconds overall for trying the >> specific page fault up to 3 times. >>=20 >>> [likely the vm stuff is pointless] >>>=20 >>> If there's anything useful I can try please say so. >>>=20 >>=20 >> I'll have to set up an experiment and try it >> based on the recent snapshot of main. >>=20 >=20 > Well, that lead to an interesting discovery separate > from your issue: initial_turbo=3D60 does not work for > my "boot -s" use: the USB timeouts occur anyway. >=20 > I ended up replacing initial_turbo with my normal > overclocking that involves force_turbo for the > "boot -s" use experiment: >=20 > # more /boot/efi/config.txt=20 > [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 >=20 > [pi4] > hdmi_safe=3D1 > armstub=3Darmstub8-gic.bin >=20 > [all] > # > # Local addition that avoids USB3 SSD boot failures that look like: > # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT > # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling = port ? > #initial_turbo=3D60 > over_voltage=3D6 > arm_freq=3D2000 > sdram_freq_min=3D3200 > force_turbo=3D1 > # > [pi4] > hdmi_safe=3D0 >=20 >=20 > That avoided the USB timeout. >=20 > With that out of the way, I can confirm your report, > where the serial console showed: >=20 > . . . > da0: quirks=3D0x2<NO_6_BYTE> > Warning: no time-of-day clock registered, system time will not be set = accurately > Dual Console: Serial Primary, Video Secondary > Enter full pathname of shell or RETURN for /bin/sh:=20 > root@:/ # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/ufs/rootfs 4892 2793 1707 62% / > devfs 0 0 0 0% /dev > . . . >=20 > but the video console stopped at the > "Dual Console: . . ." line. >=20 > But I expect that this is considered normal: > "boot -s" likely only supports the Primary > console at its extra stage, here the Serial > console. FYI: >=20 > # 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" >=20 > (The default.) >=20 > Changing that to: >=20 > # 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" >=20 > and retrying leads to the serial console for > "boot -s" showing just: >=20 > . . . > da0: quirks=3D0x2<NO_6_BYTE> > Warning: no time-of-day clock registered, system time will not be set = accurately > Dual Console: Video Primary, Serial Secondary >=20 > and the video console being where the: >=20 > Enter full pathname of shell or RETURN for /bin/sh:=20 >=20 > shows up and operates. The USB keyboard worked just > fine for this. So, again, "boot -s" only supported > the Primary console for the extra stage. >=20 >=20 > I did this experiment with: >=20 > # uname -apKU > FreeBSD generic 14.0-CURRENT FreeBSD 14.0-CURRENT #0 = main-n263574-456c1199d3b3: Thu Jun 15 11:08:03 UTC 2023 = root@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 aarch64 1400090 1400090 >=20 > But I expect that is is not specific to main > [so: 14]. >=20 I've changed to using: # more /boot/efi/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_TIMEOUT # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = ? # WARNING, not sufficient for "boot -s": that needs the full = force_turbo=3D1 initial_turbo=3D60 [pi4] over_voltage=3D6 arm_freq=3D2000 sdram_freq_min=3D3200 force_turbo=3D1 # hdmi_safe=3D0 So that only the RPi4's do the over_voltage . . . force_turbo sequence with the specific values. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE7937D2-1639-433B-9244-E7D2DD427243>