![]() |
Normal baudrate for Rockchip boards - Printable Version +- PINE64 (https://forum.pine64.org) +-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85) +--- Forum: Rock64 Hardware and Accessories (https://forum.pine64.org/forumdisplay.php?fid=89) +--- Thread: Normal baudrate for Rockchip boards (/showthread.php?tid=7379) |
Normal baudrate for Rockchip boards - z4v4l - 04-13-2019 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! ![]() 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. RE: Normal baudrate for Rockchip boards - z4v4l - 04-15-2019 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, ![]() RE: Normal baudrate for Rockchip boards - tllim - 04-15-2019 (04-15-2019, 03:03 PM)z4v4l Wrote: 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, 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. RE: Normal baudrate for Rockchip boards - z4v4l - 04-15-2019 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 { Code: fiq-debugger { RE: Normal baudrate for Rockchip boards - tllim - 04-15-2019 (04-15-2019, 04:01 PM)z4v4l Wrote: 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? Just PM me your address and phone number (for shipping purpose), I just provide a serial console to you. RE: Normal baudrate for Rockchip boards - z4v4l - 04-15-2019 ![]() ![]() ![]() RE: Normal baudrate for Rockchip boards - psychedup - 04-16-2019 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 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 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 RE: Normal baudrate for Rockchip boards - t4_4t - 04-16-2019 >> 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 Confirmed that Linux:ttyS2 is running at "baudrate=115200". Code: ~# stty -a *** CAUTION *** If you execute "saveenv" on "u-boot", you can not restore it. (See below.) Code: => setenv baudrate 115200 ---- >> 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. RE: Normal baudrate for Rockchip boards - z4v4l - 04-17-2019 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. |