Date: Mon, 8 Jan 2024 02:55:23 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Marcin Cieslak <saper@saper.info>, freebsd-arm@freebsd.org Subject: Re: USB-serial adapter suggestions needed Message-ID: <C8723D84-D5B8-41E6-9F29-1C1B83BCC0F0@yahoo.com> In-Reply-To: <C40967D3-D480-41DD-8054-421EA7AE5EFE@yahoo.com> References: <ZZoOMoM/iwcFqSNi@www.zefox.net> <7D27DF9F-AA9A-4D44-BC28-8CC637D0F550@yahoo.com> <C40967D3-D480-41DD-8054-421EA7AE5EFE@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 7, 2024, at 08:48, Mark Millard <marklmi@yahoo.com> wrote: > On Jan 6, 2024, at 19:00, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >>> On Jan 6, 2024, at 18:36, bob prohaska <fbsd@www.zefox.net> wrote: >>>=20 >>> =EF=BB=BFOn Sat, Jan 06, 2024 at 11:44:49PM +0000, Marcin Cieslak = wrote: >>>>> On Fri, 5 Jan 2024, Mark Millard wrote: >>>>>=20 >>>>> I also request to again list the exact content of the two >>>>> config.txt files --and again every time they are changed during >>>>> this investigation. >>>>=20 >>>> I second this. There is way too much text in this conversation >>>> and not enough data. It also does not help if every system is = somewhat >>>> different. >>>=20 >>> Unfortunately, the systems simply are different. Four Pi2 >>=20 >> Please differentiate RPi2B v1.1 (armv7) from v1.2 (aarch64). >=20 > I meant that to be a general request to never reference just > RPi2B. The v1.1 vs. v1.2 was an unfortunate marketing naming > for the armv7 vs. aarch64 change that ends up needing such > extra text to give the proper context. >=20 >> I suggest armv7 use the snapshot armv7=E2=80=99s config.txt as its >> config.txt prefix. Now that I have my normal internet access back, FYI: # dd = if=3DFreeBSD-15.0-CURRENT-arm-armv7-GENERICSD-20240104-8bf0882e186e-267378= .img of=3D/dev/da0 bs=3D1m conv=3Dfsync,sync status=3Dprogress 5205131264 bytes (5205 MB, 4964 MiB) transferred 18.064s, 288 MB/s 5120+0 records in 5120+0 records out 5368709120 bytes transferred in 18.680162 secs (287401640 bytes/sec) # mount -onoatime -tmsdosfs /dev/da0s1 /mnt # more /mnt/config.txt init_uart_clock=3D3000000 enable_uart=3D1 kernel=3Du-boot.bin kernel7=3Du-boot.bin dtoverlay=3Dmmc >>> , two Pi3, >>> one Pi4. I'll try to make the config.txt files on the Pi3s match >>> better when the present experiment is complete. The interconnection >>> of hosts is unique and, apparently, unusual. Not all of that is >>> relevant, but exatctly what part isn't yet obvious. >>>=20 >>>>=20 >>>> I have skimmed the peripherial documentation for one of the = Broadcom >>>> chips (I think the one from Raspberry Pi 3) and it says that >>>> the speed of the mini uart depends on the CPU clock frequency. >>>>=20 >>>> I could imagine a situation when mini uart speed changes during >>>> downlocking the CPU. There was suggestion to not use mini uart. >>>> Use the port where the frequency is not changing with the weather. >>>>=20 >>>=20 >>> Agreed, and I changed config.txt to set >>> dtoverly=3Ddisable-bt >>> on www.zefox.org (the console host) to force use of the PL011. >>> It didn't help detectably. >>>=20 >>>> I don't know how smart is the power management with powerd, but >>>> I could also imagine shutting down peripherials or stopping the = UART >>>> clock as a potential power saving feature, so here you are. >>>=20 >>> No sign of that, but Mark posited that powerd might be causing >>> trouble with the terminal server (pelorus in this test). That >>> looks like a possibility. At the moment pelorus is without >>> powerd and it's holding a serial connection to www.zefox.org. >>>=20 >>> Meanwhile www.zefox.org is running powerd and buildworld >>> while being a terminal server to a Pi4 named nemesis.zefox.com >>> That connection has dropped twice so far today. >>=20 >> Interesting. You have not reported on nemesis.zefox.com =E2=80=98s = config.txt >> content or powerd status. Also, which type of RPi* ? >=20 > If the chart you referenced is right for the issue: RPi4B. (Other > details about turned out to be in accurate at the time as I > remember, so the cross check seems appropriate.) If so, that > still leaves the status of powerd and the config.txt content > to publicly document. >=20 > Also, as I understand the reports, a system running both tip and > powerd ends up dropping the serial console connection at times. > A system running tip but not powerd does not drop the connection. >=20 > However, it might be that some form of test of a RPi* running > powerd and just tip and not ssh might be useful. Similarly for > a RPi* running powerd and just ssh, not tip. I'd expect that > the tip+powerd-ssh case (so no ssh) to fail and the > ssh+powerd-tip case (so: no tip) to not fail. =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?C8723D84-D5B8-41E6-9F29-1C1B83BCC0F0>