Re: USB-serial adapter suggestions needed

[Back to just some cell phone based internet access.]

On Jan 6, 2024, at 08:33, bob prohaska <fbsd@www.zefox.net> wrote:

> On Fri, Jan 05, 2024 at 07:26:16PM -0800, Mark Millard wrote:
>> 
>> I'd next try having powerd disabled only on the terminal server
>> pelorus and then checking for getting a failure.
>> 
> 
> I started powerd manually on www.zefox.org using
> powerd -a adp (which I think is the default)
> last night. The machine's console connection lasted all night.
> Previously powerd was started via /etc/rc.conf. Might that be
> somewhat different?
> 
> However, early in the evening I accidentally crashed the RPiOS
> workstation, forcing me to re-establish all the console sessions.
> When the connection to www.zefox.org came back up it was prefaced
> by the usual non-printable gibberish. That session is still up
> as I write this. Could the gibberish be the result of getty
> activity on www.zefox.org as it establishes the connection from
> pelorus (the terminal server)? Part of baudrate negotiations, 
> maybe?

Serial baud rates are not negotiated or automatically matched. The
2 sides are set separately but have to be kept in agreement from
both sides. The send and receive directions have the same baud rate
at both ends (when configured to work). One end is the tip end
and the other end is via the GPIO pins on the other RPi* in this
kind of context.

Of course, things like Ethernet do have configuration matching.
But that is a different context.

> The overnight test was unloaded. Now www.zefox.org has been 
> updated: Updating 499e84e16f56..aa1223ac3afc
> with a -j4 build/install cycle running with 3.5 GB swap
> divided between two USB mechanical hard disks.  
> 
>> Last I would try instead having www.zefox.org <http://www.zefox.org/> be the only one
>> of the two with powerd disabled.
>> 
> That test will come next, in a couple of days.
> 
>> I expect that having powerd disabled just on pelorus will prove
>> sufficient and that having powerd disabled just on www.zefox.org <http://www.zefox.org/>
>> will not prove sufficient.
>> 
> 
> So the difficulty is on the ethernet-usb-serial side? 
> I was thinking it's on the serial-console side, maybe
> an inadvertent escape sequence from baud mismatch.

Lets just wait for the 2 experiments. My expectations are
not valid evidence. I probably should not have said anything
about my expectations.

>> 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.
>> 
> 
> On pelorus, the terminal server, config.txt contains:
> bob@pelorus:~ % 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

The above is what FreeBSD's snapshots for aarch64
provide. The below is not. (I'm igoring the needed
force_mac_address line that is a required differnece.)

> On www.zefox.org, the console client, config.txt contains
> bob@www:~ % more /boot/msdos/config.txt
> arm_64bit=1
> dtoverlay=disable-bt
> init_uart_clock=3000000
> enable_uart=1
> kernel=u-boot.bin
> kernel7=u-boot.bin
> dtoverlay=mmc
> force_mac_address=b8:27:eb:71:46:4f

I suggest you instead use the likes of:

[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

# Local addition:
[all]
force_mac_address=b8:27:eb:71:46:4f

(In this form the first 11 lines, if I
counted right, are unchanged from the
snapshot content. Note that earlier lines
can be overridden by later lines in that
local additions section.)

I would prefer if the testing was based
on having the uniformity instead of the
existing varaibility in the config.txt
files.

> I'll admit to some uncertainty where 
> init_uart_clock=3000000
> and 
> kernel7=u-boot.bin
> came from.

Look at the official armv7 snapshot's config.txt
content. It looks like you started from an armv7
config.txt instead of from an aarch64 one.

I suggest that you make your aarch64 config.txt
files uniform, other than things like
force_mac_address being added where needed.

This uniformity criteria would imply that if you
discovered that some line was important for the
serial console that it be supplied in all the
aarch64 config.txt files, not just the one where
the issue was discovered.

> The latter seems harmless, but I'm
> not so sure about the former.

Judging evidence of sufficiency is easier for
having uniformity where it proves possible.
Otherwise there are more things to deal with
and wonder if they contribute or not.

>> You also have the option of fixed-rate clocking that is faster
>> than FreeBSD default. This can be controlled from config.txt .
> 
> As a last resort, yes. Still, I'd like to minimize power use
> to the extent possible.

That gets into if the failures are infrequent enough
that you can tolerate them and continue to use
powerd for the power savings (presuming no other
alternative is readily available that happens to work).
Not for me to say.

> Powerd seems optimized for laptops.
> Maybe it isn't the right tool for mains-powered, lightly
> loaded servers which occasionally see saturation loads.


===
Mark Millard
marklmi at yahoo.com