- 19 May, 2020 1 commit
-
-
Manish V Badarkhe authored
CoT used for BL1 and BL2 are moved to tbbr_cot_bl1.c and tbbr_cot_bl2.c respectively. Common CoT used across BL1 and BL2 are moved to tbbr_cot_common.c. Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: I2252ac8a6960b3431bcaafdb3ea4fb2d01b79cf5
-
- 02 Apr, 2020 3 commits
-
-
Masahiro Yamada authored
This is not used in BL31 or Bl32 for this platform. Pass it to BL2_CPPFLAGS instead of defining it for all BL images. This will produce slightly smaller BL31 and Bl32. Change-Id: I66ec5179f8dc5b112e65547335e7dd0a0f4074cd Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
As GCC manual says, -D option defines a macro as 1, if =<value> is omitted. -D <name> Predefine <name> as a macro, with definition 1. The same applied with Clang, too. In the context of -D option, =1 is always redundant. Change-Id: I487489a1ea3eb51e734741619c1e65dab1420bc4 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Commit d5e97a1d ("Build: define IMAGE_AT_EL1 or IMAGE_AT_EL3 globally for C files") does not have commit 848a7e8c ("Build: introduce per-BL CPPFLAGS and ASFLAGS") as an ancestor because they were pulled almost at the same time. This is a follow-up conversion to be consistent with commit 11a3c5ee ("plat: pass -D option to BL*_CPPFLAGS instead of BL*_CFLAGS"). With this change, the command line option, IMAGE_AT_EL3, will be passed to .S files as well. I remove the definition in include/lib/cpus/aarch64/cpu_macros.S Otherwise, the following error would happen. include/lib/cpus/aarch64/cpu_macros.S:29:0: error: "IMAGE_AT_EL3" redefined [-Werror] Change-Id: I943c8f22356483c2ae3c57b515c69243a8fa6889 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 01 Apr, 2020 2 commits
-
-
Masahiro Yamada authored
BL2 for this platform uses mmap_add_dynamic_region(), but BL31 and BL32 (TSP) only use static mapping. So, BL31 and BL32 can make the tables read-only after enabling MMU. Enable ALLOW_RO_XLAT_TABLES by default. Change-Id: Ib59c44697163629119888bb6abd47fa144f09ba3 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Currently, enable_mmu_el1() or enable_mmu_el3() is kept outside the common function because the appropriate one must be chosen. Use enable_mmu() and move it to the common function. Change-Id: If2fb651691a7b6be05674f5cf730ae067ba95d4b Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 30 Mar, 2020 1 commit
-
-
Alexei Fedorov authored
This patch moves all GICv3 driver files into new added 'gicv3.mk' makefile for the benefit of the generic driver which can evolve in the future without affecting platforms. The patch adds GICv3 driver configuration flags 'GICV3_IMPL', 'GICV3_IMPL_GIC600_MULTICHIP' and 'GICV3_OVERRIDE_DISTIF_PWR_OPS' described in 'GICv3 driver options' section of 'build-option.rst' document. NOTE: Platforms with GICv3 driver need to be modified to include 'drivers/arm/gic/v3/gicv3.mk' in their makefiles. Change-Id: If055f6770ff20f5dee5a3c99ae7ced7cdcac5c44 Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 10 Mar, 2020 1 commit
-
-
Alexei Fedorov authored
This patch provides separation of GICD, GICR accessor functions and adds new macros for GICv3 registers access as a preparation for GICv3.1 and GICv4 support. NOTE: Platforms need to modify to include both 'gicdv3_helpers.c' and 'gicrv3_helpers.c' instead of the single helper file previously. Change-Id: I1641bd6d217d6eb7d1228be3c4177b2d556da60a Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 06 Mar, 2020 1 commit
-
-
Masahiro Yamada authored
Currently, the ROM region is needlessly too large. The on-chip SRAM region of the next SoC will start from 0x04000000, and this will cause the region overlap. Mapping 0x04000000 for the ROM is enough. Change-Id: I85ce0bb1120ebff2e3bc7fd13dc0fd15dfff5ff6 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 26 Feb, 2020 1 commit
-
-
Masahiro Yamada authored
The revision register address will be changed in the next SoC. The LSI revision is needed in order to know where the revision register is located, but you need to read out the revision register for that. This is impossible. We need to know the revision register address by other means. Use BL_CODE_BASE, where the base address of the TF image that is currently running. If it is bigger than 0x80000000 (i.e. the DRAM base is 0x80000000), we assume it is a legacy SoC. Change-Id: I9d7f4325fe2085a8a1ab5310025e5948da611256 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 25 Feb, 2020 2 commits
-
-
Andre Przywara authored
Since now the generic console_t structure holds the UART base address as well, let's use that generic location and drop the UART driver specific data structure at all. Change-Id: I7a23327394d142af4b293ea7ccd90b843c54587c Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
Since now the generic console_t structure holds the UART base address as well, let's use that generic location and drop the UART driver specific data structure at all. Change-Id: Ia9d996bb45ff3a7f1b240f12fd75805b48a048e9 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 12 Feb, 2020 11 commits
-
-
Masahiro Yamada authored
The on-chip SRAM region will be changed in the next SoC. Make it configurable. Also, split the mmap code into a new helper function so that it can be re-used for another boot mode. Change-Id: I89f40432bf852a58ebc9be5d9dec4136b8dc010b Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The I/O register region will be changed in the next SoC. Make it configurable. Change-Id: Iec0cbd1ef2d0703ebc7c3d3082edd73791bbfec9 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The next SoC will have: - No boot swap - SD boot - No USB boot Add new fields to handle this. Change-Id: I772395f2c5dfc612e575b0cbd0657a5fa9611c25 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The register base address will be changed in the next SoC. Make it configurable. Change-Id: Ibe07bd9db128b0f7e629916cb6ae21ba7984eca9 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The flag, uniphier_emmc_block_addressing, is boolean logic, so "bool' is more suitable. uniphier_emmc_is_over_2gb() is not boolean - it returns 1 / 0 depending on the card density, or a negative value on failure. Rename it to make it less confusing. Change-Id: Ia646b1929147b644e0df07c46b54ab80548bc3bd Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The register base will be changed in the next SoC. Make it configurable. Change-Id: I4a7cf85fe50e4d71db58a3372a71774e43193bd3 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
This is boolean logic, so "bool" is more suitable. Change-Id: I439c5099770600a65b8f58390a4c621c2ee487a5 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The next SoC supports the same UART, but the register base will be changed. Make it configurable. Change-Id: Ida5c9151b2f3554afd15555b22838437eef443f7 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The register base will be changed in the next SoC. Make it configurable. Change-Id: I9fbb6bdd1cf06207618742d4ad7970d911c9bc26 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The next SoC does not support the NAND controller, but make the base address configurable for consistency and future proof. Change-Id: I776e43ff2b0408577919b0b72849c3e1e5ce0758 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The next SoC supports the same eMMC controller, but the register base will be changed. Make it configurable. Change-Id: I00cb5531bc3d8d49357ad5e922cdd3d785355edf Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 07 Feb, 2020 1 commit
-
-
Aditya Angadi authored
In order to allow the MHUv2 driver to be usable with multiple MHUv2 controllers, use the base address of the controller from the platform information instead of the MHUV2_BASE_ADDR macro. Change-Id: I4dbab87b929fb0568935e6c8b339ce67937f8cd1 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
- 28 Jan, 2020 1 commit
-
-
Louis Mayencourt authored
The Secure Configuration Register is 64-bits in AArch64 and 32-bits in AArch32. Use u_register_t instead of unsigned int to reflect this. Change-Id: I51b69467baba36bf0cfaec2595dc8837b1566934 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
- 24 Jan, 2020 7 commits
-
-
Masahiro Yamada authored
This platform supports multiple SoCs. The next SoC will still keep quite similar architecture, but the memory base will be changed. The ENABLE_PIE improves the maintainability and usability. You can reuse a single set of BL images for other SoC/board without re-compiling TF-A at all. This will also keep the code cleaner because it avoids #ifdef around various base addresses. By defining ENABLE_PIE, BL2_AT_EL3, BL31, and BL32 (TSP) are really position-independent now. You can load them anywhere irrespective of their link address. Change-Id: I8d5e3124ee30012f5b3bfa278b0baff8efd2fff7 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
BL2_BASE, BL31_BASE, and BL32_BASE are defined in platform_def.h, that is, determined at link-time. On the other hand, BL2_END, BL31_END, and BL32_END are derived from the symbols produced by the linker scripts. So, they are fixed-up at run-time if ENABLE_PIE is enabled. To make it work in a position-indepenent manner, use BL_CODE_BASE and BL_END, both of which are relocatable. Change-Id: Ic179a7c60eb64c5f3024b178690b3ac7cbd7521b Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Currently, UNIPHIER_SCP_BASE is hard-coded in uniphier_scp_start(), which is not handy for PIE. Towards the goal of making this really position-independent, pass in image_info->image_base. Change-Id: I88e020a1919c607b1d5ce70b116201d95773bb63 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Currently, the .buffer field in io_block_dev_spec is statically set, which is not handy for PIE. Towards the goal of making this really position-independent, set the buffer length and length in the uniphier_io_block_setup() function. Change-Id: I22b20d7b58d6ffd38f64f967a2820fca4bd7dade Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Currently, uniphier_bl2_mmap hard-codes the memory region needed for loading other images. Towards the goal of making this really position-independent, call mmap_add_dynamic_region() before that region gets accessed. Change-Id: Ieb505b91ccf2483e5f1a280accda564b33f19f11 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Now that various issues in the PIE support have been fixed, this platform can enable ENABLE_PIE. I tested BL2_AT_EL3, BL31, TSP, and all of them worked. Change-Id: Ibc499c6bad30b7f81a42bfa7e435ce25f820bd9c Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Deepika Bhavnani authored
PLATFORM_CORE_COUNT - Unsigned int PLATFORM_CLUSTER_COUNT - Unsigned int PLATFORM_MAX_CPUS_PER_CLUSTER - Unsigned int PLATFORM_CORE_COUNT_PER_CLUSTER - Unsigned int Signed-off-by: Deepika Bhavnani <deepika.bhavnani@arm.com> Change-Id: Iad91e99e9d13254de23eb10e5f655253f253cf0d
-
- 26 Dec, 2019 1 commit
-
-
Masahiro Yamada authored
All the SoCs in 64-bit UniPhier SoC family support EL2. Just hard-code MODE_EL2 instead of using el_implemented() helper. Change-Id: I7ab48002c5205bc8c013e1b46313b57d6c431db0 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 25 Dec, 2019 1 commit
-
-
Masahiro Yamada authored
uniphier_scp_is_running() reads the UNIPHIER_STMBE2COM register, but it does not exist on all SoCs. Do not call this function if the on-chip SCP is not supported. Change-Id: I7c71ca0735e3a8e095c3f22ba6165f82a2986362 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 20 Dec, 2019 2 commits
-
-
Paul Beesley authored
Before adding any new SPM-related components we should first do some cleanup around the existing SPM-MM implementation. The aim is to make sure that any SPM-MM components have names that clearly indicate that they are MM-related. Otherwise, when adding new SPM code, it could quickly become confusing as it would be unclear to which component the code belongs. The secure_partition.h header is a clear example of this, as the name is generic so it could easily apply to any SPM-related code, when it is in fact SPM-MM specific. This patch renames the file and the two structures defined within it, and then modifies any references in files that use the header. Change-Id: I44bd95fab774c358178b3e81262a16da500fda26 Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
Paul Beesley authored
There are two different implementations of Secure Partition management in TF-A. One is based on the "Management Mode" (MM) design, the other is based on the Secure Partition Client Interface (SPCI) specification. Currently there is a dependency between their build flags that shouldn't exist, making further development harder than it should be. This patch removes that dependency, making the two flags function independently. Before: ENABLE_SPM=1 is required for using either implementation. By default, the SPCI-based implementation is enabled and this is overridden if SPM_MM=1. After: ENABLE_SPM=1 enables the SPCI-based implementation. SPM_MM=1 enables the MM-based implementation. The two build flags are mutually exclusive. Note that the name of the ENABLE_SPM flag remains a bit ambiguous - this will be improved in a subsequent patch. For this patch the intention was to leave the name as-is so that it is easier to track the changes that were made. Change-Id: I8e64ee545d811c7000f27e8dc8ebb977d670608a Signed-off-by: Paul Beesley <paul.beesley@arm.com>
-
- 03 Sep, 2019 1 commit
-
-
Masahiro Yamada authored
This console driver sends '\r' before 'n', not after. It works, but the convention is "\r\n" (i.e. CRLF) Instead of fixing it in the driver, set CONSOLE_FLAG_TRANSLATE_CRLF to leave it to the framework. Change-Id: I2154e29313739a40dff70cfb5c0f8989136d4ad2 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 31 Jul, 2019 2 commits
-
-
Masahiro Yamada authored
Fix the typo "warn" -> "warm". Also fix the following checkpatch.pl warnings: CHECK: Prefer using the BIT macro CHECK: No space is necessary after a cast CHECK: Alignment should match open parenthesis CHECK: Unnecessary parentheses around uniphier_io_policies[image_id].dev_handle Change-Id: Ic11eea2668c4bf2d1e8f089e6338ba7b7156d80b Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Use the helper in utils_def.h instead of the own macro. Change-Id: I527f9e75914d60f66354e365006b960ba5e8cbae Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 12 Jul, 2019 1 commit
-
-
Madhukar Pappireddy authored
Fix the header file path Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com> Change-Id: I73a92a3f0049ecbda7eade452405927c04048e01
-