Date: Sat, 17 Jun 2023 21:13:04 -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: <45029007-99E4-4A6B-A0C1-6DFBF1CB0565@yahoo.com> In-Reply-To: <7D97AA65-3D7F-456B-8279-B987606EB8C6@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 17, 2023, at 20:08, Mark Millard <marklmi@yahoo.com> wrote: > 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 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. I ended up replacing initial_turbo with my normal overclocking that involves force_turbo for the "boot -s" use experiment: # 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 [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 = ? #initial_turbo=3D60 over_voltage=3D6 arm_freq=3D2000 sdram_freq_min=3D3200 force_turbo=3D1 # [pi4] hdmi_safe=3D0 That avoided the USB timeout. With that out of the way, I can confirm your report, where the serial console showed: . . . 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 . . . but the video console stopped at the "Dual Console: . . ." line. 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: # 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" (The default.) Changing that to: # 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" and retrying leads to the serial console for "boot -s" showing just: . . . 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 and the video console being where the: Enter full pathname of shell or RETURN for /bin/sh:=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. I did this experiment with: # 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 But I expect that is is not specific to main [so: 14]. =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?45029007-99E4-4A6B-A0C1-6DFBF1CB0565>