- 15 Feb, 2016 1 commit
-
-
Vikram Kanigiri authored
Current code assumes `SCP_COM_SHARED_MEM_BASE` as the base address for BOM/SCPI protocol between AP<->SCP on all CSS platforms. To cater for future ARM platforms this is made platform specific. Similarly, the bit shifts of `SCP_BOOT_CONFIG_ADDR` are also made platform specific. Change-Id: Ie8866c167abf0229a37b3c72576917f085c142e8
-
- 01 Feb, 2016 1 commit
-
-
Soby Mathew authored
The debug prints used to debug translation table setup in xlat_tables.c used the `printf()` standard library function instead of the stack optimized `tf_printf()` API. DEBUG_XLAT_TABLE option was used to enable debug logs within xlat_tables.c and it configured a much larger stack size for the platform in case it was enabled. This patch modifies these debug prints within xlat_tables.c to use tf_printf() and modifies the format specifiers to be compatible with tf_printf(). The debug prints are now enabled if the VERBOSE prints are enabled in Trusted Firmware via LOG_LEVEL build option. The much larger stack size definition when DEBUG_XLAT_TABLE is defined is no longer required and the platform ports are modified to remove this stack size definition. Change-Id: I2f7d77ea12a04b827fa15e2adc3125b1175e4c23
-
- 26 Jan, 2016 7 commits
-
-
Fan Chen authored
We found sometimes mtcmos operation is too long in spm (>1ms), so update a new version to fix it. I verified with 5 hours power_LoadTest, every mtcmos control can finish in 500us (average is 100~200us). Change-Id: I47b712bf9898870f4abcecbea47e01b9786231d4 Signed-off-by: Fan Chen <fan.chen@mediatek.com>
-
Weiyi Lu authored
1. Set more wakeup source 2. Update PCM code for control logic Change-Id: I2ad06bd85bd1c75a22c838eab4cf5566c443b89a Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
-
Jimmy Huang authored
1. Add SiP calls for subsystem power on/off and check support 2. Add subsystem power control related initialization in bl31_plat_setup.c 3. Add subsystem power on/off and power ack waiting functions 4. Update PCM code for subsystem physical power control logic Change-Id: Ia0ebb1964c8f9758159bcf17c1813d76ef52cf64 Signed-off-by: yt.lee <yt.lee@mediatek.com>
-
Jimmy Huang authored
1. add power control for both big and Little cluster in MCDI 2. fix incorrect PCM_HOTPLUG_VALID_MASK in spm_hotplug.c 3. check the power status of cpus in cluster before setting the cputop power control Change-Id: Ifa85306a8bc218098667247904d281494c2f7bfe Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
-
Jimmy Huang authored
Move SPM related PLL settings to spm_boot_init in ARM TF SPM driver Change-Id: I414b896caae072570c8de33a25e06db4ae011f57 Signed-off-by: yt.lee <yt.lee@mediatek.com>
-
Jimmy Huang authored
This patch updates SPM driver settings and PCM code to fix USB remote wake up problem. Change-Id: I07a81cc64b1d226d111380580d09ae25879f4285 Signed-off-by: yt.lee <yt.lee@mediatek.com>
-
Jimmy Huang authored
This patch enables dynamic clock management control to reduce power consumption in various components. Change-Id: I8f66d9b72c8b1d70169ffe46cc361b16a0dadb77 Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
-
- 21 Jan, 2016 1 commit
-
-
Juan Castillo authored
The PL011 TRM (ARM DDI 0183G) specifies that the UART must be disabled before any of the control registers are programmed. The PL011 driver included in TF does not disable the UART, so the initialization in BL2 and BL31 is violating this requirement (and potentially in BL1 if the UART is enabled after reset). This patch modifies the initialization function in the PL011 console driver to disable the UART before programming the control registers. Register clobber list and documentation updated. Fixes ARM-software/tf-issues#300 Change-Id: I839b2d681d48b03f821ac53663a6a78e8b30a1a1
-
- 20 Jan, 2016 1 commit
-
-
Juan Castillo authored
Currently, Trusted Firmware on ARM platforms unlocks access to the timer frame registers that will be used by the Non-Secure world. This unlock operation should be done by the Non-Secure software itself, instead of relying on secure firmware settings. This patch adds a new ARM specific build option 'ARM_CONFIG_CNTACR' to unlock access to the timer frame by setting the corresponding bits in the CNTACR<N> register. The frame id <N> is defined by 'PLAT_ARM_NSTIMER_FRAME_ID'. Default value is true (unlock timer access). Documentation updated accordingly. Fixes ARM-software/tf-issues#170 Change-Id: Id9d606efd781e43bc581868cd2e5f9c8905bdbf6
-
- 14 Jan, 2016 1 commit
-
-
Soren Brinkmann authored
Migrate all direct usage of __attribute__ to usage of their corresponding macros from cdefs.h. e.g.: - __attribute__((unused)) -> __unused Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
-
- 13 Jan, 2016 1 commit
-
-
Sandrine Bailleux authored
This patch enables the ARM Cortex-A72 support in BL1 and BL31 on FVP. This allows the same TF binaries to run on a Cortex-A72 based FVP without recompiling them. Change-Id: I4eb6bbad9f0e5d8704613f7c685c3bd22b45cf47
-
- 12 Jan, 2016 1 commit
-
-
Sandrine Bailleux authored
This patch adds support for ARM Cortex-A35 processor in the CPU specific framework, as described in the Cortex-A35 TRM (r0p0). Change-Id: Ief930a0bdf6cd82f6cb1c3b106f591a71c883464
-
- 05 Jan, 2016 1 commit
-
-
Juan Castillo authored
The fip_create tool specifies images in the command line using the ARM TF naming convention (--bl2, --bl31, etc), while the cert_create tool uses the TBBR convention (--tb-fw, --soc-fw, etc). This double convention is confusing and should be aligned. This patch updates the fip_create command line options to follow the TBBR naming convention. Usage examples in the User Guide have been also updated. NOTE: users that build the FIP by calling the fip_create tool directly from the command line must update the command line options in their scripts. Users that build the FIP by invoking the main ARM TF Makefile should not notice any difference. Change-Id: I84d602630a2585e558d927b50dfde4dd2112496f
-
- 21 Dec, 2015 2 commits
-
-
Sandrine Bailleux authored
Change-Id: I6f49bd779f2a4d577c6443dd160290656cdbc59b
-
Sandrine Bailleux authored
fvp_pwr_domain_on() used to program the CPUs mailbox. This changed with commit 804040d1 but the comment documenting this code still refers to the mailbox programming. This patch removes this out-dated information. Change-Id: Ibfe2a426bdda6e71f20c83a99cb223ceca9c559c
-
- 15 Dec, 2015 1 commit
-
-
Dan Handley authored
The current FWU_SMC_UPDATE_DONE implementation incorrectly passes an unused framework cookie through to the 1st argument in the platform function `bl1_plat_fwu_done`. The intent is to allow the SMC caller to pass a cookie through to this function. This patch fixes FWU_SMC_UPDATE_DONE to pass x1 from the caller through to `bl1_plat_fwu_done`. The argument names are updated for clarity. Upstream platforms currently do not use this argument so no impact is expected. Change-Id: I107f4b51eb03e7394f66d9a534ffab1cbc09a9b2
-
- 14 Dec, 2015 3 commits
-
-
Juan Castillo authored
This patch removes the dash character from the image name, to follow the image terminology in the Trusted Firmware Wiki page: https://github.com/ARM-software/arm-trusted-firmware/wiki Changes apply to output messages, comments and documentation. non-ARM platform files have been left unmodified. Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
-
Juan Castillo authored
This patch replaces all references to the SCP Firmware (BL0, BL30, BL3-0, bl30) with the image terminology detailed in the TF wiki (https://github.com/ARM-software/arm-trusted-firmware/wiki): BL0 --> SCP_BL1 BL30, BL3-0 --> SCP_BL2 bl30 --> scp_bl2 This change affects code, documentation, build system, tools and platform ports that load SCP firmware. ARM plaforms have been updated to the new porting API. IMPORTANT: build option to specify the SCP FW image has changed: BL30 --> SCP_BL2 IMPORTANT: This patch breaks compatibility for platforms that use BL2 to load SCP firmware. Affected platforms must be updated as follows: BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID BL30_BASE --> SCP_BL2_BASE bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo() bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2() Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
-
Juan Castillo authored
This patch applies the TBBR naming convention to the certificates and the corresponding extensions defined by the CoT: * Certificate UUID names * Certificate identifier names * OID names Changes apply to: * Generic code (variables and defines) * The default certificate identifiers provided in the generic code * Build system * ARM platforms port * cert_create tool internal definitions * fip_create and cert_create tools command line options * Documentation IMPORTANT: this change breaks the compatibility with platforms that use TBBR. The platform will need to adapt the identifiers and OIDs to the TBBR naming convention introduced by this patch: Certificate UUIDs: UUID_TRUSTED_BOOT_FIRMWARE_BL2_CERT --> UUID_TRUSTED_BOOT_FW_CERT UUID_SCP_FIRMWARE_BL30_KEY_CERT --> UUID_SCP_FW_KEY_CERT UUID_SCP_FIRMWARE_BL30_CERT --> UUID_SCP_FW_CONTENT_CERT UUID_EL3_RUNTIME_FIRMWARE_BL31_KEY_CERT --> UUID_SOC_FW_KEY_CERT UUID_EL3_RUNTIME_FIRMWARE_BL31_CERT --> UUID_SOC_FW_CONTENT_CERT UUID_SECURE_PAYLOAD_BL32_KEY_CERT --> UUID_TRUSTED_OS_FW_KEY_CERT UUID_SECURE_PAYLOAD_BL32_CERT --> UUID_TRUSTED_OS_FW_CONTENT_CERT UUID_NON_TRUSTED_FIRMWARE_BL33_KEY_CERT --> UUID_NON_TRUSTED_FW_KEY_CERT UUID_NON_TRUSTED_FIRMWARE_BL33_CERT --> UUID_NON_TRUSTED_FW_CONTENT_CERT Certificate identifiers: BL2_CERT_ID --> TRUSTED_BOOT_FW_CERT_ID BL30_KEY_CERT_ID --> SCP_FW_KEY_CERT_ID BL30_CERT_ID --> SCP_FW_CONTENT_CERT_ID BL31_KEY_CERT_ID --> SOC_FW_KEY_CERT_ID BL31_CERT_ID --> SOC_FW_CONTENT_CERT_ID BL32_KEY_CERT_ID --> TRUSTED_OS_FW_KEY_CERT_ID BL32_CERT_ID --> TRUSTED_OS_FW_CONTENT_CERT_ID BL33_KEY_CERT_ID --> NON_TRUSTED_FW_KEY_CERT_ID BL33_CERT_ID --> NON_TRUSTED_FW_CONTENT_CERT_ID OIDs: TZ_FW_NVCOUNTER_OID --> TRUSTED_FW_NVCOUNTER_OID NTZ_FW_NVCOUNTER_OID --> NON_TRUSTED_FW_NVCOUNTER_OID BL2_HASH_OID --> TRUSTED_BOOT_FW_HASH_OID TZ_WORLD_PK_OID --> TRUSTED_WORLD_PK_OID NTZ_WORLD_PK_OID --> NON_TRUSTED_WORLD_PK_OID BL30_CONTENT_CERT_PK_OID --> SCP_FW_CONTENT_CERT_PK_OID BL30_HASH_OID --> SCP_FW_HASH_OID BL31_CONTENT_CERT_PK_OID --> SOC_FW_CONTENT_CERT_PK_OID BL31_HASH_OID --> SOC_AP_FW_HASH_OID BL32_CONTENT_CERT_PK_OID --> TRUSTED_OS_FW_CONTENT_CERT_PK_OID BL32_HASH_OID --> TRUSTED_OS_FW_HASH_OID BL33_CONTENT_CERT_PK_OID --> NON_TRUSTED_FW_CONTENT_CERT_PK_OID BL33_HASH_OID --> NON_TRUSTED_WORLD_BOOTLOADER_HASH_OID BL2U_HASH_OID --> AP_FWU_CFG_HASH_OID SCP_BL2U_HASH_OID --> SCP_FWU_CFG_HASH_OID NS_BL2U_HASH_OID --> FWU_HASH_OID Change-Id: I1e047ae046299ca913911c39ac3a6e123bd41079
-
- 09 Dec, 2015 11 commits
-
-
Yatharth Kochar authored
Firmware update feature needs a new FIP called `fwu_fip.bin` that includes Secure(SCP_BL2U, BL2U) and Normal world(NS_BL2U) images along with the FWU_CERT certificate in order for NS_BL1U to load the images and help the Firmware update process to complete. This patch adds the capability to support the new target `fwu_fip` which includes above mentioned FWU images in the make files. The new target of `fwu_fip` and its dependencies are included for compilation only when `TRUSTED_BOARD_BOOT` is defined. Change-Id: Ie780e3aac6cbd0edfaff3f9af96a2332bd69edbc
-
Yatharth Kochar authored
This patch adds support for Firmware update in BL2U for ARM platforms such that TZC initialization is performed on all ARM platforms and (optionally) transfer of SCP_BL2U image on ARM CSS platforms. BL2U specific functions are added to handle early_platform and plat_arch setup. The MMU is configured to map in the BL2U code/data area and other required memory. Change-Id: I57863295a608cc06e6cbf078b7ce34cbd9733e4f
-
Yatharth Kochar authored
This patch adds Firmware Update support for ARM platforms. New files arm_bl1_fwu.c and juno_bl1_setup.c were added to provide platform specific Firmware update code. BL1 now includes mmap entry for `ARM_MAP_NS_DRAM1` to map DRAM for authenticating NS_BL2U image(For both FVP and JUNO platform). Change-Id: Ie116cd83f5dc00aa53d904c2f1beb23d58926555
-
Yatharth Kochar authored
Firmware update(a.k.a FWU) feature is part of the TBB architecture. BL1 is responsible for carrying out the FWU process if platform specific code detects that it is needed. This patch adds support for FWU feature support in BL1 which is included by enabling `TRUSTED_BOARD_BOOT` compile time flag. This patch adds bl1_fwu.c which contains all the core operations of FWU, which are; SMC handler, image copy, authentication, execution and resumption. It also adds bl1.h introducing #defines for all BL1 SMCs. Following platform porting functions are introduced: int bl1_plat_mem_check(uintptr_t mem_base, unsigned int mem_size, unsigned int flags); This function can be used to add platform specific memory checks for the provided base/size for the given security state. The weak definition will invoke `assert()` and return -ENOMEM. __dead2 void bl1_plat_fwu_done(void *cookie, void *reserved); This function can be used to initiate platform specific procedure to mark completion of the FWU process. The weak definition waits forever calling `wfi()`. plat_bl1_common.c contains weak definitions for above functions. FWU process starts when platform detects it and return the image_id other than BL2_IMAGE_ID by using `bl1_plat_get_next_image_id()` in `bl1_main()`. NOTE: User MUST provide platform specific real definition for bl1_plat_mem_check() in order to use it for Firmware update. Change-Id: Ice189a0885d9722d9e1dd03f76cac1aceb0e25ed
-
Yatharth Kochar authored
As of now BL1 loads and execute BL2 based on hard coded information provided in BL1. But due to addition of support for upcoming Firmware Update feature, BL1 now require more flexible approach to load and run different images using information provided by the platform. This patch adds new mechanism to load and execute images based on platform provided image id's. BL1 now queries the platform to fetch the image id of the next image to be loaded and executed. In order to achieve this, a new struct image_desc_t was added which holds the information about images, such as: ep_info and image_info. This patch introduces following platform porting functions: unsigned int bl1_plat_get_next_image_id(void); This is used to identify the next image to be loaded and executed by BL1. struct image_desc *bl1_plat_get_image_desc(unsigned int image_id); This is used to retrieve the image_desc for given image_id. void bl1_plat_set_ep_info(unsigned int image_id, struct entry_point_info *ep_info); This function allows platforms to update ep_info for given image_id. The plat_bl1_common.c file provides default weak implementations of all above functions, the `bl1_plat_get_image_desc()` always return BL2 image descriptor, the `bl1_plat_get_next_image_id()` always return BL2 image ID and `bl1_plat_set_ep_info()` is empty and just returns. These functions gets compiled into all BL1 platforms by default. Platform setup in BL1, using `bl1_platform_setup()`, is now done _after_ the initialization of authentication module. This change provides the opportunity to use authentication while doing the platform setup in BL1. In order to store secure/non-secure context, BL31 uses percpu_data[] to store context pointer for each core. In case of BL1 only the primary CPU will be active hence percpu_data[] is not required to store the context pointer. This patch introduce bl1_cpu_context[] and bl1_cpu_context_ptr[] to store the context and context pointers respectively. It also also re-defines cm_get_context() and cm_set_context() for BL1 in bl1/bl1_context_mgmt.c. BL1 now follows the BL31 pattern of using SP_EL0 for the C runtime environment, to support resuming execution from a previously saved context. NOTE: THE `bl1_plat_set_bl2_ep_info()` PLATFORM PORTING FUNCTION IS NO LONGER CALLED BY BL1 COMMON CODE. PLATFORMS THAT OVERRIDE THIS FUNCTION MAY NEED TO IMPLEMENT `bl1_plat_set_ep_info()` INSTEAD TO MAINTAIN EXISTING BEHAVIOUR. Change-Id: Ieee4c124b951c2e9bc1c1013fa2073221195d881
-
Yatharth Kochar authored
This patch adds support for secure setup of the SoC on CSS platforms in BL1. This change is required to provide memory access to normal world images that take part in upcoming Firmware Update feature. Change-Id: Ib202fb6cb82622c1874b700637d82ea72575e6fe
-
Soby Mathew authored
This patch overrides the default weak definition of `bl31_plat_runtime_setup()` for ARM Standard platforms to specify a BL31 runtime console. ARM Standard platforms are now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and `PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required by `arm_bl31_plat_runtime_setup()` to initialize the runtime console. The system suspend resume helper `arm_system_pwr_domain_resume()` is fixed to initialize the runtime console rather than the boot console on resumption from system suspend. Fixes ARM-software/tf-issues#220 Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975
-
Soby Mathew authored
It is not ideal for BL31 to continue to use boot console at runtime which could be potentially uninitialized. This patch introduces a new optional platform porting API `bl31_plat_runtime_setup()` which allows the platform to perform any BL31 runtime setup just prior to BL31 exit during cold boot. The default weak implementation of this function will invoke `console_uninit()` which will suppress any BL31 runtime logs. On the ARM Standard platforms, there is an anomaly that the boot console will be reinitialized on resumption from system suspend in `arm_system_pwr_domain_resume()`. This will be resolved in the following patch. NOTE: The default weak definition of `bl31_plat_runtime_setup()` disables the BL31 console. To print the BL31 runtime messages, platforms must override this API and initialize a runtime console. Fixes ARM-software/tf-issues#328 Change-Id: Ibaf8346fcceb447fe1a5674094c9f8eb4c09ac4a
-
Yatharth Kochar authored
The `plat/nvidia/tegra/include/tegra_private.h` file uses resources from psci.h (for example, psci_power_state_t) but does not explicitly include psci.h. This does not currently cause a problem since psci.h is indirectly included via other headers. However, this may not be the case in future. This patch explicitly includes psci.h from tegra_private.h Change-Id: Ia991147898dbd117c1d3496a95850995a5554c05
-
Achin Gupta authored
Suport for ARM GIC v2.0 and v3.0 drivers has been reworked to create three separate drivers instead of providing a single driver that can work on both versions of the GIC architecture. These drivers correspond to the following software use cases: 1. A GICv2 only driver that can run only on ARM GIC v2.0 implementations e.g. GIC-400 2. A GICv3 only driver that can run only on ARM GIC v3.0 implementations e.g. GIC-500 in a mode where all interrupt regimes use GICv3 features 3. A deprecated GICv3 driver that operates in legacy mode. This driver can operate only in the GICv2 mode in the secure world. On a GICv3 system, this driver allows normal world to run in either GICv3 mode (asymmetric mode) or in the GICv2 mode. Both modes of operation are deprecated on GICv3 systems. ARM platforms implement both versions of the GIC architecture. This patch adds a layer of abstraction to help ARM platform ports chose the right GIC driver and corresponding platform support. This is as described below: 1. A set of ARM common functions have been introduced to initialise the GIC and the driver during cold and warm boot. These functions are prefixed as "plat_arm_gic_". Weak definitions of these functions have been provided for each type of driver. 2. Each platform includes the sources that implement the right functions directly into the its makefile. The FVP can be instantiated with different versions of the GIC architecture. It uses the FVP_USE_GIC_DRIVER build option to specify which of the three drivers should be included in the build. 3. A list of secure interrupts has to be provided to initialise each of the three GIC drivers. For GIC v3.0 the interrupt ids have to be further categorised as Group 0 and Group 1 Secure interrupts. For GIC v2.0, the two types are merged and treated as Group 0 interrupts. The two lists of interrupts are exported from the platform_def.h. The lists are constructed by adding a list of board specific interrupt ids to a list of ids common to all ARM platforms and Compute sub-systems. This patch also makes some fields of `arm_config` data structure in FVP redundant and these unused fields are removed. Change-Id: Ibc8c087be7a8a6b041b78c2c3bd0c648cd2035d8
-
Soby Mathew authored
This patch adds platform helpers for the new GICv2 and GICv3 drivers in plat_gicv2.c and plat_gicv3.c. The platforms can include the appropriate file in their build according to the GIC driver to be used. The existing plat_gic.c is only meant for the legacy GIC driver. In the case of ARM platforms, the major changes are as follows: 1. The crash reporting helper macro `arm_print_gic_regs` that prints the GIC CPU interface register values has been modified to detect the type of CPU interface being used (System register or memory mappped interface) before using the right interface to print the registers. 2. The power management helper function that is called after a core is powered up has been further refactored. This is to highlight that the per-cpu distributor interface should be initialised only when the core was originally powered down using the CPU_OFF PSCI API and not when the CPU_SUSPEND PSCI API was used. 3. In the case of CSS platforms, the system power domain restore helper `arm_system_pwr_domain_resume()` is now only invoked in the `suspend_finish` handler as the system power domain is always expected to be initialized when the `on_finish` handler is invoked. Change-Id: I7fc27d61fc6c2a60cea2436b676c5737d0257df6
-
- 04 Dec, 2015 2 commits
-
-
Varun Wadekar authored
This patch modifies the Tegra port to support the new platform APIs so that we can disable the compat layer. This includes modifications to the power management and platform topology code. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
Juan Castillo authored
This patch fixes several issues with the SP804 delay timer on FVP: * By default, the SP804 dual timer on FVP runs at 32 KHz. In order to run the timer at 35 MHz (as specified in the FVP user manual) the Overwrite bit in the SP810 control register must be set. * The CLKMULT and CLKDIV definitions are mixed up: delta(us) = delta(ticks) * T(us) = delta(ticks) / f(MHz) From the delay function: delta_us = (delta * ops->clk_mult) / ops->clk_div; Matching both expressions: 1 / f(MHz) = ops->clk_mult / ops->clk_div And consequently: f(MHz) = ops->clk_div / ops->clk_mult Which, for a 35 MHz timer, translates to: ops->clk_div = 35 ops->clk_mult = 1 * The comment in the delay timer header file has been corrected: The ratio of the multiplier and the divider is the clock period in microseconds, not the frequency. Change-Id: Iffd5ce0a5a28fa47c0720c0336d81b678ff8fdf1
-
- 02 Dec, 2015 1 commit
-
-
Juan Castillo authored
This patch adds watchdog support on ARM platforms (FVP and Juno). A secure instance of SP805 is used as Trusted Watchdog. It is entirely managed in BL1, being enabled in the early platform setup hook and disabled in the exit hook. By default, the watchdog is enabled in every build (even when TBB is disabled). A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG` has been introduced to allow the user to disable the watchdog at build time. This feature may be used for testing or debugging purposes. Specific error handlers for Juno and FVP are also provided in this patch. These handlers will be called after an image load or authentication error. On FVP, the Table of Contents (ToC) in the FIP is erased. On Juno, the corresponding error code is stored in the V2M Non-Volatile flags register. In both cases, the CPU spins until a watchdog reset is generated after 256 seconds (as specified in the TBBR document). Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
-
- 27 Nov, 2015 1 commit
-
-
Juan Castillo authored
FVP and Juno platforms include a NOR flash memory to store and load the FIP, the kernel or a ramdisk. This NOR flash is arranged as 2 x 16 bit flash devices and can be programmed using CFI standard commands. This patch provides a basic API to write single 32 bit words of data into the NOR flash. Functions to lock/unlock blocks against erase or write operations are also provided. Change-Id: I1da7ad3105b1ea409c976adc863954787cbd90d2
-
- 26 Nov, 2015 4 commits
-
-
Sandrine Bailleux authored
Normally, in the FVP port, secondary CPUs are immediately powered down if they are powered on at reset. However, when booting an EL3 payload, we need to keep them powered on as the requirement is for all CPUs to enter the EL3 payload image. This patch puts them in a holding pen instead of powering them off. Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c
-
Sandrine Bailleux authored
By default, only the primary CPU is powered on by SCP on CSS platforms. Secondary CPUs are then powered on later using PSCI calls. However, it is possible to power on more than one CPU at boot time using platform specific settings. In this case, several CPUs will enter the Trusted Firmware and execute the cold boot path code. This is currently not supported and secondary CPUs will panic. This patch preserves this behaviour in the normal boot flow. However, when booting an EL3 payload, secondary CPUs are now held in a pen until their mailbox is populated, at which point they jump to this address. Note that, since all CPUs share the same mailbox, they will all be released from their holding pen at the same time and the EL3 payload is responsible to arbitrate execution between CPUs if required. Change-Id: I83737e0c9f15ca5e73afbed2e9c761bc580735b9
-
Sandrine Bailleux authored
This patch adds support for booting EL3 payloads on CSS platforms, for example Juno. In this scenario, the Trusted Firmware follows its normal boot flow up to the point where it would normally pass control to the BL31 image. At this point, it jumps to the EL3 payload entry point address instead. Before handing over to the EL3 payload, the data SCP writes for AP at the beginning of the Trusted SRAM is restored, i.e. we zero the first 128 bytes and restore the SCP Boot configuration. The latter is saved before transferring the BL30 image to SCP and is restored just after the transfer (in BL2). The goal is to make it appear that the EL3 payload is the first piece of software to run on the target. The BL31 entrypoint info structure is updated to make the primary CPU jump to the EL3 payload instead of the BL31 image. The mailbox is populated with the EL3 payload entrypoint address, which releases the secondary CPUs out of their holding pen (if the SCP has powered them on). The arm_program_trusted_mailbox() function has been exported for this purpose. The TZC-400 configuration in BL2 is simplified: it grants secure access only to the whole DRAM. Other security initialization is unchanged. This alternative boot flow is disabled by default. A new build option EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3 payload's entry point address. The build system has been modified such that BL31 and BL33 are not compiled and/or not put in the FIP in this case, as those images are not used in this boot flow. Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
-
Sandrine Bailleux authored
This patch modifies the prototype of the bl1_plat_prepare_exit() platform API to pass the address of the entry point info structure received from BL2. The structure contains information that can be useful, depending on the kind of clean up or bookkeeping operations to perform. The weak implementation of this function ignores this argument to preserve platform backwards compatibility. NOTE: THIS PATCH MAY BREAK PLATFORM PORTS THAT ARE RELYING ON THE FORMER PROTOTYPE OF THE BL1_PLAT_PREPARE_EXIT() API. Change-Id: I3fc18f637de06c85719c4ee84c85d6a4572a0fdb
-