| dd4a0d16 | 05-Aug-2019 |
Heiko Stuebner <heiko@sntech.de> |
rockchip: move dt-coreboot uart distinction into param handling code
Rockchip platforms can be booted from either u-boot or coreboot.
So far the Coreboot-console was initizalized from a coreboot da
rockchip: move dt-coreboot uart distinction into param handling code
Rockchip platforms can be booted from either u-boot or coreboot.
So far the Coreboot-console was initizalized from a coreboot data struct in the early_param2 callbacks and dt-based consoles with data from the rockchip_get_uart_* functions.
But later code may also need this console information for example for special suspend handling. To make this easy follow a suggestion from Julius Werner and move the coreboot<->dt distinction into the rockchip_get_uart_* functions, thus making correct data about the used uart available to all Rockchip platform code at all times.
This includes a new rockchip_get_uart_clock as well, because while the dt-platforms right now always just default the rate defined in a constant Coreboot provides its own field for the clock rate and we don't want to loose that information for the console init. Similarly the rk_uart_* variables should move into the non-Coreboot code, to prevent them from being marked as unused, which also requires the rk_get_uart_* functions to move below the actual dt-parsing.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Change-Id: I278d595d2aa6c6864187fc8979a9fbff9814feac
show more ...
|
| 30970e0f | 05-Aug-2019 |
Heiko Stuebner <heiko@sntech.de> |
rockchip: make uart baudrate configurable
A previous patch already allowed to configure the uart output from the devicetree, but on Rockchip platforms we also have the issue of different vendors usi
rockchip: make uart baudrate configurable
A previous patch already allowed to configure the uart output from the devicetree, but on Rockchip platforms we also have the issue of different vendors using different baudrates for their uarts.
For example, rk3399 has a default baudrate of 115200 which is true for ChromeOS-devices and boards from Theobroma-Systems, while all the boards using the vendor boot chain actually use a baudrate of 1500000.
Similarly the newly added px30 has a default of said 1500000 but some boards may want to use the more widely used 115200.
The devicetree stdout-path node already contains the desired baudrate, so add simple code to parse it from there and override the default, which stays unchanged.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Change-Id: I7412139c3df3073a1996eb508ec08642ec6af90d
show more ...
|
| 220c33a2 | 19-Apr-2019 |
Christoph Müllner <christophm30@gmail.com> |
rockchip: Allow console device to be set by DTB.
Currently the compile-time constant PLAT_RK_UART_BASE defines which UART is used as console device. E.g. on RK3399 it is set to UART2. That means, th
rockchip: Allow console device to be set by DTB.
Currently the compile-time constant PLAT_RK_UART_BASE defines which UART is used as console device. E.g. on RK3399 it is set to UART2. That means, that a single bl31 image can not be used for two boards, which just differ on the UART console.
This patch addresses this limitation by parsing the "stdout-path" property from the "chosen" node in the DTB. The expected property string is expected to have the form "serialN:XXX", with N being either 0, 1, 2, 3 or 4. When the property is found, it will be used to override PLAT_RK_UART_BASE.
Tested on RK3399-Q7, with a stdout-path of "serial0:115200n8".
Signed-off-by: Christoph Müllner <christophm30@gmail.com> Change-Id: Iafe1320e77ab006c121f8d52745d54cef68a48c7
show more ...
|
| 82e18f89 | 14-Mar-2019 |
Heiko Stuebner <heiko@sntech.de> |
rockchip: add common aarch32 support
There are a number or ARMv7 Rockchip SoCs that are very similar in their bringup routines to the existing arm64 SoCs, so there is quite a high commonality possib
rockchip: add common aarch32 support
There are a number or ARMv7 Rockchip SoCs that are very similar in their bringup routines to the existing arm64 SoCs, so there is quite a high commonality possible here.
Things like virtualization also need psci and hyp-mode and instead of trying to cram this into bootloaders like u-boot, barebox or coreboot (all used in the field), re-use the existing infrastructure in TF-A for this (both Rockchip plat support and armv7 support in general).
So add core support for aarch32 Rockchip SoCs, with actual soc support following in a separate patch.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Change-Id: I298453985b5d8434934fc0c742fda719e994ba0b
show more ...
|
| 3b5b888d | 07-Mar-2019 |
Heiko Stuebner <heiko@sntech.de> |
rockchip: Allow socs with undefined wfe check bits
Some older socs like the rk3288 do not have the necessary registers to check the wfi/wfe state of the cpu cores. Allow this case an "just" do an ad
rockchip: Allow socs with undefined wfe check bits
Some older socs like the rk3288 do not have the necessary registers to check the wfi/wfe state of the cpu cores. Allow this case an "just" do an additional delay similar to how the Linux kernel handles smp right now.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Change-Id: I0f67af388b06b8bfb4a9bac411b4900ac266a77a
show more ...
|