- 14 Mar, 2016 1 commit
-
-
Antonio Nino Diaz authored
Added a new platform porting function plat_panic_handler, to allow platforms to handle unexpected error situations. It must be implemented in assembly as it may be called before the C environment is initialized. A default implementation is provided, which simply spins. Corrected all dead loops in generic code to call this function instead. This includes the dead loop that occurs at the end of the call to panic(). All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have been removed. Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
-
- 19 Nov, 2015 2 commits
-
-
Sandrine Bailleux authored
The default reset values for the L2 Data & Tag RAM latencies on the Cortex-A72 on Juno R2 are not suitable. This patch modifies the Juno platform reset handler to configure the right settings on Juno R2. Change-Id: I20953de7ba0619324a389e0b7bbf951b64057db8
-
Sandrine Bailleux authored
This patch splits the Juno reset handler in 4 distinct pieces: - Detection of the board revision; - Juno R0 specific handler; - Juno R1 specific handler; - Juno R2 specific handler. Depending on the board revision, the appropriate handler is called. This makes the code easier to understand and maintain. This patch is mainly cosmetic. The only functional change introduced is that the Juno platform reset handler will now spin infinitely if the board revision is not recognised. Previously, it would have assumed that it was running on Juno R1 in this case. Change-Id: I54ed77c4665085ead9d1573316c9c884d7d3ffa0
-
- 27 Oct, 2015 1 commit
-
-
David Wang authored
Currently all ARM CSS platforms which include css_helpers.S use the same strong definition of `plat_arm_calc_core_pos`. This patch allows these CSS platforms to define their own strong definition of this function. * Replace the strong definition of `plat_arm_calc_core_pos` in css_helpers.S with a utility function `css_calc_core_pos_swap_cluster` does the same thing (swaps cluster IDs). ARM CSS platforms may choose to use this function or not. * Add a Juno strong definition of `plat_arm_calc_core_pos`, which uses `css_calc_core_pos_swap_cluster`. Change-Id: Ib5385ed10e44adf6cd1398a93c25973eb3506d9d
-
- 04 Jun, 2015 1 commit
-
-
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
-
- 28 Apr, 2015 2 commits
-
-
Dan Handley authored
Move the Juno port from plat/juno to plat/arm/board/juno. Also rename some of the files so they are consistently prefixed with juno_. Update the platform makefiles accordingly. Change-Id: I0af6cb52a5fee7ef209107a1188b76a3c33a2a9f
-
Dan Handley authored
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
-
- 08 Apr, 2015 1 commit
-
-
Kévin Petit authored
In order for the symbol table in the ELF file to contain the size of functions written in assembly, it is necessary to report it to the assembler using the .size directive. To fulfil the above requirements, this patch introduces an 'endfunc' macro which contains the .endfunc and .size directives. It also adds a .func directive to the 'func' assembler macro. The .func/.endfunc have been used so the assembler can fail if endfunc is omitted. Fixes ARM-Software/tf-issues#295 Change-Id: If8cb331b03d7f38fe7e3694d4de26f1075b278fc Signed-off-by: Kévin Petit <kevin.petit@arm.com>
-
- 24 Mar, 2015 1 commit
-
-
Sandrine Bailleux authored
For Juno r0, the platform reset handler needs to: - Implement the workaround for defect #831273 - Increase the L2 Data and Tag RAM latencies for Cortex-A57. Defect #831273 does not affect Juno r1. Also, the default value for the L2 Tag RAM latency for Cortex-A57 is suitable on Juno r1. The L2 Data RAM latency for Cortex-A57 still needs to be increased, though. This patch modifies the Juno platform reset handler to detect the board revision and skip the unnecessary steps on Juno r1. The behaviour on Juno r0 is unchanged. Change-Id: I27542917223e680ef923ee860900806ffcd0357b
-
- 26 Jan, 2015 1 commit
-
-
Yatharth Kochar authored
This patch adds support to call the reset_handler() function in BL3-1 in the cold and warm boot paths when another Boot ROM reset_handler() has already run. This means the BL1 and BL3-1 versions of the CPU and platform specific reset handlers may execute different code to each other. This enables a developer to perform additional actions or undo actions already performed during the first call of the reset handlers e.g. apply additional errata workarounds. Typically, the reset handler will be first called from the BL1 Boot ROM. Any additional functionality can be added to the reset handler when it is called from BL3-1 resident in RW memory. The constant FIRST_RESET_HANDLER_CALL is used to identify whether this is the first version of the reset handler code to be executed or an overridden version of the code. The Cortex-A57 errata workarounds are applied only if they have not already been applied. Fixes ARM-software/tf-issue#275 Change-Id: Id295f106e4fda23d6736debdade2ac7f2a9a9053
-
- 04 Nov, 2014 1 commit
-
-
Soby Mathew authored
This patch reassigns the crash console on Juno and FVP to use the runtime BL3-1 console. The crash console is changed to SoC UART0 (UART2) from the previous FPGA UART0 (UART0) on Juno. In FVP, it is changed from UART0 to UART1. Fixes ARM-software/tf-issues#256 Change-Id: I7df54f86ca00ec2652c27261dd66a94c12610816
-
- 21 Aug, 2014 2 commits
-
-
Juan Castillo authored
This patch removes the PRIMARY_CPU definition hardcoded in the Juno port. Instead, the primary CPU is obtained at runtime by reading the SCC General Purpose Register 1 (GPR_1), whose value is copied by the SCP into shared memory during the boot process. Change-Id: I3981daa92eb7142250712274cf7f655b219837f5
-
Sandrine Bailleux authored
This patch adds the initial port of the ARM Trusted Firmware on the Juno development platform. This port does not support a BL3-2 image or any PSCI APIs apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno platform errata (Defect id 831273). Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
-