From nobody Sun Jun 18 04:35:52 2023 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QkKpc1Bdpz4f77K for ; Sun, 18 Jun 2023 04:36:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QkKpb0lRKz4DcL for ; Sun, 18 Jun 2023 04:36:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="e/Fm8Zjp"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687062965; bh=LgOss9d6XmOuJQwly7LQ0N1ECGPtBQSlgdfrDeZq9Xc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=e/Fm8Zjp14cvmoS2fCdztX/3rjfJqpTEERT0Vq1CIttsDZiB6TKfrHYgRzT1e8fyvG1+lMZALnZuPad+PVBjLoe0pe+44W9x4c6wNTL466r5xGOTBCoYZpDgHRsz0c+6EAEYv9SaedvdhvBNCfy8qoSIK9Jc7NaEzaa6+ppOTy2aemAEakUs6efrr2zcs58XAZYyKiCpmvS3hhDz16XpcIqXr9J6JmHXdSFnV6tuCMjXUxhUhNDUqV/BHhFLsrtwm82VH9KxieD010sZcEQjuTslpNxyVno4635hLksp4IfTih0WjrjV/jMWblB0elJNAc9EKIJrSdI30DVYOigUbw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687062965; bh=oUhndtHcOwdD4diSCxSnS2EiFPyEtRWGx8A5anCFHuS=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eHWXjDWZ1CQzeq5pDWs8RLVK5wK0Wcu2VyJnRo46K2zvcnE9K5hL0GV0jWfpXXkaPJa9ySMbW0vR6Gr+XEsxM3R29QUm7aKp9QH410ToZ5F0/SJ9IF6SLS5vDAtXqCAmkIEPn8ERG20rsONkhV4JU91n42tIq2OvWLyjMYcDE1MrM6014HcmB4gqHItDAT55iOJtyE0g3SAoGM2wJEt0MmWUi7qt7j5KnpslDuua3pgoHCcsmOLXXRwcivNzw30EnYjNqewhFF+DBwRkdNyPDacBoDx20EPnyR1h5x/tY7ZyhgCCRFw6akchKoA/Szbt6B6AcDc4ZKpI2+H992ZrJg== X-YMail-OSG: Y32BLMkVM1njco9LBxejQxd4Ud0q0m5Upykl0mR0pnGz58isX4C3jtu5jC1BXIl SxFEqpFSWfi.0Im3SweL9iq_caQoOYaFB.WFXKfyLbuRmxchzHf3LONbtYAsNKMRUVbBCv_3jq.I hDtxXMzC4aEuS_PUX3dyHajNY9WevGKrH0aSLjfFcWYWwePoIrsReZhrEH8CBOgODUyonMr3fEuz eFr_Z_BPOki2Lmt_XJG7.FspEow.IVWhCtT24Z0be7OQaSnLxv0C9g1JSFhwkvQGWUYSOj6InmM7 f.bHU53F6RsnKzjYz_qxrMQea34ITxnYlmFCV34e8Ykv4oa9o0OWme8gZtd0os_0U.n1nQ4yAcGS KhUEnBON9FHvHtFanpPx2G1SiWLVXAdXGohQP31EQOt42nCJyWoRLDoGoG8dwLCtyreeJGn5jcQt VE2TFaBTPEuCQVBdKmLJCI9ZxBB4WGGqIA1MKeOUgPwoe8tpEe3pFJgOq5mK0pMbpOEDVCdOh3QX nyZsPwefN8jyr2FUOFWEogYfLBg9K7aciJVtmWNXTe9KGU49tuT.kOh75wgwgx7fxZP1wcp4r.bo s5rWKAp9uqtcvoOuiRuE3EAEoG36kVnqIWujqcpvKwvJKaiHVj3HMp46evnCWCO55bPHQpQm9fiw CpqbxIqkHkQ.X9tjuby14pCitUHTXrQaqfpDJYUFHoYiad5LxtczUzf9cKDYLkxt7ZaaszYFJ3Tz 6XK81EGrCv7A7OIcDnKDdZq8TtfwcsCs9yqfV3ocree9sQB2W8OJ8xZKybN9GN_DNpKU0P9MeMxh qKqQcHJyXl97efilU3Qr6tgo1dyWbHLuuMxB.KR7_NLqRyoLgvzeRwj8qIiFXLg_XwhL2ax80UvE 4fTWs_eXmfM98yGlgQqvIF8l.hM7PYSo6HD4_iQM_bxtVNXmCnng3G_0qYUr_iNqjRDS_.SVW7Np yq6UydZ1feVmccabH6NSZOYgB0R2Y0nZYK2ItuEbfLcAN0RLWZOULUbaAby_reHUta9ifzHvrVmz 47rYBiiegVDjRfkvyO7NHk83SkkqAhuE9qOLZ_fhVYLaFJmpxta.7PI.HOgcrePjaNFI2IRSNyjR F0mraVD1BtBJO_wSeEaVQWf8YPIRLq6cx6_B0T2m4vS97tSjKGzeMnU9FA_isw50sfrxQv7tlVH4 teZIMZ02fPQX8.ZyEbMfkBtKn3z9awJH1cBntEUfb9prTnTwkIpBRZfEoSrriXCcki4ptFCpHtTk oOysVW8kzvTQSndBbnE2Am2I.ZptWx772DdoWJiPBqBezdcFXO1a4JyVDKqg15MZxZWIKoYkwRvx d4x2SeplvV7uE67Q6XdqMrgBPVVOq60f5kkvVguB_W0y0xp8dRpUNLq_.ysEmiDhLtPc7Zx.4n7S diCoZq2sHXhRSzW34jxCQ4PWfD3OwIOkCg71qZcn_3Lgh8dsbaL7pb7uG_DhVKrGvGBRl0KXnz_A 6s_gC3S7k_ydWON8Y8rbG443_RhLLmprtqixydOhXVzZd0sWPRqWhEsE6WT.CaPjxGAnibsETCPF fZRnBemJGqXBRuhJ6GXvxYwJP1MsI33ZW5JiNk5osVEMn25xSZiQIOhDvNnz3O7_OPSeqcesBCAJ ty5VFbClHSNDVf9X265hmM2TuL.0rCH3tERYGO4jtCZRxDAfH.ptZLdgWyAWxxHpmuIcROK206qK FhZ4yqHguSVacfradKqmax5ta.Ek7v4YMbUSXSuHdFFsyhrYTDZCyas6UZNCVM3r93N94NJPlVmc k.AW0fFu.ThJ94M5XWAdfimKbhFVqoBKvrxEGY.0byd6bEVaXxdNJwdPy1Gx9OcDEFdHKmef7EjF 8F_zBzkfxdPZiUUyn0dMM8xHgr_A1GBl2pSpQTXDC6iBVfURdDWScMsQZA7n_1aTqh5E7hi4TdW_ RPULbgMM9QHJb4TLwijrre3hd2GPh6EkGxCI8fRXOGwgewkRYgD9QhpThVkIbmflZODHIEnedOpG 8qs_tDnBePqed9sJo6JZ41gRcyjiDlWnMbqpfUlDFEpZcr3onMF3PuUA8poa8s8qo__u0y_sZYHu tV7rBIfYukR_yIr03z9nlmkT.ioShvMjSGHSndR1WRy8VjclUycbRYFeNouywlw25fgmoPylbnXy TpLq19Llrn28vPg2VegKJYPUMaj5Vv6NS7nq0v6Bvzf97ztqFJct9n5jhBz47n080KTsbivxtXTD CzfGeg_tVmojby26iqy839pc4EMbPwI6yyotn6SYQaLEJzaOIg23O.hfWAMWn1fTWqcjZRtqgFnO M X-Sonic-MF: X-Sonic-ID: 8e7ddc10-2fc6-46e4-9ae0-1d9d5f3f3a84 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 18 Jun 2023 04:36:05 +0000 Received: by hermes--production-ne1-574d4b7954-cm564 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f105181ed09b55d1c4a2af0e601f1447; Sun, 18 Jun 2023 04:36:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: keyboard doesn't work at Boot Menu From: Mark Millard In-Reply-To: <45029007-99E4-4A6B-A0C1-6DFBF1CB0565@yahoo.com> Date: Sat, 17 Jun 2023 21:35:52 -0700 Cc: freebsd-arm , Nuno Teixeira Content-Transfer-Encoding: quoted-printable Message-Id: References: <70CC43FC-2055-409E-A94E-76F934C14AE2@yahoo.com> <5875BDD2-B792-4FE1-8F42-99D996CAE71D@yahoo.com> <7D1BE218-B8B5-40EB-8CF3-C09CDEABA9C3@yahoo.com> <7D97AA65-3D7F-456B-8279-B987606EB8C6@yahoo.com> <45029007-99E4-4A6B-A0C1-6DFBF1CB0565@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3731.600.7) X-Spamd-Result: default: False [-3.44 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.995]; NEURAL_HAM_MEDIUM(-0.95)[-0.949]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from] X-Rspamd-Queue-Id: 4QkKpb0lRKz4DcL X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Jun 17, 2023, at 21:13, Mark Millard wrote: > On Jun 17, 2023, at 20:08, Mark Millard wrote: >=20 >> On Jun 17, 2023, at 19:09, bob prohaska 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 > 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 > 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