bcm63xx/atf/plat/rockchip/common, branch master

Merge changes from topic "rockchip-uart-fixes" into integration

2019-08-15T15:30:13Z

* changes: rockchip: rk3399: store actual debug uart information on suspend rockchip: move dt-coreboot uart distinction into param handling code rockchip: make uart baudrate configurable rockchip: px30: add uart5 as option for serial output

rockchip: move dt-coreboot uart distinction into param handling code

2019-08-09T07:40:19Z

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 Change-Id: I278d595d2aa6c6864187fc8979a9fbff9814feac

rockchip: make uart baudrate configurable

2019-08-05T15:52:06Z

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 Change-Id: I7412139c3df3073a1996eb508ec08642ec6af90d

rockchip: px30: add uart5 as option for serial output

2019-08-05T07:45:09Z

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 Change-Id: Ib88df7a55d761ee104d312c9953a13de3beba1c4

Switch AARCH32/AARCH64 to aarch64

2019-08-01T20:45:03Z

NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__. All common C compilers pre-define the same macros to signal which architecture the code is being compiled for: __arm__ for AArch32 (or earlier versions) and __aarch64__ for AArch64. There's no need for TF-A to define its own custom macros for this. In order to unify code with the export headers (which use __aarch64__ to avoid another dependency), let's deprecate the AARCH32 and AARCH64 macros and switch the code base over to the pre-defined standard macro. (Since it is somewhat unintuitive that __arm__ only means AArch32, let's standardize on only using __aarch64__.) Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200 Signed-off-by: Julius Werner

Replace ASSEMBLY with compiler-builtin ASSEMBLER

2019-08-01T20:14:12Z

NOTE: __ASSEMBLY__ macro is now deprecated in favor of __ASSEMBLER__. All common C compilers predefine a macro called __ASSEMBLER__ when preprocessing a .S file. There is no reason for TF-A to define it's own __ASSEMBLY__ macro for this purpose instead. To unify code with the export headers (which use __ASSEMBLER__ to avoid one extra dependency), let's deprecate __ASSEMBLY__ and switch the code base over to the predefined standard. Change-Id: Id7d0ec8cf330195da80499c68562b65cb5ab7417 Signed-off-by: Julius Werner

Merge changes I0d17ba6c,I540741d2,I9e6475ad,Ifd769320,I12c04a85, ... into integration

2019-07-25T09:04:21Z

* changes: plat/mediatek/mt81*: Use new bl31_params_parse() helper plat/rockchip: Use new bl31_params_parse_helper() Add helper to parse BL31 parameters (both versions) Factor out cross-BL API into export headers suitable for 3rd party code Use explicit-width data types in AAPCS parameter structs plat/rockchip: Switch to use new common BL aux parameter library Introduce lightweight BL platform parameter library

plat/rockchip: Use new bl31_params_parse_helper()

2019-07-24T18:04:03Z

The Rockchip platform is a prime candidate for switching to the new bl31_params_parse_helper(), so switch it over. This will allow BL2 implementations on this platform to transparently switch over to the version 2 parameter structure. Change-Id: I540741d2425c93f66c8697ce749a351eb2b3a7e8 Signed-off-by: Julius Werner

Factor out cross-BL API into export headers suitable for 3rd party code

2019-07-24T03:25:34Z

This patch adds a new include/export/ directory meant for inclusion in third-party code. This is useful for cases where third-party code needs to interact with TF-A interfaces and data structures (such as a custom BL2-implementation like coreboot handing off to BL31). Directly including headers from the TF-A repository avoids having to duplicate all these definitions (and risk them going stale), but with the current header structure this is not possible because handoff API definitions are too deeply intertwined with other TF code/headers and chain-include other headers that will not be available in the other environment. The new approach aims to solve this by separating only the parts that are really needed into these special headers that are self-contained and will not chain-include other (non-export) headers. TF-A code should never include them directly but should instead always include the respective wrapper header, which will include the required prerequisites (like ) before including the export header. Third-party code can include the export headers via its own wrappers that make sure the necessary definitions are available in whatever way that environment can provide them. Change-Id: Ifd769320ba51371439a8e5dd5b79c2516c3b43ab Signed-off-by: Julius Werner

plat/rockchip: Switch to use new common BL aux parameter library

2019-07-24T03:25:30Z

This patch changes all Rockchip platforms to use the new common BL aux parameter helpers. Since the parameter space is now cleanly split in generic and vendor-specific parameters and the COREBOOT_TABLE parameter is now generic, the parameter type number for that parameter has to change. Since it only affects coreboot which always builds TF as a submodule and includes its headers directly to get these constants, this should not cause any issues. In general, after this point, we should avoid changing already assigned parameter type numbers whenever possible. Change-Id: Ic99ddd1e91ff5e5fe212fa30c793a0b8394c9dad Signed-off-by: Julius Werner