Page MenuHomePhabricator

RK3399_BAUDRATE default value
Open, NormalPublic


I have noticed that default baudrate for rk3399 board RK3399_BAUDRATE defined in plat/rockchip/rk3399/rk3399_def.h is 115200 while U-boot default value and most documentation points to a value of 1500000.
This of course means that messages printed by ATF are not visible by default in this context.

The change from 1500000 to 115200 was introduced in 0c05748bdebfad9fa43a80962186438bb8fbce62,

with the following message

commit 0c05748bdebfad9fa43a80962186438bb8fbce62
Author: Caesar Wang <>
Date:   Tue Apr 19 20:42:17 2016 +0800

    rockchip: fixes for the required
    This patch has the following change for rk3399.
    * Set the uart to 115200 since the loader decide to set
      uart baud to 115200Hz. So the ATF also should set uart baud to 115200.

However, I'm not sure it this still applies.

I'll be happy to submit a patch to update the value if it is OK.

Event Timeline

wlozano0collabora triaged this task as Normal priority.Jun 3 2020, 4:29 PM
wlozano0collabora created this task.
tchebb added a subscriber: tchebb.Fri, Jun 19, 5:04 AM

I noticed this as well, and I was on the verge of submitting a patch until I looked into it further and decided that the current default is justifiable.

Rockchip officially lists the UART speed of the RK3399 as 1500000 on their wiki, and their proprietary idbloader (I believe) uses 15000000 too. This indicates that Rockchip expects the UART to run at 1500000. However, there's nothing in the silicon itself that requires this, as the chip's BootROM doesn't use UART at all. Nor is there a prescribed baud rate in the datasheet or TRM.

Furthermore, although both U-Boot's RK3399 configs (example) and the DTS files in Linux for boards that generally use U-Boot (example) use 1500000, coreboot and the DTS files for boards that generally use coreboot (Chromebooks, example) use 115200. This means there isn't a de facto standard for baud rate, since Google has decided to use 115200 on their RK3399 products.

Since 115200 is a standard baud rate and 1500000 is very whacky, I'm inclined to just leave the default as is. It shouldn't matter with a properly configured AP_BL2 anyway, since it should pass in a DTB with the correct baud rate via the platform param which will override the default. U-Boot doesn't currently do this, probably because, up until very recently, TF-A would fail to parse the DTB because it was too large and crash. Luckily, the TF-A size limit has now been increased and I've submitted a patch to make sure it gracefully degrades to the default baud rate instead of crashing should the DTB get too large again. So in a few months, it should be safe to re-enable platform param passing in U-Boot.

Thanks for your comments and clarification. I should have updated this ticket with the information provided in the mail list, in order to keep them in sync.

I agree with you and hope that in a few months we can re enable the option.