Re: keyboard doesn't work at Boot Menu

On Jun 17, 2023, at 21:13, Mark Millard <[email protected]> wrote:

> On Jun 17, 2023, at 20:08, Mark Millard <[email protected]> wrote:
> 
>> On Jun 17, 2023, at 19:09, bob prohaska <[email protected]> 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     [email protected]:/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