board/rdv1mc: initialize tzc400 controllers

A TZC400 controller is placed inline on DRAM channels and regulates
the secure and non-secure accesses to both secure and non-secure
regions of the DRAM m

board/rdv1mc: initialize tzc400 controllers

A TZC400 controller is placed inline on DRAM channels and regulates
the secure and non-secure accesses to both secure and non-secure
regions of the DRAM memory. Configure each of the TZC controllers
across the Chips.

For use by secure software, configure the first chip's trustzone
controller to protect the upper 16MB of the memory of the first DRAM
block for secure accesses only. The other regions are configured for
non-secure read write access. For all the remote chips, all the DRAM
regions are allowed for non-secure read and write access.

Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
Change-Id: I809f27eccadfc23ea0ef64e2fd87f95eb8f195c1

show more ...

plat/sgi: allow access to TZC controller on all chips

On a multi-chip platform, the boot CPU on the first chip programs the
TZC controllers on all the remote chips. Define a memory region map for
th

plat/sgi: allow access to TZC controller on all chips

On a multi-chip platform, the boot CPU on the first chip programs the
TZC controllers on all the remote chips. Define a memory region map for
the TZC controllers for all the remote chips and include it in the BL2
memory map table.

In addition to this, for SPM_MM enabled multi-chip platforms, increase
the number of mmap entries and xlat table counts for EL3 execution
context as well because the shared RAM regions and GIC address space of
remote chips are accessed.

Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
Change-Id: I6f0b5fd22f9f28046451e382eef7f1f9258d88f7

show more ...

plat/sgi: define memory regions for multi-chip platforms

For multi-chip platforms, add a macro to define the memory regions on
chip numbers >1 and its associated access permissions. These memory
reg

plat/sgi: define memory regions for multi-chip platforms

For multi-chip platforms, add a macro to define the memory regions on
chip numbers >1 and its associated access permissions. These memory
regions are marked with non-secure access.

Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
Change-Id: If3d6180fd8ea61f45147c39d3140d694abf06617

show more ...

plat/sgi: allow access to nor2 flash and system registers from s-el0

Allow the access of system registers and nor2 flash memory region
from s-el0. This allows the secure parititions residing at s-el

plat/sgi: allow access to nor2 flash and system registers from s-el0

Allow the access of system registers and nor2 flash memory region
from s-el0. This allows the secure parititions residing at s-el0
to access these memory regions.

Signed-off-by: Thomas Abraham <thomas.abraham@arm.com>
Change-Id: I3887a86770de806323fbde0d20fdc96eec6e0c3c

show more ...

plat/sgi: define default list of memory regions for dmc620 tzc

Define a default DMC-620 TZC memory region configuration and use it to
specify the TZC memory regions on sgi575, rdn1edge and rde1edge

plat/sgi: define default list of memory regions for dmc620 tzc

Define a default DMC-620 TZC memory region configuration and use it to
specify the TZC memory regions on sgi575, rdn1edge and rde1edge
platforms. The default DMC-620 TZC memory regions are defined
considering the support for secure paritition as well.

Signed-off-by: Thomas Abraham <thomas.abraham@arm.com>
Change-Id: Iedee3e57d0d3de5b65321444da51ec990d3702db

show more ...

plat/sgi: improve macros defining cper buffer memory region

Remove the 'ARM_' prefix from the macros defining the CPER buffer memory
and replace it with 'CSS_SGI_' prefix. These macros are applicabl

plat/sgi: improve macros defining cper buffer memory region

Remove the 'ARM_' prefix from the macros defining the CPER buffer memory
and replace it with 'CSS_SGI_' prefix. These macros are applicable only
for platforms supported within plat/sgi. In addition to this, ensure
that these macros are defined only if the RAS_EXTENSION build option is
enabled.

Signed-off-by: Thomas Abraham <thomas.abraham@arm.com>
Change-Id: I44df42cded18d9d3a4cb13e5c990e9ab3194daee

show more ...

plat/sgi: refactor DMC-620 error handling SMC function id

The macros defining the SMC function ids for DMC-620 error handling are
listed in the sgi_base_platform_def.h header file. But these macros

plat/sgi: refactor DMC-620 error handling SMC function id

The macros defining the SMC function ids for DMC-620 error handling are
listed in the sgi_base_platform_def.h header file. But these macros are
not applicable for all platforms supported under plat/sgi. So move these
macro definitions to sgi_ras.c file in which these are consumed. While
at it, remove the AArch32 and error injection function ids as these are
unused.

Signed-off-by: Thomas Abraham <thomas.abraham@arm.com>
Change-Id: I249b54bf4c1b1694188a1e3b297345b942f16bc9

show more ...

plat/sgi: refactor SDEI specific macros

The macros specific to SDEI defined in the sgi_base_platform_def.h are
not applicable for all the platforms supported by plat/sgi. So refactor
the SDEI specif

plat/sgi: refactor SDEI specific macros

The macros specific to SDEI defined in the sgi_base_platform_def.h are
not applicable for all the platforms supported by plat/sgi. So refactor
the SDEI specific macros into a new header file and include this file on
only on platforms it is applicable on.

Signed-off-by: Thomas Abraham <thomas.abraham@arm.com>
Change-Id: I0cb7125334f02a21cae1837cdfd765c16ab50bf5

show more ...

Merge "driver: brcm: add i2c driver" into integration

Merge "doc: update maintainer list for Arm platforms" into integration

Merge "doc: re-format maintainer.rst file rendering" into integration

driver: brcm: add i2c driver

Broadcom I2C controller driver. Follwoing API's are supported:-
- i2c_init() Intialize ethe I2C controller
- i2c_probe()
- i2c_set_bus_speed() Set the I2C bus speed
- i2

driver: brcm: add i2c driver

Broadcom I2C controller driver. Follwoing API's are supported:-
- i2c_init() Intialize ethe I2C controller
- i2c_probe()
- i2c_set_bus_speed() Set the I2C bus speed
- i2c_get_bus_speed() Get the current bus speed
- i2c_recv_byte() Receive one byte of data.
- i2c_send_byte() Send one byteof data
- i2c_read_byte() Read single byte of data
- i2c_read() Read multiple bytes of data
- i2c_write_byte Write single byte of data
- i2c_write() Write multiple bytes of data

This driver is verified by reading the DDR SPD data.

Signed-off-by: Bharat Gooty <bharat.gooty@broadcom.com>
Change-Id: I2d7fe53950e8b12fab19d0293020523ff8b74e13

show more ...

allwinner: H616: Add reserved-memory node to DT

When the BL31 for the Allwinner H616 runs in DRAM, we need to make sure
we tell the non-secure world about the memory region it uses.

Add a reserved-

allwinner: H616: Add reserved-memory node to DT

When the BL31 for the Allwinner H616 runs in DRAM, we need to make sure
we tell the non-secure world about the memory region it uses.

Add a reserved-memory node to the DT, which covers the area that BL31
could occupy. The "no-map" property will prevent OSes from mapping
the area, so there would be no speculative accesses.

Change-Id: I808f3e1a8089da53bbe4fc6435a808e9159831e1
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

plat: ti: k3: board: Let explicitly map our SEC_SRAM_BASE to 0x0

ENABLE_PIE (position independent executable) is default on K3
platform to handle variant RAM configurations in the system. This,
unfo

plat: ti: k3: board: Let explicitly map our SEC_SRAM_BASE to 0x0

ENABLE_PIE (position independent executable) is default on K3
platform to handle variant RAM configurations in the system. This,
unfortunately does cause confusion while reading the code, so, lets
make things explicit by selecting 0x0 as the "SEC_SRAM_BASE" out of
which we compute the BL31_BASE depending on usage.

Lets also document a warning while at it to help folks copying code
over to a custom K3 platform and optimizing size by disabling PIE to
modify the defaults.

Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I8e67a9210e907e266ff6a78ba4d02e3259bb2b21

show more ...

plat: ti: k3: board: Lets cast our macros

Lets cast our macros to the right types and reduce a few MISRA
warnings.

Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I0dc06072713fe7c9440eca063509

plat: ti: k3: board: Lets cast our macros

Lets cast our macros to the right types and reduce a few MISRA
warnings.

Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I0dc06072713fe7c9440eca0635094c5f3ceb7f1c

show more ...

plat: ti: k3: common: bl31_setup: Use BL31_SIZE instead of computing

We compute BL31_END - BL31_START on the fly, which is basically
BL31_SIZE. Lets just use the BL31_SIZE directly so that we dont
c

plat: ti: k3: common: bl31_setup: Use BL31_SIZE instead of computing

We compute BL31_END - BL31_START on the fly, which is basically
BL31_SIZE. Lets just use the BL31_SIZE directly so that we dont
complicate PIE relocations when actual address is +ve and -ve offsets
relative to link address.

Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I5e14906381d2d059163800d39798eb39c42da4ec

show more ...

plat: ti: k3: platform_def.h: Define the correct number of max table entries

Since we are using static xlat tables, we need to account for exact
count of table entries we are actually using.
periphe

plat: ti: k3: platform_def.h: Define the correct number of max table entries

Since we are using static xlat tables, we need to account for exact
count of table entries we are actually using.
peripherals usart, gic, gtc, sec_proxy_rt, scfg and data account for 6 entries
and are constant, however, we also need to account for:
bl31 full range, codebase, ro_data as additional 3 region

With USE_COHERENT_MEM we do add in 1 extra region as well.

This implies that we will have upto 9 or 10 regions based on
USE_COHERENT_MEM usage. Vs we currently define 8 regions.

This gets exposed with DEBUG=1 and assert checks trigger, which for some
reason completely escaped testing previously.

ASSERT: lib/xlat_tables_v2/xlat_tables_core.c:97
BACKTRACE: START: assert

Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I962cdfc779b4eb3b914fe1c46023d50bc289e6bc

show more ...

plat: ti: k3: board: lite: Increase SRAM size to account for additional table

We actually have additional table entries than what we accounted for in
our size. MAX_XLAT_TABLES is 8, but really we co

plat: ti: k3: board: lite: Increase SRAM size to account for additional table

We actually have additional table entries than what we accounted for in
our size. MAX_XLAT_TABLES is 8, but really we could be using upto 10
depending on the platform. So, we need an extra 8K space in.

This gets exposed with DEBUG=1 and assert checks trigger, which for some
reason completely escaped testing previously.

ASSERT: lib/xlat_tables_v2/xlat_tables_core.c:97
BACKTRACE: START: assert

Signed-off-by: Nishanth Menon <nm@ti.com>
Change-Id: I5c5d04440ef1fccfaf2317066f3abbc0ec645903

show more ...

allwinner: Add Allwinner H616 SoC support

The new Allwinner H616 SoC lacks the management controller and the secure
SRAM A2, so we need to tweak the memory map quite substantially:
We run BL31 in DR

allwinner: Add Allwinner H616 SoC support

The new Allwinner H616 SoC lacks the management controller and the secure
SRAM A2, so we need to tweak the memory map quite substantially:
We run BL31 in DRAM. Since the DRAM starts at 1GB, we cannot use our
compressed virtual address space (max 256MB) anymore, so we revert to
the full 32bit VA space and use a flat mapping throughout all of it.

The missing controller also means we need to always use the native PSCI
ops, using the CPUIDLE hardware, as SCPI and suspend depend on the ARISC.

Change-Id: I77169b452cb7f5dc2ef734f3fc6e5d931749141d
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

allwinner: Add H616 SoC ID

Change-Id: I557fd05401e24204952135cf3ca26479a43ad1f1
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

allwinner: Express memmap more dynamically

In preparation for changing the memory map, express the locations of the
various code and data pieces more dynamically, allowing SoCs to override
the memma

allwinner: Express memmap more dynamically

In preparation for changing the memory map, express the locations of the
various code and data pieces more dynamically, allowing SoCs to override
the memmap later.
Also prepare for the SCP region to become optional.

No functional change.

Change-Id: I7ac01e309be2f23bde2ac2050d8d5b5e3d6efea2
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

allwinner: Move sunxi_cpu_power_off_self() into platforms

The code to power the current core off when SCPI is not available is now
different for the two supported SoC families.
To make adding new pl

allwinner: Move sunxi_cpu_power_off_self() into platforms

The code to power the current core off when SCPI is not available is now
different for the two supported SoC families.
To make adding new platforms easier, move sunxi_cpu_power_off_self()
into the SoC directory, so we don't need to carry definitions for both
methods for all SoCs.

On the H6 we just need to trigger the CPUIDLE hardware, so can get rid
of all the code to program the ARISC, which is now only needed for the
A64 version.

Change-Id: Id2a1ac7dcb375e2fd021b441575ce86b4d7edf2c
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

allwinner: Move SEPARATE_NOBITS_REGION to platforms

For the existing SoCs we support, we use SEPARATE_NOBITS_REGION, to move
some parts of the data into separate memory regions (to save on the SRAM

allwinner: Move SEPARATE_NOBITS_REGION to platforms

For the existing SoCs we support, we use SEPARATE_NOBITS_REGION, to move
some parts of the data into separate memory regions (to save on the SRAM
A2 we are loaded into).
For the upcoming H616 platform this is of no concern (we run in DRAM),
so make this flag a platform choice instead.

Change-Id: Ic01d49578c6274660f8f112bd23680d3eca3be7a
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

doc: allwinner: Reorder sections, document memory mapping

Update the Allwinner platform documentation.
Reorder the section, to have the build instructions first, followed by
hints about the installa

doc: allwinner: Reorder sections, document memory mapping

Update the Allwinner platform documentation.
Reorder the section, to have the build instructions first, followed by
hints about the installation.

Add some ASCII art about the layout of our virtual memory map, which
uses a non-trivial condensed virtual address space.

Change-Id: Iaaa79b4366012394e15e4c1b26c212b5efb6ed6a
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

Merge "allwinner: Use CPUIDLE hardware when available" into integration