<diego71>
115200 was the max serial speed on classic pc
apritzel has joined #linux-sunxi
<apritzel>
DuClare: the baudrate of the serial line is a user choice, so you can easily change it, even at runtime
<apritzel>
for instance via the kernel command line, or whatever you use for getty
<apritzel>
but why would you actually want to to that? Normally the serial console is a debug feature, especially in embedded devices
<apritzel>
and apart from what diego71 said, 115200 is kind of a well known standard baudrate, even some USB serial adapters don't support higher baudrates
<apritzel>
so by using 115200 just everywhere *by default*, we avoid one annoying problem when people want to bring up their boards
<apritzel>
DuClare: but please try it, on a shell prompt, connected via a serial terminal, type "stty 1500000", then change your terminal program's baudrate to the same rate
<apritzel>
DuClare: oh, there are some limitations, as MoeIcenowy mentioned: the incoming clock is 1.5 MHz (24MHz/16), so from the somewhat standard baudrates only 500k and 1500k work
<apritzel>
the rest cannot be programmed via only an integer divider
vagrantc has quit [Quit: leaving]
<Jookia>
i had an interesting issue where i had to re-flash my 3d printer firmware to not use a baud of 2.5MHz because the D1 couldn't clock to it
<Jookia>
3.84MHz it is
<Jookia>
3.804*
<apritzel>
Jookia: the D1 uses APB1 as the UART clock source, which *can* be muxed to PLL_PERI(1x), so 600 MHz
<apritzel>
that should give you 3.75MHz baudrate (600 / 16 / 10), that's an error of 1.41%, which should be accepted by the other end
<Jookia>
yeah i think that's what happens
<apritzel>
but I don't know if Linux' common clock framework does the re-parenting automatically
<Jookia>
i'm not sure
<Jookia>
this is allwinner's kernel
<Jookia>
i think it has a table
<apritzel>
oh, then all bets are off ;-)
<apritzel>
problem is that I2C also hangs off that same clock, so the I2C dividers would need to changed as well