- 25 Feb, 2020 3 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: I07a07677153d3671ced776671e4f107824d3df16 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
*All* UART drivers in TF-A are storing their base address as a uintptr_t pointer in the first location of the UART specific driver data. Since the base address is a pretty natural and generic data item, we should integrate this into the generic console_t structure. That will not only allow to remove a lot of seemingly UART specific data structures, but also enables to simplify runtime choices between different UARTs, since they can share the same pointer. This patch just adds the new member, the existing data structures will be handled on a per-UART base in follow-up patches. Change-Id: I59ce49471ccc8f3b870f2cfd8a72ebfd0cb14d12 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 20 Feb, 2020 4 commits
-
-
Varun Wadekar authored
This patch modifies the delay timer driver to switch to the ARM secure physical timer instead of using Tegra's on-chip uS timer. The secure timer is not accessible to the NS world and so eliminates an important attack vector, where the Tegra timer source gets switched off from the NS world leading to a DoS attack for the trusted world. This timer is shared with the S-EL1 layer for now, but later patches will mark it as exclusive to the EL3 exception mode. Change-Id: I2c00f8cb4c48b25578971c626c314603906ad7cc Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Varun Wadekar authored
This patch moves the MHZ_TICKS_PER_SEC macro to utils_def.h for other platforms to use. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Change-Id: I6c4dc733f548d73cfdb3515ec9ad89a9efaf4407
-
Varun Wadekar authored
The CPUACTLR_EL1 register on Cortex-A57 CPUs supports a bit to enable non-cacheable streaming enhancement. Platforms can set this bit only if their memory system meets the requirement that cache line fill requests from the Cortex-A57 processor are atomic. This patch adds support to enable higher performance non-cacheable load forwarding for such platforms. Platforms must enable this support by setting the 'A57_ENABLE_NONCACHEABLE_LOAD_FWD' flag from their makefiles. This flag is disabled by default. Change-Id: Ib27e55dd68d11a50962c0bbc5b89072208b4bac5 Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Manish V Badarkhe authored
Removed duplicate error code present for SMCCC and used proper error code for "SMCCC_ARCH_WORKAROUND_2" call. Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com> Change-Id: I76fc7c88095f78a7e2c3d205838f8eaf3132ed5c
-
- 18 Feb, 2020 3 commits
-
-
Zelalem authored
Fixes for the following MISRA violations: - Missing explicit parentheses on sub-expression - An identifier or macro name beginning with an underscore, shall not be declared - Type mismatch in BL1 SMC handlers and tspd_main.c Change-Id: I7a92abf260da95acb0846b27c2997b59b059efc4 Signed-off-by: Zelalem <zelalem.aweke@arm.com>
-
Jimmy Brisson authored
Also update copyright statements Change-Id: Iba0305522ac0f2ddc4da99127fd773f340e67300 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
-
Jimmy Brisson authored
Change-Id: I686fd623b8264c85434853a2a26ecd71e9eeac01 Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
-
- 10 Feb, 2020 4 commits
-
-
Achin Gupta authored
This patch adds a rudimentary SPM dispatcher component in EL3. It does the following: - Consumes the TOS_FW_CONFIG to determine properties of the SPM core component - Initialises the SPM core component which resides in the BL32 image - Implements a handler for SPCI calls from either security state. Some basic validation is done for each call but in most cases it is simply forwarded as-is to the "other" security state. Signed-off-by: Achin Gupta <achin.gupta@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Change-Id: I7d116814557f7255f4f4ebb797d1619d4fbab590
-
Achin Gupta authored
This patch reserves and maps the Trusted DRAM for SPM core execution. It also configures the TrustZone address space controller to run BL31 in secure DRAM. Signed-off-by: Achin Gupta <achin.gupta@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Change-Id: I7e1bb3bbc61a0fec6a9cb595964ff553620c21dc
-
Achin Gupta authored
This patch repurposes the TOS FW configuration file as the manifest for the SPM core component which will reside at the secure EL adjacent to EL3. The SPM dispatcher component will use the manifest to determine how the core component must be initialised. Routines and data structure to parse the manifest have also been added. Signed-off-by: Achin Gupta <achin.gupta@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Change-Id: Id94f8ece43b4e05609f0a1d364708a912f6203cb
-
Manish Pandey authored
Currently sptool generates a single blob containing all the Secure Partitions, with latest SPM implementation, it is desirable to have individual blobs for each Secure Partition. It allows to leverage packaging and parsing of SP on existing FIP framework. It also allows SP packages coming from different sources. This patch modifies sptool so that it takes number of SP payload pairs as input and generates number of SP blobs instead of a single blob. Each SP blob can optionally have its own header containing offsets and sizes of different payloads along with a SP magic number and version. It is also associated in FIP with a UUID, provided by SP owner. Usage example: sptool -i sp1.bin:sp1.dtb -o sp1.pkg -i sp2.bin:sp2.dtb -o sp2.pkg ... Signed-off-by: Manish Pandey <manish.pandey2@arm.com> Change-Id: Ie2db8e601fa1d4182d0a1d22e78e9533dce231bc
-
- 07 Feb, 2020 13 commits
-
-
Alexei Fedorov authored
At the moment, address demangling is only used by the backtrace functionality. However, at some point, other parts of the TF-A codebase may want to use it. The 'demangle_address' function is replaced with a single XPACI instruction which is also added in 'do_crash_reporting()'. Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com> Change-Id: I4424dcd54d5bf0a5f9b2a0a84c4e565eec7329ec
-
Aditya Angadi authored
On systems that have multiple platform components that can interpret the SCMI messages, there is a need to support multiple SCMI channels (one each to those platform components). Extend the existing SCMI interface that currently supports only a single SCMI channel to support multiple SCMI channels. Change-Id: Ice4062475b903aef3b5e5bc37df364c9778a62c5 Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
-
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>
-
Vijayenthiran Subramaniam authored
Multi-chip platforms have two or more identical chips connected using a high speed coherent link. In order to identify such platforms, add chip_id and multi_chip_mode information in the platform variant info structure. The values of these two new elements is populated during boot. Change-Id: Ie6e89cb33b3f0f408814f6239cd06647053e23ed Signed-off-by: Vijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
-
Louis Mayencourt authored
Currently, an IO setup failure will be ignored on arm platform release build. Change this to panic instead. Change-Id: I027a045bce2422b0a0fc4ff9e9d4c6e7bf5d2f98 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
Change the return type of "arm_io_is_toc_valid()" and "plat_arm_bl1_fwu_needed()" to bool, to match function behavior. Change-Id: I503fba211219a241cb263149ef36ca14e3362a1c Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
Use the firmware configuration framework to store the io_policies information inside the configuration device tree instead of the static structure in the code base. The io_policies required by BL1 can't be inside the dtb, as this one is loaded by BL1, and only available at BL2. This change currently only applies to FVP platform. Change-Id: Ic9c1ac3931a4a136aa36f7f58f66d3764c1bfca1 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
Use the firmware configuration framework in arm dynamic configuration to retrieve mbedtls heap information between bl1 and bl2. For this, a new fconf getter is added to expose the device tree base address and size. Change-Id: Ifa5ac9366ae100e2cdd1f4c8e85fc591b170f4b6 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
Use fconf to retrieve the `disable_authentication` property. Move this access from arm dynamic configuration to bl common. Change-Id: Ibf184a5c6245d04839222f5457cf5e651f252b86 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
This patch introduces a better separation between the trusted-boot related properties, and the dynamic configuration DTBs loading information. The dynamic configuration DTBs properties are moved to a new node: `dtb-registry`. All the sub-nodes present will be provided to the dynamic config framework to be loaded. The node currently only contains the already defined configuration DTBs, but can be extended for future features if necessary. The dynamic config framework is modified to use the abstraction provided by the fconf framework, instead of directly accessing the DTBs. The trusted-boot properties are kept under the "arm,tb_fw" compatible string, but in a separate `tb_fw-config` node. The `tb_fw-config` property of the `dtb-registry` node simply points to the load address of `fw_config`, as the `tb_fw-config` is currently part of the same DTB. Change-Id: Iceb6c4c2cb92b692b6e28dbdc9fb060f1c46de82 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
Use the dtb provided by bl1 as configuration file for fconf. Change-Id: I3f466ad9b7047e1a361d94e71ac6d693e31496d9 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
Move the loading of the dtb from arm_dym_cfg to fconf. The new loading function is not associated to arm platform anymore, and can be moved to bl_main if wanted. Change-Id: I847d07eaba36d31d9d3ed9eba8e58666ea1ba563 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
Louis Mayencourt authored
Introduce the Firmware CONfiguration Framework (fconf). The fconf is an abstraction layer for platform specific data, allowing a "property" to be queried and a value retrieved without the requesting entity knowing what backing store is being used to hold the data. The default backing store used is C structure. If another backing store has to be used, the platform integrator needs to provide a "populate()" function to fill the corresponding C structure. The "populate()" function must be registered to the fconf framework with the "FCONF_REGISTER_POPULATOR()". This ensures that the function would be called inside the "fconf_populate()" function. A two level macro is used as getter: - the first macro takes 3 parameters and converts it to a function call: FCONF_GET_PROPERTY(a,b,c) -> a__b_getter(c). - the second level defines a__b_getter(c) to the matching C structure, variable, array, function, etc.. Ex: Get a Chain of trust property: 1) FCONF_GET_PROPERY(tbbr, cot, BL2_id) -> tbbr__cot_getter(BL2_id) 2) tbbr__cot_getter(BL2_id) -> cot_desc_ptr[BL2_id] Change-Id: Id394001353ed295bc680c3f543af0cf8da549469 Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
-
- 06 Feb, 2020 1 commit
-
-
Max Shvetsov authored
Enables usage of ARM_ROTPK_LOCATION=regs for FVP board. Removes hard-coded developer keys. Instead, setting ARM_ROTPK_LOCATION=devel_* takes keys from default directory. In case of ROT_KEY specified - generates a new hash and replaces the original. Note: Juno board was tested by original feature author and was not tested for this patch since we don't have access to the private key. Juno implementation was moved to board-specific file without changing functionality. It is not known whether byte-swapping is still needed for this platform. Change-Id: I0fdbaca0415cdcd78f3a388551c2e478c01ed986 Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com>
-
- 05 Feb, 2020 1 commit
-
-
Achin Gupta authored
This patch adds a header file with defines based on the SPCI Beta 0 spec. It will be used by the SPM dispatcher component which will be introduced in subsequent patches. Signed-off-by: Achin Gupta <achin.gupta@arm.com> Signed-off-by: Artsem Artsemenka <artsem.artsemenka@arm.com> Change-Id: Ia8a196cd85ebc14731f24801698d0a49a97b6063
-
- 03 Feb, 2020 1 commit
-
-
Alexei Fedorov authored
This patch adds 'fdtw_read_bytes' and 'fdtw_write_inplace_bytes' functions for read/write array of bytes from/to a given property. It also adds 'fdt_setprop_inplace_namelen_partial' to jmptbl.i files for builds with USE_ROMLIB=1 option. Change-Id: Ied7b5c8b38a0e21d508aa7bcf5893e656028b14d Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
- 30 Jan, 2020 1 commit
-
-
Grzegorz Jaszczyk authored
In order to access MG SRAM, the amb bridge needs to be configured which is done in bl2 platform init. For MG CM3, the image is only loaded to its SRAM and the CM3 itself is left in reset. It is because the next stage bootloader (e.g. u-boot) will trigger action which will take it out of reset when needed. This can happen e.g. when appropriate device-tree setup (which has enabled 802.3 auto-neg) will be chosen. In other cases the MG CM3 should not be running. Change-Id: I816ea14e3a7174eace068ec44e3cc09998d0337e Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
-
- 28 Jan, 2020 2 commits
-
-
Alexei Fedorov authored
This patch adds 'calc_hash' function using Mbed TLS library required for Measured Boot support. Change-Id: Ifc5aee0162d04db58ec6391e0726a526f29a52bb Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
-
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>
-
- 27 Jan, 2020 2 commits
-
-
Madhukar Pappireddy authored
In order to support SEPARATE_NOBITS_REGION for Arm platforms, we need to load BL31 PROGBITS into secure DRAM space and BL31 NOBITS into SRAM. Hence mandate the build to require that ARM_BL31_IN_DRAM is enabled as well. Naturally with SEPARATE_NOBITS_REGION enabled, the BL31 initialization code cannot be reclaimed to be used for runtime data such as secondary cpu stacks. Memory map for BL31 NOBITS region also has to be created. Change-Id: Ibbc8c9499a32e63fd0957a6e254608fbf6fa90c9 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
-
Manish Pandey authored
CPUECTLR_EL1.EXTLLC bit indicates the presense of internal or external last level cache(LLC) in the system, the reset value is internal LLC. To cater for the platforms(like N1SDP) which has external LLC present introduce a new build option 'NEOVERSE_N1_EXTERNAL_LLC' which can be enabled by platform port. Signed-off-by: Manish Pandey <manish.pandey2@arm.com> Change-Id: Ibf475fcd6fd44401897a71600f4eafe989921363
-
- 24 Jan, 2020 1 commit
-
-
Masahiro Yamada authored
Currently, the end address macros are defined per BL, like BL2_END, BL31_END, BL32_END. They are not handy in the common code shared between multiple BL stages. This commit introduces BL_END, which is equivalent to BL{2,31,32}_END, and will be useful for the BL-common code. Change-Id: I3c39bf6096d99ce920a5b9fa21c0f65456fbfe8a Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 23 Jan, 2020 2 commits
-
-
Mark Dykes authored
This reverts commit d433bbdd. Change-Id: I46c69dce704a1ce1b50452dd4d62425c4a67f7f0
-
Andrew Walbran authored
This makes the PSCI SYSTEM_OFF call work on QEMU. It assumes that QEMU has semihosting enabled, but that is already assumed by the image loader. Signed-off-by: Andrew Walbran <qwandor@google.com> Change-Id: I0fb7cf7909262b675c3143efeac07f4d60730b03
-
- 22 Jan, 2020 2 commits
-
-
Anthony Steinhauser authored
Even though ERET always causes a jump to another address, aarch64 CPUs speculatively execute following instructions as if the ERET instruction was not a jump instruction. The speculative execution does not cross privilege-levels (to the jump target as one would expect), but it continues on the kernel privilege level as if the ERET instruction did not change the control flow - thus execution anything that is accidentally linked after the ERET instruction. Later, the results of this speculative execution are always architecturally discarded, however they can leak data using microarchitectural side channels. This speculative execution is very reliable (seems to be unconditional) and it manages to complete even relatively performance-heavy operations (e.g. multiple dependent fetches from uncached memory). This was fixed in Linux, FreeBSD, OpenBSD and Optee OS: https://github.com/torvalds/linux/commit/679db70801da9fda91d26caf13bf5b5ccc74e8e8 https://github.com/freebsd/freebsd/commit/29fb48ace4186a41c409fde52bcf4216e9e50b61 https://github.com/openbsd/src/commit/3a08873ece1cb28ace89fd65e8f3c1375cc98de2 https://github.com/OP-TEE/optee_os/commit/abfd092aa19f9c0251e3d5551e2d68a9ebcfec8a It is demonstrated in a SafeSide example: https://github.com/google/safeside/blob/master/demos/eret_hvc_smc_wrapper.cc https://github.com/google/safeside/blob/master/kernel_modules/kmod_eret_hvc_smc/eret_hvc_smc_module.c Signed-off-by: Anthony Steinhauser <asteinhauser@google.com> Change-Id: Iead39b0b9fb4b8d8b5609daaa8be81497ba63a0f
-
Madhukar Pappireddy authored
In order to support SEPARATE_NOBITS_REGION for Arm platforms, we need to load BL31 PROGBITS into secure DRAM space and BL31 NOBITS into SRAM. Hence mandate the build to require that ARM_BL31_IN_DRAM is enabled as well. Naturally with SEPARATE_NOBITS_REGION enabled, the BL31 initialization code cannot be reclaimed to be used for runtime data such as secondary cpu stacks. Memory map for BL31 NOBITS region also has to be created. Change-Id: Ibd480f82c1dc74e9cbb54eec07d7a8fecbf25433 Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
-