Normal baudrate for Rockchip boards

[z4v4l]

Hi. I got tired of this insane 1500000 baud/s speed, Rockchip made default for UART. I can't use UART for debug/trace normally - no utilities work with this. minicom corrupts output, screen doesn't configure at all. I can't attach the board directly to my machine, because the adapter I can use with it, doesn't work with such speed, I need to attach it through a pine64 board, and there, the mentioned utilities get their pants dirty with this speed too... I was told how to make uboot run on 115200 baud/s. this is by setting the environment variable baudrate (and storing it for the permanent effect, I checked it, rock64 works fine with this speed, let's hope saveenv will work too), but what do I need to do for linux to make it use 115200 baud/s permanently? Does anybody know? I think, this might be useful not only for me, because this poor choice of the speed gives a lot of troubles for others too. many USB-UART adapters don't support it. Just don't tell, I need to compile the kernel! I hope it involves some dancing with DT? I am not a linux guy.
And yet, why not switch to this normal speed for builds? Literally everything works just fine with 115200 baud/s. This would eliminate so much of frustration.

[z4v4l]

C'mon, dudes, is my question so stupid or nobody knows the answer? Haven't you suffered from utilities' malfunctions caused by this very unusual speed? I write now an OS loader for my hobby OS, yup, there are such use cases, and on Pine64 everything goes like a charm. But with Rock64, I can't see the output!

[tllim]

C'mon, dudes, is my question so stupid or nobody knows the answer? Haven't you suffered from utilities' malfunctions caused by this very unusual speed? I write now an OS loader for my hobby OS, yup, there are such use cases, and on Pine64 everything goes like a charm. But with Rock64, I can't see the output!

The 15000000 speed determine by Rockchip and we  follow as is. Knowing that not all serial consoles are "happy" to operate in such high bit rate.

[z4v4l]

yes, I understand, but it does work with 115200 baud/s too. I set it in uboot and it worked. Then, when linux started to boot, as expected, garbage was spitted out on the screen - linux is configured for 1500000 baud/s. My question is to knowledgeable in linux people, what one needs to set in linux, to make it use 115200 baud/s? Inside an OS, it's actually a matter of configuring the clock for the UART controller, right? But what steps need to have been done on the user part to force that configuration?
I've looked through the Rockchip DTs for rk3328/rock64 and found this (rk3328-rock64.dts):

Code:

chosen {
bootargs = "rockchip_jtag earlyprintk=uart8250-32bit,0xff130000 swiotlb=1 kpti=0";
stdout-path = "serial2:1500000n8";
};

So far so good, but it wouldn't be so easy, right? Really, a few lines below, we see another setting up:

Code:

fiq-debugger {
compatible = "rockchip,fiq-debugger";
rockchip,serial-id = <2>;
rockchip,signal-irq = <159>;
rockchip,wake-irq = <0>;
/* If enable uart uses irq instead of fiq */
rockchip,irq-mode-enable = <0>;
rockchip,baudrate = <1500000>; /* Only 115200 and 1500000 */
interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
status = "okay";
};

Sooo, this multiple setting up is what prevents me from just going and changing these fields. What if linux has yet other places where it (again and again) configures UART2? People knowing linux internals might help.

[tllim]

yes, I understand, but it does work with 115200 baud/s too. I set it in uboot and it worked. Then, when linux started to boot, as expected, garbage was spitted out on the screen - linux is configured for 1500000 baud/s. My question is to knowledgeable in linux people, what one needs to set in linux, to make it use 115200 baud/s? Inside an OS, it's actually a matter of configuring the clock for the UART controller, right? But what steps need to have been done on the user part to force that configuration?
I've looked through the Rockchip DTs for rk3328/rock64 and found this (rk3328-rock64.dts):

Code:

chosen {
bootargs = "rockchip_jtag earlyprintk=uart8250-32bit,0xff130000 swiotlb=1 kpti=0";
stdout-path = "serial2:1500000n8";
};

So far so good, but it wouldn't be so easy, right? Really, a few lines below, we see another setting up:

Code:

fiq-debugger {
compatible = "rockchip,fiq-debugger";
rockchip,serial-id = <2>;
rockchip,signal-irq = <159>;
rockchip,wake-irq = <0>;
/* If enable uart uses irq instead of fiq */
rockchip,irq-mode-enable = <0>;
rockchip,baudrate = <1500000>; /* Only 115200 and 1500000 */
interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
status = "okay";
};

Sooo, this multiple setting up is what prevents me from just going and changing these fields. What if linux has yet other places where it (again and again) configures UART2? People knowing linux internals might help.

Just PM me your address and phone number (for shipping purpose), I just provide a serial console to you.

[z4v4l]

thank you, tllim, your generosity is inexhaustible. but I do own such a console, I bought it from the Pine64 store, so no need to worry. My problem is not with the USB-UART adapter, it is with utilities - minicom, cu, screen. they don't work with the set up I need to use. I tried to explain this in the OP, but apparently failed on that.

[psychedup]

There's a couple of places to look. First, there's usually a kernel command line argument that tells it what speed to use for dmesg output when booting. For example, on my PineA64+ in /boot/uEnv.txt:

Code:

console=tty0 console=ttyS2,115200n8 no_console_suspend
kernel_filename=pine64/Image
initrd_filename=initrd.img
#fdt_filename_prefix=pine64/sun50i-a64-tp-
fdt_filename_prefix=pine64/sun50i-a64-hdmi-
optargs=disp.screen0_output_mode=1080p60

the "console=ttyS1,115200n8" is setting the serial port speed.

On my Rock64 I don't see that, but in /boot/efi/extlinux/extlinux.conf looks like this:

Code:

timeout 30
default kernel-4.4.138
menu title select kernel

label kernel-4.18.0-rc8
   kernel /Image-4.18.0-rc8
   initrd /initrd.img
   fdt /dtb-4.18.0-rc8
   append rw root=UUID=2791c0dd-f329-4734-adc7-aebb589fdb53 rootwait rootfstype=ext4 panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1

I wonder if that "{serial#}" is something being passed to the kernel by u-boot?

Besides the command line, you also want to look at /etc/inittab. There should be a line similar to this:

Code:

s2:12345:respawn:/sbin/agetty -L 115200 ttyS2 vt100

Your serial port might be some other device besides ttyS2 - but the 115200 on this line is setting the serial port speed for logins over this serial port.

Hope that helps a little.

Chris

[t4_4t]

>> the "console=ttyS1,115200n8" is setting the serial port speed.

I actually tried it, it's all right with only above addition.
(However, unless the "u-boot" freezes due to garbled characters on boot-up ....)

Code:

label kernel-4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   kernel /boot/vmlinuz-4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   initrd /boot/initrd.img-4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   devicetreedir /boot/dtbs/4.4.167-1163-rockchip-ayufan-g3d2c5b33817a
   append console=ttyS2,115200n8 rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root_sd1 rootwait rootfstype=ext4

Confirmed that Linux:ttyS2 is running at "baudrate=115200".

Code:

~# stty -a
speed 115200 baud; rows 35; columns 132; line = 0;
...

~# uname -a
Linux Rock64 4.4.167-1163-rockchip-ayufan-g3d2c5b33817a #1 SMP Tue Mar 26 15:06:19 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

*** CAUTION ***
If you execute "saveenv" on "u-boot", you can not restore it. (See below.)

Code:

=> setenv baudrate 115200
## Switch baudrate to 115200 bps and press ENTER ...

=> setenv baudrate 1500000
## Baudrate 1500000 bps not supported
## Error inserting "baudrate" variable, errno=22

----
>> I wonder if that "{serial#}" is something being passed to the kernel by u-boot?

"u-boot" passes "{serial#}", but which is a HASH value of "cpuid#".
So it has nothing to do with this issue.

[z4v4l]

Thank you all. I actually fixed it yesterday, it was too late to post about it. I added a couple of lines in the /boot/boot.cmd (I use Armbian) and recompiled it. Those changes set on the fly new baudrate for UART2 in related properties in two nodes of the DT (this file, lines 52 and 62). Also set uboot's "baudrate" and it works now. Both uboot and linux use 115200 baud/s speed. I only get some little amount of boxes at the very beginning of the boot, this is most probably ROM code output, but it's tiny, it's tolerable. But now I can use Rock64 with an adapter, that doesn't support 1500000 baud/s but otherwise is very good, and most importantly - that I can directly insert into my computer.