- 25 Jun, 2015 3 commits
-
-
Juan Castillo authored
Using assert() to check the length of keys and hashes included in a certificate is not a safe approach because assert() only applies to debug builds. A malformed certificate could exploit security flaws in release binaries due to buffer overflows. This patch replaces assert() with runtime checkings in the PolarSSL authentication module, so malformed certificates can not cause a memory overflow. Change-Id: I42ba912020595752c806cbd242fe3c74077d993b
-
Juan Castillo authored
The cert_create tool calculates the hash of each BL image and includes it as an ASN.1 OCTET STRING in the corresponding certificate extension. Without additional information, the firmware running on the platform has to know in advance the algorithm used to generate the hash. This patch modifies the cert_create tool so the certificate extensions that include an image hash are generated according to the following ASN.1 structure: DigestInfo ::= SEQUENCE { digestAlgorithm AlgorithmIdentifier, digest OCTET STRING } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } The PolarSSL module has been updated to extract the image hash from the certificate extension according to this structure. Change-Id: I6d83430f12a8a0eea8447bec7c936e903f644c85
-
Juan Castillo authored
This patch adds a boolean build option 'SAVE_KEYS' to indicate the certificate generation tool that it must save the private keys used to establish the chain of trust. This option depends on 'CREATE_KEYS' to be enabled. Default is '0' (do not save). Because the same filenames are used as outputs to save the keys, they are no longer a dependency to the cert_tool. This dependency has been removed from the Makefile. Documentation updated accordingly. Change-Id: I67ab1c2b1f8a25793f0de95e8620ce7596a6bc3b
-
- 24 Jun, 2015 4 commits
-
-
danh-arm authored
Bug fix: Build time condition to relocate RW data
-
Sandrine Bailleux authored
This patch fixes the build time condition deciding whether the read-write data should be relocated from ROM to RAM. It was incorrectly using __DATA_ROM_START__, which is a linker symbol and not a compiler build flag. As a result, the relocation code was always compiled out. This bug has been introduced by the following patch: "Rationalize reset handling code" Change-Id: I1c8d49de32f791551ab4ac832bd45101d6934045
-
danh-arm authored
Add missing features to the Tegra GIC driver
-
danh-arm authored
Enhance BL3-1 entrypoint handling to support non-TF boot firmware - Phase 1
-
- 22 Jun, 2015 1 commit
-
-
Varun Wadekar authored
In order to handle secure/non-secure interrupts, overload the plat_ic_* functions and copy GIC helper functions from arm_gic.c. Use arm_gic.c as the reference to add Tegra's GIC helper functions. Now that Tegra has its own GIC implementation, we have no use for plat_gic.c and arm_gic.c files. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 19 Jun, 2015 4 commits
-
-
danh-arm authored
Fix incorrect assertions in bl1_main()
-
danh-arm authored
Fix integer extension in mpidr_set_aff_inst()
-
Andrew Thoelke authored
The validation of the caching enable state in bl1_main() was incorrect resulting in the state not being checked. Using the right operator fixes this. Change-Id: I2a99478f420281a1dcdf365d3d4fd8394cd21b51
-
Andrew Thoelke authored
mpidr_set_aff_inst() is left shifting an int constant and an unsigned char value to construct an MPIDR. For affinity level 3 a shift of 32 would result in shifting out of the 32-bit type and have no effect on the MPIDR. These values need to be extended to unsigned long before shifting to ensure correct results for affinity level 3. Change-Id: I1ef40afea535f14cfd820c347a065a228e8f4536
-
- 18 Jun, 2015 4 commits
-
-
danh-arm authored
Add delay timer API v10
-
Ryan Harkin authored
Add SP804 delay timer support to the FVP BSP. This commit simply provides the 3 constants needed by the SP804 delay timer driver and calls sp804_timer_init() in bl2_platform_setup(). The BSP does not currently use the delay timer functions. Note that the FVP SP804 is a normal world accessible peripheral and should not be used by the secure world after transition to the normal world. Change-Id: I5f91d2ac9eb336fd81943b3bb388860dfb5f2b39 Co-authored-by: Dan Handley <dan.handley@arm.com>
-
Ryan Harkin authored
Add a delay timer driver for the ARM SP804 dual timer. This driver only uses the first timer, called timer 1 in the SP804 Technical Reference Manual (ARM DDI 0271D). To use this driver, the BSP must provide three constants: * The base address of the SP804 dual timer * The clock multiplier * The clock divider The BSP is responsible for calling sp804_timer_init(). The SP804 driver instantiates a constant timer_ops_t and calls the generic timer_init(). Change-Id: I49ba0a52bdf6072f403d1d0a20e305151d4bc086 Co-authored-by: Dan Handley <dan.handley@arm.com>
-
danh-arm authored
Reserve a Video Memory aperture in DRAM memory
-
- 17 Jun, 2015 1 commit
-
-
Ryan Harkin authored
The API is simple. The BSP or specific timer driver creates an instance of timer_ops_t, fills in the timer specific data, then calls timer_init(). The timer specific data includes a function pointer to return the timer value and a clock multiplier/divider. The ratio of the multiplier and the divider is the clock frequency in MHz. After that, mdelay() or udelay() can be called to delay execution for the specified time (milliseconds or microseconds, respectively). Change-Id: Icf8a295e1d25874f789bf28b7412156329dc975c Co-authored-by: Dan Handley <dan.handley@arm.com>
-
- 12 Jun, 2015 2 commits
-
-
Achin Gupta authored
Run bl32 on tegra v3
-
Varun Wadekar authored
This patch adds support to reserve a memory carveout region in the DRAM on Tegra SoCs. The memory controller provides specific registers to specify the aperture's base and size. This aperture can also be changed dynamically in order to re-size the memory available for DRM video playback. In case of the new aperture not overlapping the previous one, the previous aperture has to be cleared before setting up the new one. This means we do not "leak" any video data to the NS world. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 11 Jun, 2015 2 commits
-
-
Varun Wadekar authored
This patch moves the optee-dispatcher.md and tlk-dispatcher.md to docs/spd. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Varun Wadekar authored
This patch adds support to run a Trusted OS during boot time. The previous stage bootloader passes the entry point information in the 'bl32_ep_info' structure, which is passed over to the SPD. The build system expects the dispatcher to be passed as an input parameter using the 'SPD=<dispatcher>' option. The Tegra docs have also been updated with this information. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 09 Jun, 2015 4 commits
-
-
danh-arm authored
Clarify some CSS data structures
-
danh-arm authored
Fix build option 'ARM_TSP_RAM_LOCATION' in user guide
-
Sandrine Bailleux authored
For CSS based platforms, the constants MHU_SECURE_BASE and MHU_SECURE_SIZE used to define the extents of the Trusted Mailboxes. As such, they were misnamed because the mailboxes are completely unrelated to the MHU hardware. This patch removes the MHU_SECURE_BASE and MHU_SECURE_SIZE #defines. The address of the Trusted Mailboxes is now relative to the base of the Trusted SRAM. This patch also introduces a new constant, SCP_COM_SHARED_MEM_BASE, which is the address of the first memory region used for communication between AP and SCP. This is used by the BOM and SCPI protocols. Change-Id: Ib200f057b19816bf05e834d111271c3ea777291f
-
Sandrine Bailleux authored
Add a comment explaining what the SCP boot configuration information is on CSS based platforms like Juno. Also express its address relatively to the base of the Trusted SRAM rather than hard-coding it. Change-Id: I82cf708a284c8b8212933074ea8c37bdf48b403b
-
- 08 Jun, 2015 1 commit
-
-
Juan Castillo authored
The 'ARM_TSP_RAM_LOCATION_ID' option specified in the user guide corresponds to the internal definition not visible to the final user. The proper build option is 'ARM_TSP_RAM_LOCATION'. This patch fixes it. Fixes ARM-software/tf-issues#308 Change-Id: Ica8cb72c0c5e8b3503f60b5357d16698e869b1bd
-
- 05 Jun, 2015 1 commit
-
-
danh-arm authored
FVP: Correct the PSYSR_WK bit width in platform_get_entrypoint
-
- 04 Jun, 2015 3 commits
-
-
Sandrine Bailleux authored
This patch introduces a new platform build option, called PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has a programmable or fixed reset vector address. If the reset vector address is fixed then the code relies on the platform_get_entrypoint() mailbox mechanism to figure out where it is supposed to jump. On the other hand, if it is programmable then it is assumed that the platform code will program directly the right address into the RVBAR register (instead of using the mailbox redirection) so the mailbox is ignored in this case. Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308
-
Sandrine Bailleux authored
The attempt to run the CPU reset code as soon as possible after reset results in highly complex conditional code relating to the RESET_TO_BL31 option. This patch relaxes this requirement a little. In the BL1, BL3-1 and PSCI entrypoints code, the sequence of operations is now as follows: 1) Detect whether it is a cold or warm boot; 2) For cold boot, detect whether it is the primary or a secondary CPU. This is needed to handle multiple CPUs entering cold reset simultaneously; 3) Run the CPU init code. This patch also abstracts the EL3 registers initialisation done by the BL1, BL3-1 and PSCI entrypoints into common code. This improves code re-use and consolidates the code flows for different types of systems. NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION. OTHERWISE, SECONDARY CPUS WILL PANIC. Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
-
Sandrine Bailleux authored
This patch removes the FIRST_RESET_HANDLER_CALL build flag and its use in ARM development platforms. If a different reset handling behavior is required between the first and subsequent invocations of the reset handling code, this should be detected at runtime. On Juno, the platform reset handler is now always compiled in. This means it is now executed twice on the cold boot path, first in BL1 then in BL3-1, and it has the same behavior in both cases. It is also executed twice on the warm boot path, first in BL1 then in the PSCI entrypoint code. Also update the documentation to reflect this change. NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER. Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2
-
- 03 Jun, 2015 1 commit
-
-
Soby Mathew authored
This patch fixes the incorrect bit width used to extract the wakeup reason from PSYSR in platform_get_entrypoint() function. This defect did not have any observed regression. Change-Id: I42652dbffc99f5bf50cc86a5878f28d730720d9a
-
- 02 Jun, 2015 3 commits
-
-
Achin Gupta authored
Ag/tf issues#306
-
Achin Gupta authored
CSS: Extract primary cpu id using the correct bit width
-
Achin Gupta authored
Tegra soc support v4
-
- 01 Jun, 2015 1 commit
-
-
Sandrine Bailleux authored
On ARM standard platforms, snoop and DVM requests used to be enabled for the primary CPU's cluster only in the first EL3 bootloader. In other words, if the platform reset into BL1 then CCI coherency would be enabled by BL1 only, and not by BL3-1 again. However, this doesn't cater for platforms that use BL3-1 along with a non-TF ROM bootloader that doesn't enable snoop and DVM requests. In this case, CCI coherency is never enabled. This patch modifies the function bl31_early_platform_setup() on ARM standard platforms so that it always enables snoop and DVM requests regardless of whether earlier bootloader stages have already done it. There is no harm in executing this code twice. ARM Trusted Firmware Design document updated accordingly. Change-Id: Idf1bdeb24d2e1947adfbb76a509f10beef224e1c
-
- 29 May, 2015 2 commits
-
-
Varun Wadekar authored
T210 is the latest chip in the Tegra family of SoCs from NVIDIA. It is an ARM v8 dual-cluster (A57/A53) SoC, with any one of the clusters being active at a given point in time. This patch adds support to boot the Trusted Firmware on T210 SoCs. The patch also adds support to boot secondary CPUs, enter/exit core power states for all CPUs in the slow/fast clusters. The support to switch between clusters is still not available in this patch and would be available later. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Varun Wadekar authored
This patch adds driver for the 16550 UART interface. The driver is exposed as a console, which platforms can use to dump their boot/crash logs. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 27 May, 2015 1 commit
-
-
Soby Mathew authored
This patch fixes the incorrect bit width used to extract the primary cpu id from `ap_data` exported by scp at SCP_BOOT_CFG_ADDR in platform_is_primary_cpu(). Change-Id: I14abb361685f31164ecce0755fc1a145903b27aa
-
- 20 May, 2015 1 commit
-
-
danh-arm authored
Fix return type of FVP plat_arm_topology_setup
-
- 19 May, 2015 1 commit
-
-
Achin Gupta authored
The ARM GIC driver treats the entire contents of the GICC_HPPIR as the interrupt ID instead of just bits[9:0]. This could result in an SGI being treated as a Group 1 interrupt on a GICv2 system. This patch introduces a mask to retrieve only the ID from a read of GICC_HPPIR, GICC_IAR and similar registers. The value read from these registers is masked with this constant prior to use as an interrupt ID. Fixes ARM-software/tf-issues#306 Change-Id: Ie3885157de33b71df9781a41f6ef015a30c4608d
-