andrius
/
arm-trusted-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
arm-trusted-firmware/plat/arm/board/juno/juno_security.c

76 lines
3.1 KiB
C
Raw Normal View History

Juno: Use TZC-400 driver calls This patch replaces direct accesses to the TZC-400 registers by the appropiate calls to the generic driver available in the Trusted Firmware in order to initialize the TrustZone Controller. Functions related to the initialization of the secure memory, like the TZC-400 configuration, have been moved to a new file 'plat_security.c'. This reorganization makes easier to set up the secure memory from any BL stage. TZC-400 initialization has been moved from BL1 to BL2 because BL1 does not access the non-secure memory. It is BL2's responsibility to enable and configure the TZC-400 before loading the next BL images. In Juno, BL3-0 initializes some of the platform peripherals, like the DDR controller. Thus, BL3-0 must be loaded before configuring the TrustZone Controller. As a consequence, the IO layer initialization has been moved to early platform initialization. Fixes ARM-software/tf-issues#234 Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
2014-09-04 14:43:09 +01:00
/*
Migrate Juno port to use common code Major update to the Juno platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also move the ARM SoC specific security setup (i.e. NIC-400 and PCIe initialization) from BL1 to `plat_arm_security_setup()` in BL2, where the other security setup is done. Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
2015-03-19 19:22:44 +00:00
* Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.
Juno: Use TZC-400 driver calls This patch replaces direct accesses to the TZC-400 registers by the appropiate calls to the generic driver available in the Trusted Firmware in order to initialize the TrustZone Controller. Functions related to the initialization of the secure memory, like the TZC-400 configuration, have been moved to a new file 'plat_security.c'. This reorganization makes easier to set up the secure memory from any BL stage. TZC-400 initialization has been moved from BL1 to BL2 because BL1 does not access the non-secure memory. It is BL2's responsibility to enable and configure the TZC-400 before loading the next BL images. In Juno, BL3-0 initializes some of the platform peripherals, like the DDR controller. Thus, BL3-0 must be loaded before configuring the TrustZone Controller. As a consequence, the IO layer initialization has been moved to early platform initialization. Fixes ARM-software/tf-issues#234 Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
2014-09-04 14:43:09 +01:00
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* Neither the name of ARM nor the names of its contributors may be used
* to endorse or promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
Juno: clear DMA-330 SMMU security state By default the SMMU for the DMA-330 is configured to mark some stream IDs as always belonging to the Secure world. As a result, if EL1 software turns the SMMU on, certain Non-Secure accesses get rewritten as Secure, making them bypass translation and access Secure physical addresses directly. Since the current Juno board firmware configures the DMA-330 hardware as Non-Secure, rewrite the SMMU's default SSD table as well to prevent any unexpected behaviour in EL1. Change-Id: Iaa81d883eecf28d80eb182b9ce475684bf9c718c
2015-01-09 14:30:58 +00:00
#include <mmio.h>
Separate CSS security setup from SOC security setup Currently, on ARM platforms(ex. Juno) non-secure access to specific peripheral regions, config registers which are inside and outside CSS is done in the soc_css_security_setup(). This patch separates the CSS security setup from the SOC security setup in the css_security_setup(). The CSS security setup involves programming of the internal NIC to provide access to regions inside the CSS. This is needed only in Juno, hence Juno implements it in its board files as css_init_nic400(). Change-Id: I95a1fb9f13f9b18fa8e915eb4ae2f15264f1b060
2015-08-03 23:58:19 +01:00
#include <nic_400.h>
Migrate Juno port to use common code Major update to the Juno platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also move the ARM SoC specific security setup (i.e. NIC-400 and PCIe initialization) from BL1 to `plat_arm_security_setup()` in BL2, where the other security setup is done. Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
2015-03-19 19:22:44 +00:00
#include <plat_arm.h>
#include <soc_css.h>
Juno: Use TZC-400 driver calls This patch replaces direct accesses to the TZC-400 registers by the appropiate calls to the generic driver available in the Trusted Firmware in order to initialize the TrustZone Controller. Functions related to the initialization of the secure memory, like the TZC-400 configuration, have been moved to a new file 'plat_security.c'. This reorganization makes easier to set up the secure memory from any BL stage. TZC-400 initialization has been moved from BL1 to BL2 because BL1 does not access the non-secure memory. It is BL2's responsibility to enable and configure the TZC-400 before loading the next BL images. In Juno, BL3-0 initializes some of the platform peripherals, like the DDR controller. Thus, BL3-0 must be loaded before configuring the TrustZone Controller. As a consequence, the IO layer initialization has been moved to early platform initialization. Fixes ARM-software/tf-issues#234 Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
2014-09-04 14:43:09 +01:00
#include "juno_def.h"
Juno: clear DMA-330 SMMU security state By default the SMMU for the DMA-330 is configured to mark some stream IDs as always belonging to the Secure world. As a result, if EL1 software turns the SMMU on, certain Non-Secure accesses get rewritten as Secure, making them bypass translation and access Secure physical addresses directly. Since the current Juno board firmware configures the DMA-330 hardware as Non-Secure, rewrite the SMMU's default SSD table as well to prevent any unexpected behaviour in EL1. Change-Id: Iaa81d883eecf28d80eb182b9ce475684bf9c718c
2015-01-09 14:30:58 +00:00
/*******************************************************************************
* Set up the MMU-401 SSD tables. The power-on configuration has all stream IDs
* assigned to Non-Secure except some for the DMA-330. Assign those back to the
* Non-Secure world as well, otherwise EL1 may end up erroneously generating
* (untranslated) Secure transactions if it turns the SMMU on.
******************************************************************************/
static void init_mmu401(void)
{
uint32_t reg = mmio_read_32(MMU401_DMA330_BASE + MMU401_SSD_OFFSET);
reg |= 0x1FF;
mmio_write_32(MMU401_DMA330_BASE + MMU401_SSD_OFFSET, reg);
}
Separate CSS security setup from SOC security setup Currently, on ARM platforms(ex. Juno) non-secure access to specific peripheral regions, config registers which are inside and outside CSS is done in the soc_css_security_setup(). This patch separates the CSS security setup from the SOC security setup in the css_security_setup(). The CSS security setup involves programming of the internal NIC to provide access to regions inside the CSS. This is needed only in Juno, hence Juno implements it in its board files as css_init_nic400(). Change-Id: I95a1fb9f13f9b18fa8e915eb4ae2f15264f1b060
2015-08-03 23:58:19 +01:00
/*******************************************************************************
* Program CSS-NIC400 to allow non-secure access to some CSS regions.
******************************************************************************/
static void css_init_nic400(void)
{
/* Note: This is the NIC-400 device on the CSS */
mmio_write_32(PLAT_SOC_CSS_NIC400_BASE +
NIC400_ADDR_CTRL_SECURITY_REG(CSS_NIC400_SLAVE_BOOTSECURE),
~0);
}
Juno: Use TZC-400 driver calls This patch replaces direct accesses to the TZC-400 registers by the appropiate calls to the generic driver available in the Trusted Firmware in order to initialize the TrustZone Controller. Functions related to the initialization of the secure memory, like the TZC-400 configuration, have been moved to a new file 'plat_security.c'. This reorganization makes easier to set up the secure memory from any BL stage. TZC-400 initialization has been moved from BL1 to BL2 because BL1 does not access the non-secure memory. It is BL2's responsibility to enable and configure the TZC-400 before loading the next BL images. In Juno, BL3-0 initializes some of the platform peripherals, like the DDR controller. Thus, BL3-0 must be loaded before configuring the TrustZone Controller. As a consequence, the IO layer initialization has been moved to early platform initialization. Fixes ARM-software/tf-issues#234 Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
2014-09-04 14:43:09 +01:00
/*******************************************************************************
Migrate Juno port to use common code Major update to the Juno platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also move the ARM SoC specific security setup (i.e. NIC-400 and PCIe initialization) from BL1 to `plat_arm_security_setup()` in BL2, where the other security setup is done. Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
2015-03-19 19:22:44 +00:00
* Initialize the secure environment.
Juno: Use TZC-400 driver calls This patch replaces direct accesses to the TZC-400 registers by the appropiate calls to the generic driver available in the Trusted Firmware in order to initialize the TrustZone Controller. Functions related to the initialization of the secure memory, like the TZC-400 configuration, have been moved to a new file 'plat_security.c'. This reorganization makes easier to set up the secure memory from any BL stage. TZC-400 initialization has been moved from BL1 to BL2 because BL1 does not access the non-secure memory. It is BL2's responsibility to enable and configure the TZC-400 before loading the next BL images. In Juno, BL3-0 initializes some of the platform peripherals, like the DDR controller. Thus, BL3-0 must be loaded before configuring the TrustZone Controller. As a consequence, the IO layer initialization has been moved to early platform initialization. Fixes ARM-software/tf-issues#234 Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
2014-09-04 14:43:09 +01:00
******************************************************************************/
Migrate Juno port to use common code Major update to the Juno platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also move the ARM SoC specific security setup (i.e. NIC-400 and PCIe initialization) from BL1 to `plat_arm_security_setup()` in BL2, where the other security setup is done. Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
2015-03-19 19:22:44 +00:00
void plat_arm_security_setup(void)
Juno: Use TZC-400 driver calls This patch replaces direct accesses to the TZC-400 registers by the appropiate calls to the generic driver available in the Trusted Firmware in order to initialize the TrustZone Controller. Functions related to the initialization of the secure memory, like the TZC-400 configuration, have been moved to a new file 'plat_security.c'. This reorganization makes easier to set up the secure memory from any BL stage. TZC-400 initialization has been moved from BL1 to BL2 because BL1 does not access the non-secure memory. It is BL2's responsibility to enable and configure the TZC-400 before loading the next BL images. In Juno, BL3-0 initializes some of the platform peripherals, like the DDR controller. Thus, BL3-0 must be loaded before configuring the TrustZone Controller. As a consequence, the IO layer initialization has been moved to early platform initialization. Fixes ARM-software/tf-issues#234 Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
2014-09-04 14:43:09 +01:00
{
/* Initialize the TrustZone Controller */
Migrate ARM standard platforms to the refactored TZC driver This patch migrates ARM Standard platforms to the refactored TZC driver. Change-Id: I2a2f60b645f73e14d8f416740c4551cec87cb1fb
2016-02-26 14:23:19 +00:00
arm_tzc400_setup();
Separate CSS security setup from SOC security setup Currently, on ARM platforms(ex. Juno) non-secure access to specific peripheral regions, config registers which are inside and outside CSS is done in the soc_css_security_setup(). This patch separates the CSS security setup from the SOC security setup in the css_security_setup(). The CSS security setup involves programming of the internal NIC to provide access to regions inside the CSS. This is needed only in Juno, hence Juno implements it in its board files as css_init_nic400(). Change-Id: I95a1fb9f13f9b18fa8e915eb4ae2f15264f1b060
2015-08-03 23:58:19 +01:00
/* Do ARM CSS internal NIC setup */
css_init_nic400();
Migrate Juno port to use common code Major update to the Juno platform port to use the common platform code in (include/)plat/arm/* and (include/)plat/common/*. This mainly consists of removing duplicated code but also introduces some small behavioural changes where there was unnecessary variation between the FVP and Juno ports. See earlier commit titled `Add common ARM and CSS platform code` for details. Also move the ARM SoC specific security setup (i.e. NIC-400 and PCIe initialization) from BL1 to `plat_arm_security_setup()` in BL2, where the other security setup is done. Change-Id: Ic9fe01bae8ed382bfb04fc5839a4cfff332eb124
2015-03-19 19:22:44 +00:00
/* Do ARM CSS SoC security setup */
soc_css_security_setup();
Juno: clear DMA-330 SMMU security state By default the SMMU for the DMA-330 is configured to mark some stream IDs as always belonging to the Secure world. As a result, if EL1 software turns the SMMU on, certain Non-Secure accesses get rewritten as Secure, making them bypass translation and access Secure physical addresses directly. Since the current Juno board firmware configures the DMA-330 hardware as Non-Secure, rewrite the SMMU's default SSD table as well to prevent any unexpected behaviour in EL1. Change-Id: Iaa81d883eecf28d80eb182b9ce475684bf9c718c
2015-01-09 14:30:58 +00:00
/* Initialize the SMMU SSD tables*/
init_mmu401();
Juno: Use TZC-400 driver calls This patch replaces direct accesses to the TZC-400 registers by the appropiate calls to the generic driver available in the Trusted Firmware in order to initialize the TrustZone Controller. Functions related to the initialization of the secure memory, like the TZC-400 configuration, have been moved to a new file 'plat_security.c'. This reorganization makes easier to set up the secure memory from any BL stage. TZC-400 initialization has been moved from BL1 to BL2 because BL1 does not access the non-secure memory. It is BL2's responsibility to enable and configure the TZC-400 before loading the next BL images. In Juno, BL3-0 initializes some of the platform peripherals, like the DDR controller. Thus, BL3-0 must be loaded before configuring the TrustZone Controller. As a consequence, the IO layer initialization has been moved to early platform initialization. Fixes ARM-software/tf-issues#234 Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
2014-09-04 14:43:09 +01:00
}