Re: keyboard doesn't work at Boot Menu

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].

===
Mark Millard
marklmi at yahoo.com