- 29 Apr, 2021 1 commit
-
-
Manish V Badarkhe authored
Added GPT parser support in BL2 for Arm platforms to get the entry address and length of the FIP in the GPT image. Also, increased BL2 maximum size for FVP platform to successfully compile ROM-enabled build with this change. Verified this change using a patch: https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/9654 Change-Id: Ie8026db054966653b739a82d9ba106d283f534d0 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
-
- 28 Apr, 2021 1 commit
-
-
Manish V Badarkhe authored
Replaced PLAT_ARM_FIP_BASE and PLAT_ARM_FIP_MAX_SIZE macro with a generic name PLAT_ARM_FLASH_IMAGE_BASE and PLAT_ARM_FLASH_IMAGE_MAX_SIZE so that these macros can be reused in the subsequent GPT based support changes. Change-Id: I88fdbd53e1966578af4f1e8e9d5fef42c27b1173 Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
-
- 19 Feb, 2020 1 commit
-
-
Suyash Pathak authored
The base address for second DRAM varies across different platforms. So allow platforms to define second DRAM by moving Juno/SGM-775 specific definition of second DRAM base address to Juno/SGM-775 board definition respectively, SGI/RD specific definition of DRAM 2 base address to SGI board definition. Change-Id: I0ecd3a2bd600b6c7019c7f06f8c452952bd07cae Signed-off-by: Suyash Pathak <suyash.pathak@arm.com>
-
- 01 Aug, 2019 1 commit
-
-
Julius Werner authored
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 <jwerner@chromium.org>
-
- 15 May, 2019 1 commit
-
-
Sami Mujawar authored
The default DRAM2 base address for Arm platforms is 0x880000000. However, on some platforms the firmware may want to move the start address to a different value. To support this introduce PLAT_ARM_DRAM2_BASE that defaults to 0x880000000; but can be overridden by a platform (e.g. in platform_def.h). Change-Id: I0d81195e06070bc98f376444b48ada2db1666e28 Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
-
- 18 Feb, 2019 1 commit
-
-
Usama Arif authored
The variable is renamed to PLAT_ARM_RUN_UART as the UART is used outside BL31 as well. Change-Id: I00e3639dfb2001758b7d24548c11236c6335f64a Signed-off-by: Usama Arif <usama.arif@arm.com>
-
- 25 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
Use full include paths like it is done for common includes. This cleanup was started in commit d40e0e08283a ("Sanitise includes across codebase"), but it only cleaned common files and drivers. This patch does the same to Arm platforms. Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 04 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca339 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 08 Nov, 2018 1 commit
-
-
Antonio Nino Diaz authored
All identifiers, regardless of use, that start with two underscores are reserved. This means they can't be used in header guards. The style that this project is now to use the full name of the file in capital letters followed by 'H'. For example, for a file called "uart_example.h", the header guard is UART_EXAMPLE_H. The exceptions are files that are imported from other projects: - CryptoCell driver - dt-bindings folders - zlib headers Change-Id: I50561bf6c88b491ec440d0c8385c74650f3c106e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 01 Nov, 2018 1 commit
-
-
Antonio Nino Diaz authored
Change-Id: I33eaee8e7c983b3042635a448cb8d689ea4e3a12 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 26 Oct, 2018 1 commit
-
-
Antonio Nino Diaz authored
There are several platforms using arm_setup_page_tables(), which is supposed to be Arm platform only. This creates several dependency problems between platforms. This patch adds the definition XLAT_TABLES_LIB_V2 to the xlat tables lib v2 makefile. This way it is possible to detect from C code which version is being used and include the correct header. The file arm_xlat_tables.h has been renamed to xlat_tables_compat.h and moved to a common folder. This way, when in doubt, this header can be used to guarantee compatibility, as it includes the correct header based on XLAT_TABLES_LIB_V2. This patch also removes the usage of ARM_XLAT_TABLES_V1 from QEMU (so that is now locked in xlat lib v2) and ZynqMP (where it was added as a workaround). Change-Id: Ie1e22a23b44c549603d1402a237a70d0120d3e04 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 11 Oct, 2018 1 commit
-
-
Antonio Nino Diaz authored
This file is shared between FVP and all CSS platforms. While it may be true that some definitions can be common, it doesn't make sense conceptually. For example, the stack size depends on the platform and so does the SRAM size. After removing them, there are not enough common definitions to justify having this header, so the other definitions have been moved to the platform_def.h of FVP, board_css_def.h and arm_def.h. Change-Id: Ifbf4b017227f9dfefa1a430f67d7d6baae6a4ba1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 10 Oct, 2018 1 commit
-
-
Antonio Nino Diaz authored
This way it can be reused by other platforms if needed. Note that this driver is designed to work with the Versatile Express NOR flash of Juno and FVP. In said platforms, the memory is organized as an interleaved memory of two chips with a 16 bit word. Any platform that wishes to reuse it with a different configuration will need to modify the driver so that it is more generic. Change-Id: Ic721758425864e0cf42b7b9b04bf0d9513b6022e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 09 Oct, 2018 1 commit
-
-
Sathees Balya authored
Change-Id: Ia00eba2b18804e6498d935d33ec104953e0e5e03 Signed-off-by: Sathees Balya <sathees.balya@arm.com>
-
- 02 Oct, 2018 1 commit
-
-
Antonio Nino Diaz authored
This option makes it hard to optimize the memory definitions of all Arm platforms because any change in the common defines must work in all of them. The best thing to do is to remove it and move the definition to each platform's header. FVP, SGI and SGM were using the definitions in board_arm_def.h. The definitions have been copied to each platform's platform_def.h. Juno was already using the ones in platform_def.h, so there have been no changes. Change-Id: I9aecd11bbc72a3d0d7aad1ef9934d8df21dcfaf2 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 07 Sep, 2018 2 commits
-
-
Sathees Balya authored
The patch 7b56928a unified the FWU mechanism on FVP and Juno platforms due to issues with MCC firmware not preserving the NVFLAGS. With MCCv150 firmware, this issue is resolved. Also writing to the NOR flash while executing from the same flash in Bypass mode had some stability issues. Hence, since the MCC firmware issue is resolved, this patch reverts to the NVFLAGS mechanism to detect FWU. Also, with the introduction of SDS (Shared Data Structure) by the SCP, the reset syndrome needs to queried from the appropriate SDS field. Change-Id: If9c08f1afaaa4fcf197f3186887068103855f554 Signed-off-by: Sathees Balya <sathees.balya@arm.com> Signed-off-by: Soby Mathew <Soby.Mathew@arm.com>
-
John Tsichritzis authored
After introducing the Mbed TLS shared heap optimisation, reducing BL2 size by 3 pages didn't leave enough space for growth. We give 1 page back to maximum BL2 size. Change-Id: I4f05432f00b923693160f69a4e4ec310a37a2b16 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
-
- 04 Sep, 2018 1 commit
-
-
John Tsichritzis authored
This patch reduces BL2 size by 12kB. Thanks to the shared Mbed TLS heap between BL1 and BL2, BL2 now requires less memory since it doesn't need to allocate a heap anymore. Change-Id: I58a15f8c424273650c9f55112abe88105b6cdbae Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
-
- 06 Aug, 2018 1 commit
-
-
Roberto Vargas authored
Change-Id: Idb9ba3864d6de3053260724f07172fd32c1523e0 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 20 Jul, 2018 1 commit
-
-
Daniel Boulby authored
BL2U is running out of stack during firmware update. Increase stack size to prevent this Change-Id: I9b1a4e237a00172c6738c84b455b3878ab184cb8 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
- 21 Jun, 2018 1 commit
-
-
Dimitris Papastamos authored
Change-Id: I67e64bb79cc984ea3263f069e22738a42321c46d Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 19 Jun, 2018 1 commit
-
-
Antonio Nino Diaz authored
The old API is deprecated and will eventually be removed. Arm platforms now use the multi console driver for boot and runtime consoles. However, the crash console uses the direct console API because it doesn't need any memory access to work. This makes it more robust during crashes. The AArch32 port of the Trusted Firmware doesn't support this new API yet, so it is only enabled in AArch64 builds. Because of this, the common code must maintain compatibility with both systems. SP_MIN doesn't have to be updated because it's only used in AArch32 builds. The TSP is only used in AArch64, so it only needs to support the new API without keeping support for the old one. Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this causes the UARTs to reset (except for the one used by the TSP). This means that they must be unregistered when suspending and re-registered when resuming. This wasn't a problem with the old driver because it just restarted the UART, and there were no problems associated with registering and unregistering consoles. The size reserved for BL2 has been increased. Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 18 Jun, 2018 1 commit
-
-
Roberto Vargas authored
Having these definitions in board_arm_def.h forces to all the arm platforms to use the same definition for PLAT_ARM_MEM_PROT_ADDR. This macro also enables the mem-protect mechanism, which means that all the arm platform has enabled mem-protect and they cannot get rid of it. Change-Id: Id29d2c51cbe6edc15f010a9f5a20c42266c48a08 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 07 Jun, 2018 1 commit
-
-
Soby Mathew authored
The patch changes the layout of BL images in memory to enable more efficient use of available space. Previously BL31 was loaded with the expectation that BL2 memory would be reclaimed by BL32 loaded in SRAM. But with increasing memory requirements in the firmware, we can no longer fit BL32 in SRAM anymore which means the BL2 memory is not reclaimed by any runtime image. Positioning BL2 below BL1-RW and above BL31 means that the BL31 NOBITS can be overlaid on BL2 and BL1-RW. This patch also propogates the same memory layout to BL32 for AArch32 mode. The reset addresses for the following configurations are also changed : * When RESET_TO_SP_MIN=1 for BL32 in AArch32 mode * When BL2_AT_EL3=1 for BL2 The restriction on BL31 to be only in DRAM when SPM is enabled is now removed with this change. The update to the firmware design guide for the BL memory layout is done in the following patch. Change-Id: Icca438e257abe3e4f5a8215f945b9c3f9fbf29c9 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 24 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
BL31 is running out of space, and the use-case of SPM doesn't require it to be in SRAM. To prevent BL31 from running out of space in the future, move BL31 to DRAM if SPM is enabled. Secure Partition Manager design document updated to reflect the changes. Increased the size of the stack of BL31 for builds with SPM. The translation tables used by SPM in Arm platforms have been moved back to the 'xlat_tables' region instead of 'arm_el3_tzc_dram'. Everything is in DRAM now, so it doesn't make sense to treat them in a different way. Change-Id: Ia6136c8e108b8da9edd90e9d72763dada5e5e5dc Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 21 May, 2018 1 commit
-
-
Soby Mathew authored
This patch adds soc_fw_config, tos_fw_config and nt_fw_config to the FVP. The config files are placeholders and do not have any useful bindings defined. The tos_fw_config is packaged in FIP and loaded by BL2 only if SPD=tspd. The load address of these configs are specified in tb_fw_config via new bindings defined for these configs. Currently, in FVP, the soc_fw_config and tos_fw_config is loaded in the page between BL2_BASE and ARM_SHARED_RAM. This memory was typically used for BL32 when ARM_TSP_RAM_LOCATION=tsram but since we cannot fit BL32 in that space anymore, it should be safe to use this memory for these configs. There is also a runtime check in arm_bl2_dyn_cfg_init() which ensures that this overlap doesn't happen. The previous arm_dyn_get_hwconfig_info() is modified to accept configs other than hw_config and hence renamed to arm_dyn_get_config_load_info(). The patch also corrects the definition of ARM_TB_FW_CONFIG_LIMIT to be BL2_BASE. Change-Id: I03a137d9fa1f92c862c254be808b8330cfd17a5a Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 15 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
This reverts commit 2f18aa1f . It is causing some tests to fail. Until the cause is found and fixed, it is needed to remove this commit from master. Change-Id: Ic5ff7a841903a15613e00379e87cbbd8a0e85152 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 11 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
The old API is deprecated and will eventually be removed. Arm platforms now use the multi console driver for boot and runtime consoles. However, the crash console uses the direct console API because it doesn't need any memory access to work. This makes it more robust during crashes. The AArch32 port of the Trusted Firmware doesn't support this new API yet, so it is only enabled in AArch64 builds. Because of this, the common code must maintain compatibility with both systems. SP_MIN doesn't have to be updated because it's only used in AArch32 builds. The TSP is only used in AArch64, so it only needs to support the new API without keeping support for the old one. Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this causes the UARTs to reset (except for the one used by the TSP). This means that they must be unregistered when suspending and re-registered when resuming. This wasn't a problem with the old driver because it just restarted the UART, and there were no problems associated with registering and unregistering consoles. The size of BL31 has been increased in builds with SPM. Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 01 May, 2018 1 commit
-
-
Roberto Vargas authored
Previously mem_protect used to be only supported from BL2. This is not helpful in the case when ARM TF-A BL2 is not used. This patch demonstrates mem_protect from el3_runtime firmware on ARM Platforms specifically when RESET_TO_BL31 or RESET_TO_SP_MIN flag is set as BL2 may be absent in these cases. The Non secure DRAM is dynamically mapped into EL3 mmap tables temporarily and then the protected regions are then cleared. This avoids the need to map the non secure DRAM permanently to BL31/sp_min. The stack size is also increased, because DYNAMIC_XLAT_TABLES require a bigger stack. Change-Id: Ia44c594192ed5c5adc596c0cff2c7cc18c001fde Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 26 Feb, 2018 1 commit
-
-
Soby Mathew authored
The patch adds the necessary changes to load HW_CONFIG in BL2 for ARM Platforms : 1. The load address of HW_CONFIG is specified via the `hw_config_addr` property in TB_FW_CONFIG is loaded by BL1. The `hw_config_max_size` property defines the maximum size to be expected for the HW_CONFIG. The `arm_dyn_cfg_helpers.c` and corresponding header implements utility functions to parse these DT properties defined. The `arm_dyn_cfg.c` implements wrappers to these helpers to enable them to be invoked from ARM platform layer. 2. `HW_CONFIG` is added to the `bl2_mem_params_descs[]` array which is the list of images to be loaded by BL2. 3. The `libfdt` sources are now included when BL2 is built 4. A new helper `populate_next_bl_params_config()` is introduced in desc_image_load.c to populate the subsequent executable BL images with the `hw_config` and the corresponding `fw_config` if available. The `plat_get_next_bl_params()` API for ARM platforms is modified to invoke this new helper. 5. The implementation of `bl2_early_platform_setup2()` is modified to consider `arg0` as well in addition to `arg1` passed from BL1. 6. Bump up the BL2 size for Juno to accommodate the inclusion of libfdt. Change-Id: I80f1554adec41753e0d179a5237364f04fe13a3f Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 11 Jan, 2018 1 commit
-
-
Dimitris Papastamos authored
On some build configurations BL31 is running out of space. Now that TSP is moved to secure dram, we have a bit of additional space to use in BL31. Change-Id: Ib89fcd8bae99c85c9c5e5d9228bb42fb7048dcb6 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com> Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 03 Jan, 2018 1 commit
-
-
Dimitris Papastamos authored
To allow BL31 to grow in SRAM, move TSP in TZC secured DRAM by default. Increase the BL31 max limit by one page. Change-Id: Idd3479be02f0f9bafac2f275376d7db0c2015431 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 06 Dec, 2017 1 commit
-
-
Antonio Nino Diaz authored
A new platform define, `PLAT_SP_IMAGE_XLAT_SECTION_NAME`, has been introduced to select the section where the translation tables used by the S-EL1/S-EL0 are placed. This define has been used to move the translation tables to DRAM secured by TrustZone. Most of the extra needed space in BL31 when SPM is enabled is due to the large size of the translation tables. By moving them to this memory region we can save 44 KiB. A new argument has been added to REGISTER_XLAT_CONTEXT2() to specify the region where the translation tables have to be placed by the linker. Change-Id: Ia81709b4227cb8c92601f0caf258f624c0467719 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 29 Nov, 2017 1 commit
-
-
Soby Mathew authored
This patch fixes a couple of issues for AArch32 builds on ARM reference platforms : 1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and AArch32 build. Since BL31 is not present in AArch32 mode, this meant that the BL31 memory is empty when built for AArch32. Hence this patch allocates BL32 to the memory region occupied by BL31 for AArch32 builds. As a side-effect of this change, the ARM_TSP_RAM_LOCATION macro cannot be used to control the load address of BL32 in AArch32 mode which was never the intention of the macro anyway. 2. A static assert is added to sp_min linker script to check that the progbits are within the bounds expected when overlaid with other images. 3. Fix specifying `SPD` when building Juno for AArch32 mode. Due to the quirks involved when building Juno for AArch32 mode, the build option SPD needed to specifed. This patch corrects this and also updates the documentation in the user-guide. 4. Exclude BL31 from the build and FIP when building Juno for AArch32 mode. As a result the previous assumption that BL31 must be always present is removed and the certificates for BL31 is only generated if `NEED_BL31` is defined. Change-Id: I1c39bbc0abd2be8fbe9f2dea2e9cb4e3e3e436a8 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 09 Nov, 2017 1 commit
-
-
Antonio Nino Diaz authored
This initial port of the Secure Partitions Manager to FVP supports BL31 in both SRAM and Trusted DRAM. A document with instructions to build the SPM has been added. Change-Id: I4ea83ff0a659be77f2cd72eaf2302cdf8ba98b32 Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Achin Gupta <achin.gupta@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 25 Oct, 2017 1 commit
-
-
Qixiang Xu authored
For Trusted Board Boot, BL2 needs more space to support the ECDSA and ECDSA+RSA algorithms. Change-Id: Ie7eda9a1315ce836dbc6d18d6588f8d17891a92d Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
-
- 11 Oct, 2017 1 commit
-
-
Soby Mathew authored
Provides GICv3 save/restore feature to arm_system_pwr_domain_resume and arm_system_pwr_domain_save functions. Introduce FVP PSCI power level 3 (System level) support. This is solely done to provide example code on how to use the GICv3 save and restore helpers. Also make CSS GICv3 platforms power off the Redistributor on SYSTEM SUSPEND as its state is saved and restored. Change-Id: I0d852f3af8824edee1a17c085cf593ddd33a4e77 Signed-off-by: Soby Mathew <soby.mathew@arm.com> Co-Authored-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 06 Oct, 2017 1 commit
-
-
David Cunado authored
The MEM_PROTECT support adds a MMAP region for DRAM2, which when building with TBBR support and OP-TEE tsp requires an additional entry in the MMAP region array in BL2 - PLAT_ARM_MMAP_ENTRIES is increased. The MEM_PROTECT support also adds a new region in BL31, and when BL31 is placed in DRAM, the memory mappings require an additional translation table - MAX_XLAT_TABLES is increased. Change-Id: I0b76260da817dcfd0b8f73a7193c36efda977625 Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 25 Sep, 2017 1 commit
-
-
Roberto Vargas authored
mem_protect needs some kind of non-volatile memory because it has to remember its state across reset and power down events. The most suitable electronic part for this feature is a NVRAM which should be only accesible from the secure world. Juno and FVP lack such hardware and for this reason the MEM_PROTECT functionality is implemented with Flash EEPROM memory on both boards, even though this memory is accesible from the non-secure world. This is done only to show a full implementation of these PSCI features, but an actual system shouldn't use a non-secure NVRAM to implement it. The EL3 runtime software will write the mem_protect flag and BL2 will read and clear the memory ranges if enabled. It is done in BL2 because it reduces the time that TF needs access to the full non-secure memory. The memory layout of both boards is defined using macros which take different values in Juno and FVP platforms. Generic platform helpers are added that use the platform specific macros to generate a mem_region_t that is valid for the platform. Change-Id: I2c6818ac091a2966fa07a52c5ddf8f6fde4941e9 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 22 Sep, 2017 1 commit
-
-
Qixiang Xu authored
For Trusted Board Boot, BL1 RW section and BL2 need more space to support the ECDSA algorithm. Specifically, PLAT_ARM_MAX_BL1_RW_SIZE is increased on ARM platforms. And on the Juno platform: - BL2 size, PLAT_ARM_MAX_BL2_SIZE is increased. - SCP_BL2 is loaded into the space defined by BL31_BASE -> BL31_RW_BASE. In order to maintain the same size space for SCP_BL2,PLAT_ARM_MAX_BL31_SIZE is increased. Change-Id: I379083f918b40ab1c765da4e71780d89f0058040 Co-Authored-By: David Cunado <david.cunado@arm.com> Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
-