On 6 Jun 2020, at 17:52, Heiko Stübner via TF-A tf-a@lists.trustedfirmware.org wrote:
Hi Walter,
Am Freitag, 5. Juni 2020, 22:45:25 CEST schrieb Walter Lozano via TF-A:
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 for console.
console baudrate on rk3399 differ a lot between boards. There are a number using the 1.5MHz and another big number using 115200 (including but not limited to the ChromeOS devices from the Gru line).
Hence we have the code that selects the actual baudrate from the devicetree attached by u-boot when calling TF-A.
So I guess it should stay as it is right now.
On the RK3399 there are currently a couple of roadblocks preventing this selection of the baudrate from the devicetree from working. Firstly in U-Boot, SPL_ATF_NO_PLATFORM_PARAM is forced on when selecting ROCKCHIP_RK3399 in Kconfig [1]. Secondly in TF-A the 64K buffer used to store the passed devicetree isn't large enough to fit some of the RK3399 device tree blobs, as I found when removing SPL_ATF_NO_PLATFORM_PARAM from U-Boot. I guess the issue in TF-A needs to be fixed first before passing the platform parameter can be enabled in U-Boot, I've submitted a TF-A patch to increase the buffer size [2].
[1]: https://gitlab.denx.de/u-boot/u-boot/-/blob/61853a7ac7e167d90899ec4e99d2e07d... [2]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4512
Heiko
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,
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c057...
with the following message
commit 0c05748bdebfad9fa43a80962186438bb8fbce62 Author: Caesar Wang wxt@rock-chips.com 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.
Regards,
Walter
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Heiko/Hugh
On 8/6/20 19:25, Hugh Cole-Baker wrote:
On 6 Jun 2020, at 17:52, Heiko Stübner via TF-A tf-a@lists.trustedfirmware.org wrote:
Hi Walter,
Am Freitag, 5. Juni 2020, 22:45:25 CEST schrieb Walter Lozano via TF-A:
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 for console.
console baudrate on rk3399 differ a lot between boards. There are a number using the 1.5MHz and another big number using 115200 (including but not limited to the ChromeOS devices from the Gru line).
Hence we have the code that selects the actual baudrate from the devicetree attached by u-boot when calling TF-A.
So I guess it should stay as it is right now.
Thanks for clarifying this.
On the RK3399 there are currently a couple of roadblocks preventing this selection of the baudrate from the devicetree from working. Firstly in U-Boot, SPL_ATF_NO_PLATFORM_PARAM is forced on when selecting ROCKCHIP_RK3399 in Kconfig [1]. Secondly in TF-A the 64K buffer used to store the passed devicetree isn't large enough to fit some of the RK3399 device tree blobs, as I found when removing SPL_ATF_NO_PLATFORM_PARAM from U-Boot. I guess the issue in TF-A needs to be fixed first before passing the platform parameter can be enabled in U-Boot, I've submitted a TF-A patch to increase the buffer size [2].
Thanks for pointing to the real issue, I'm glad that you have already submitted a patch to fix it. In relation to this, we have discussion in the mail list [1] about some ways to reduce the devicetree U-Boot uses, which will be beneficial also in this context.
[1] https://patchwork.ozlabs.org/project/uboot/patch/20200525093539.1.Ibf2d19439...
Regards,
Walter
Heiko
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,
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0c057...
with the following message
commit 0c05748bdebfad9fa43a80962186438bb8fbce62 Author: Caesar Wang wxt@rock-chips.com 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.
Regards,
Walter
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
tf-a@lists.trustedfirmware.org
-
Hugh Cole-Baker -
Walter Lozano