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."