Re: keyboard doesn't work at Boot Menu
- In reply to: Mark Millard : "Re: keyboard doesn't work at Boot Menu"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 18 Jun 2023 04:35:52 UTC
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: > >> On Jun 17, 2023, at 19:09, bob prohaska <fbsd@www.zefox.net> wrote: >> >>> [apologies if I'm barging in] >>> >>> Just for fun I tried rebooting my 8GB Pi4 running -current >>> from the video console and USB keyboard (old Logitec). >>> >>> On reboot there was no beastie menu (maybe it was turned off) >> >> You later show /boot/loader.conf as having: >> >> beastie_disable="YES" >> >> So: turned off. >> >>> but the loader responded to the USB keyboard to allow boot to >>> single user mode. >> >> So you entered "boot -s" as a loader command? >> >>> The HDMI output ended with >>> .... >>> Dual Console: Serial Primary, Video Secondary >>> and after that the keyboard became unresponsive, >> >> USB keyboard specifically (not serial console)? >> Serial console? >> >> Also, does "unresponsive" mean that neither the >> serial console output nor the HDMI display showed >> evidence of progress? Did you look in both places? >> >> And which HDMI port was in use, the one nearer to >> the USB3 power port? >> >>> although the caps lock key still toggled the light. >>> >>> Meanwhile the serial console reported: >> >> Was there serial console output between the "Dual >> Console" line and the below that you have not >> reported? >> >>> >>> Enter full pathname of shell or RETURN for /bin/sh: >>> After hitting return, >> >> USB keyboard specifically (not serial console)? >> Serial console? >> >>> it continued >>> Cannot read termcap database; >>> using dumb terminal settings. >>> Cannot read termcap database; >>> using dumb terminal settings. >>> >>> Issuing exit to the root shell on the serial >>> console brought up a login prompt on the video >>> console and it worked as normal. >>> >>> At this point /boot/msdos/config.txt contains >>> [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 >>> gpio=2,3=a0 >> >> Having hdmi_safe=1 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=0" if you want the >> first part of the file to match the default >> content exactly. >> >> The gpio line is not default content. >> >> I'm not aware of any of this being a problem. >> >>> which I think haven't been tampered with. >>> >>> /boot/loader.conf contains >>> # 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" >>> filemon_load="YES" >>> # net.inet.tcp.tolerate_missing_ts="1" >>> #hw.usb.debug=1 >>> vm.pageout_oom_seq="4096" >> >> Having a figure bigger than the default >> vm.pageout_oom_seq=12 may well be >> important. I've never needed more than >> 120. >> >>> vm.pfault_oom_attempts="120" >>> vm.pfault_oom_wait="20" >> >> That is 20 seconds * 120 == 2400 seconds, >> i.e., 40 minutes being allowed overall for >> trying a specific page fault up to 120 >> times. >> >> This seems oddly large. The defaults are: >> >> vm.pfault_oom_attempts= 3 >> vm.pfault_oom_wait= 10 >> >> so 30 seconds overall for trying the >> specific page fault up to 3 times. >> >>> [likely the vm stuff is pointless] >>> >>> If there's anything useful I can try please say so. >>> >> >> I'll have to set up an experiment and try it >> based on the recent snapshot of main. >> > > Well, that lead to an interesting discovery separate > from your issue: initial_turbo=60 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 > [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 > over_voltage=6 > arm_freq=2000 > sdram_freq_min=3200 > force_turbo=1 > # > [pi4] > hdmi_safe=0 > > > That avoided the USB timeout. > > With that out of the way, I can confirm your report, > where the serial console showed: > > . . . > da0: quirks=0x2<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: > 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=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" > > (The default.) > > Changing that to: > > # 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" > > and retrying leads to the serial console for > "boot -s" showing just: > > . . . > da0: quirks=0x2<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: > > 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]. > I've changed to using: # more /boot/efi/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 ? # WARNING, not sufficient for "boot -s": that needs the full force_turbo=1 initial_turbo=60 [pi4] over_voltage=6 arm_freq=2000 sdram_freq_min=3200 force_turbo=1 # hdmi_safe=0 So that only the RPi4's do the over_voltage . . . force_turbo sequence with the specific values. === Mark Millard marklmi at yahoo.com