| df5a9683 | 12-Dec-2019 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
rockchip: make miniloader ddr_parameter handling optional
Transfering the regions of ddr memory to additionally protect is very much specific to some rockchip internal first stage bootloader and doe
rockchip: make miniloader ddr_parameter handling optional
Transfering the regions of ddr memory to additionally protect is very much specific to some rockchip internal first stage bootloader and doesn't get used in either mainline uboot or even Rockchip's published vendor uboot sources.
This results in a big error ERROR: over or zero region, nr=0, max=10 getting emitted on every boot for most users and such a message coming from early firmware might actually confuse developers working with the system.
As this mechanism seems to be only be used by Rockchip's internal miniloader hide it behind a build conditional, so it doesn't confuse people too much.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Change-Id: I52c02decc60fd431ea78c7486cad5bac82bdbfbe
show more ...
|
| f55ef85e | 11-Oct-2019 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
rockchip: px30: cleanup securing of ddr regions
So far the px30-related ddr security was loading data for regions to secure from a pre-specified memory location and also setting region0 to secure th
rockchip: px30: cleanup securing of ddr regions
So far the px30-related ddr security was loading data for regions to secure from a pre-specified memory location and also setting region0 to secure the first megabyte of memory in hard-coded setting (top=0, end=0, meaning 1MB).
To make things more explicit and easier to read add a function doing the settings for specified memory areas, like other socs have and also add an assert to make sure any descriptor read from memory does not overlap the TZRAM security in region0 and TEE security in region1.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Change-Id: I78441875112bf66a62fde5f1789f4e52a78ef95f
show more ...
|
| 7f0b2e78 | 09-Oct-2019 |
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> |
rockchip: really use base+size for secure ddr regions
The calls to secure ddr regions on rk3288 and rk3399 use parameters of base and size - as it custom for specifying memory regions, but the funct
rockchip: really use base+size for secure ddr regions
The calls to secure ddr regions on rk3288 and rk3399 use parameters of base and size - as it custom for specifying memory regions, but the functions themself expect start and endpoints of the area.
This only works by chance for the TZRAM, as it starts a 0x0 and therefore its end location is the same as its size.
To not fall into a trap later on adapt the functions to really take base+size parameters.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Change-Id: Idb9fab38aa081f3335a4eca971e7b7f6757fbbab
show more ...
|
| 0aad563c | 19-Sep-2019 |
Kever Yang <kever.yang@rock-chips.com> |
rockchip: Update BL31_BASE to 0x40000
Rockchip platform is using the first 1MB of DRAM as secure ram space, and there is a vendor loader who loads and runs the BL31/BL32/BL33, this loader is usually
rockchip: Update BL31_BASE to 0x40000
Rockchip platform is using the first 1MB of DRAM as secure ram space, and there is a vendor loader who loads and runs the BL31/BL32/BL33, this loader is usually load by SoC BootRom to the start addres of DRAM, we need to reserve enough space for this loader so that it doesn't need to do the relocate when loading the BL31. eg. We use U-Boot SPL to load ATF BL31 and U-Boot proper as BL33, the SPL TEXT BASE is offset 0 of DRAM which is decide by Bootrom; if we update the BL31_BASE to offset 0x40000(256KB), then the 0~0x40000 should be enough for SPL and no need to do the relocate while the space size 0x10000(64KB) may not enough for SPL. After this update, the BL31 can use the rest 768KB of the first 1MB, which is also enough, and the loader who is using BL31 elf file can support this update without any change.
Change-Id: I66dc685594d77f10f9a49c3be015fd6729250ece Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
show more ...
|
| 0eb7fa91 | 05-Aug-2019 |
Heiko Stuebner <heiko@sntech.de> |
rockchip: rk3399: store actual debug uart information on suspend
The rk3399 suspend code saves and restores the debug uart settings, but right now always does this for the default uart. Right now th
rockchip: rk3399: store actual debug uart information on suspend
The rk3399 suspend code saves and restores the debug uart settings, but right now always does this for the default uart. Right now this works only by chance for the majority of rk3399 boards, which do not deviate from that default.
But both Coreboot as well as U-Boot-based platforms can actually use different uarts for their output, which can be configured from either devicetree or Coreboot-variables.
To fix this, just use the stored uart-base information instead of the default constant.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Change-Id: I1ea059d59a1126f6f8702315df7e620e632b686e
show more ...
|
| 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 ...
|
| 5f441a7b | 05-Aug-2019 |
Heiko Stuebner <heiko@sntech.de> |
rockchip: px30: add uart5 as option for serial output
The px30 mini-evb can use either uart2 (muxed with the sd-card pins) or uart5 via its pin header for serial output. Uart5 is especially useful w
rockchip: px30: add uart5 as option for serial output
The px30 mini-evb can use either uart2 (muxed with the sd-card pins) or uart5 via its pin header for serial output. Uart5 is especially useful when needing to boot from the sd-card, where uart2 obviously is not useable.
So add the uart5 constants and it as uart option for the serial-param handler.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Change-Id: Ib88df7a55d761ee104d312c9953a13de3beba1c4
show more ...
|
| f8aa5d7d | 29-Jul-2019 |
Ambroise Vincent <ambroise.vincent@arm.com> |
rockchip: px30: Use new bl31_params_parse functions
This change is needed for the platform to compile following the changes made in commits cbdc72b559ab and 3e02c7436cf4.
Change-Id: I3468dd27f3b4f3
rockchip: px30: Use new bl31_params_parse functions
This change is needed for the platform to compile following the changes made in commits cbdc72b559ab and 3e02c7436cf4.
Change-Id: I3468dd27f3b4f3095fb82f445d51cd8714311eb7 Signed-off-by: Ambroise Vincent <ambroise.vincent@arm.com>
show more ...
|