Excellent, I have everything set up properly, and I can now call this a
success. I'll post my instructions on how to accomplish this (which should
be adaptable to other boards running NetBSD in the near future). I think ppp
is still relevant b/c it provides a mechanism to put small Ethernet-less
boards on the Internet.
For those still following along:
For one, the interrupt rate at that speed can be very high and the
hardware FIFO buffer built into the serial port can be too small.
So you may drop characters which causes PPP retries so that the net
speed will be much lower.
460800 baud is a safer bet than 921600 baud. I don't know whether this is
due to NetBSD or my cable (I suspect the former b/c a serial login works
fine; it's only when the system is under heavy load that it occurs). In
fact, my top speed (about 43kB/s) is fastest at 460800 baud. Not impressive,
but certainly tolerable.
-----Original Message-----
From: Michael van Elst
Sent: Sunday, September 17, 2017 11:28 AM
To: William D. Jones
Cc: netbsd-users@netbsd.org
Subject: Re: Routing ppp (Was: Getty on USB serial port)
On Sun, Sep 17, 2017 at 09:40:43AM -0400, William D. Jones wrote:
Hello again,
Got everything working this morning- can access pi from my home network
through Beagleboard (needing to set ip_forwarding=1 in kernel). Then I
realized something when trying to boost the link speed:
> The initial parameters for the RPI1+2 serial console are hardwired into
the kernel as 115.2kbps and 8N1. You can build a custom kernel to change
this by adding options PLCONSPEED and/or PLCONMODE.
By hardwired, you mean "trying to force a speed change using a gettytab
entry will not work?" Because I've noticed ppp.230400 does not function
correctly. And is this hardwiring unique to the Pi? Maybe I will build a
custom kernel after all.
Hardwired just means that the initial speed is defined as that. Getty
can of course change it. Getty uses standard ioctl calls which can
set a fixed set of standard speeds up to B921600 when supported by
the hardware. The codes are defined in <sys/termios.h>
This has nothing to do with the speeds supported by the hardware. For
the RPI1+2 console, the speeds are based on a 3MHz clock which is
divided by 16. So the max speed using this setup is 3Mbps/16 = 187500 bps.
The 3MHz clock is however not the maximum supported by the hardware,
just the default configuration set by the firmware. You can change
this by setting the parameter init_uart_clock in /boot/config.txt
and rebooting. A value of 14745600 allows standard speeds up to
B921600 and most important, the driver will automatically adjust
to the changed clock.
There are still two obstacles :)
For one, the interrupt rate at that speed can be very high and the
hardware FIFO buffer built into the serial port can be too small.
So you may drop characters which causes PPP retries so that the net
speed will be much lower.
For the RPI3 console this is worse as it uses a "mini"-UART without
FIFO as the "full" UART is used for the bluetooth adapter. If you
give up bluetooth, you could reconfigure the console to use the
good UART.
For two, the GPIO signal drivers aren't meant to drive such a
high frequency signal. Depending on cable type and length, the
low signal quality will prevent error free reception.
Greetings,
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
--
William D. Jones
thor0...@comcast.net
