andrius
/
arm-trusted-firmware
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
arm-trusted-firmware/plat/arm/board/fvp/fvp_io_storage.c

151 lines
3.6 KiB
C
Raw Normal View History

Implement load_image in terms of IO abstraction The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
2014-02-10 17:04:32 +00:00
/*
ARM Platorms: Load TB_FW_CONFIG in BL1 This patch modifies the bl1_platform_setup() API to load and authenticate TB_FW_CONFIG in BL1. The load address of the same is passed on to BL2 in `arg0` of entrypoint info. The fvp_io_storage.c and arm_io_storage.c also adds entries corresponding to TB_FW_CONFIG. A helper function `arm_load_tb_fw_config()` is added to load and authenticate TB_FW_CONFIG if present. Change-Id: Ie7bce667b3fad2b1a083bbcbc0a773f9f04254b1 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-01-15 14:43:42 +00:00
* Copyright (c) 2014-2018, ARM Limited and Contributors. All rights reserved.
Implement load_image in terms of IO abstraction The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
2014-02-10 17:04:32 +00:00
*
Use SPDX license identifiers To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file. NOTE: Files that have been imported by FreeBSD have not been modified. [0]: https://spdx.org/ Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
2017-05-03 09:38:09 +01:00
* SPDX-License-Identifier: BSD-3-Clause
Implement load_image in terms of IO abstraction The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
2014-02-10 17:04:32 +00:00
*/
#include <assert.h>
Sanitise includes across codebase Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3a282 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca33988b9 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-12-14 00:18:21 +00:00
#include <common/debug.h>
#include <drivers/io/io_driver.h>
#include <drivers/io/io_semihosting.h>
#include <drivers/io/io_storage.h>
#include <lib/semihosting.h>
plat/arm: Sanitise includes Use full include paths like it is done for common includes. This cleanup was started in commit d40e0e08283a ("Sanitise includes across codebase"), but it only cleaned common files and drivers. This patch does the same to Arm platforms. Change-Id: If982e6450bbe84dceb56d464e282bcf5d6d9ab9b Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2019-01-25 14:30:04 +00:00
#include <plat/arm/common/plat_arm.h>
Sanitise includes across codebase Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928d5b7 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3a282 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca33988b9 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-12-14 00:18:21 +00:00
#include <plat/common/common_def.h>
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
/* Semihosting filenames */
#define BL2_IMAGE_NAME "bl2.bin"
#define BL31_IMAGE_NAME "bl31.bin"
#define BL32_IMAGE_NAME "bl32.bin"
#define BL33_IMAGE_NAME "bl33.bin"
ARM Platorms: Load TB_FW_CONFIG in BL1 This patch modifies the bl1_platform_setup() API to load and authenticate TB_FW_CONFIG in BL1. The load address of the same is passed on to BL2 in `arg0` of entrypoint info. The fvp_io_storage.c and arm_io_storage.c also adds entries corresponding to TB_FW_CONFIG. A helper function `arm_load_tb_fw_config()` is added to load and authenticate TB_FW_CONFIG if present. Change-Id: Ie7bce667b3fad2b1a083bbcbc0a773f9f04254b1 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-01-15 14:43:42 +00:00
#define TB_FW_CONFIG_NAME "fvp_tb_fw_config.dtb"
ARM Platforms: Load HW_CONFIG in BL2 The patch adds the necessary changes to load HW_CONFIG in BL2 for ARM Platforms : 1. The load address of HW_CONFIG is specified via the `hw_config_addr` property in TB_FW_CONFIG is loaded by BL1. The `hw_config_max_size` property defines the maximum size to be expected for the HW_CONFIG. The `arm_dyn_cfg_helpers.c` and corresponding header implements utility functions to parse these DT properties defined. The `arm_dyn_cfg.c` implements wrappers to these helpers to enable them to be invoked from ARM platform layer. 2. `HW_CONFIG` is added to the `bl2_mem_params_descs[]` array which is the list of images to be loaded by BL2. 3. The `libfdt` sources are now included when BL2 is built 4. A new helper `populate_next_bl_params_config()` is introduced in desc_image_load.c to populate the subsequent executable BL images with the `hw_config` and the corresponding `fw_config` if available. The `plat_get_next_bl_params()` API for ARM platforms is modified to invoke this new helper. 5. The implementation of `bl2_early_platform_setup2()` is modified to consider `arg0` as well in addition to `arg1` passed from BL1. 6. Bump up the BL2 size for Juno to accommodate the inclusion of libfdt. Change-Id: I80f1554adec41753e0d179a5237364f04fe13a3f Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-01-15 14:45:33 +00:00
#define HW_CONFIG_NAME "hw_config.dtb"
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
#if TRUSTED_BOARD_BOOT
TBB: apply TBBR naming convention to certificates and extensions 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
2015-12-03 10:19:21 +00:00
#define TRUSTED_BOOT_FW_CERT_NAME "tb_fw.crt"
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
#define TRUSTED_KEY_CERT_NAME "trusted_key.crt"
TBB: apply TBBR naming convention to certificates and extensions 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
2015-12-03 10:19:21 +00:00
#define SOC_FW_KEY_CERT_NAME "soc_fw_key.crt"
#define TOS_FW_KEY_CERT_NAME "tos_fw_key.crt"
#define NT_FW_KEY_CERT_NAME "nt_fw_key.crt"
#define SOC_FW_CONTENT_CERT_NAME "soc_fw_content.crt"
#define TOS_FW_CONTENT_CERT_NAME "tos_fw_content.crt"
#define NT_FW_CONTENT_CERT_NAME "nt_fw_content.crt"
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
#endif /* TRUSTED_BOARD_BOOT */
Implement load_image in terms of IO abstraction The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
2014-02-10 17:04:32 +00:00
/* IO devices */
Remove variables from .data section Update code base to remove variables from the .data section, mainly by using const static data where possible and adding the const specifier as required. Most changes are to the IO subsystem, including the framework APIs. The FVP power management code is also affected. Delay initialization of the global static variable, next_image_type in bl31_main.c, until it is realy needed. Doing this moves the variable from the .data to the .bss section. Also review the IO interface for inconsistencies, using uintptr_t where possible instead of void *. Remove the io_handle and io_dev_handle typedefs, which were unnecessary, replacing instances with uintptr_t. Fixes ARM-software/tf-issues#107. Change-Id: I085a62197c82410b566e4698e5590063563ed304
2014-04-23 13:47:06 +01:00
static const io_dev_connector_t *sh_dev_con;
static uintptr_t sh_dev_handle;
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
static const io_file_spec_t sh_file_spec[] = {
[BL2_IMAGE_ID] = {
.path = BL2_IMAGE_NAME,
.mode = FOPEN_MODE_RB
},
[BL31_IMAGE_ID] = {
.path = BL31_IMAGE_NAME,
.mode = FOPEN_MODE_RB
},
[BL32_IMAGE_ID] = {
.path = BL32_IMAGE_NAME,
.mode = FOPEN_MODE_RB
},
[BL33_IMAGE_ID] = {
.path = BL33_IMAGE_NAME,
.mode = FOPEN_MODE_RB
},
ARM Platorms: Load TB_FW_CONFIG in BL1 This patch modifies the bl1_platform_setup() API to load and authenticate TB_FW_CONFIG in BL1. The load address of the same is passed on to BL2 in `arg0` of entrypoint info. The fvp_io_storage.c and arm_io_storage.c also adds entries corresponding to TB_FW_CONFIG. A helper function `arm_load_tb_fw_config()` is added to load and authenticate TB_FW_CONFIG if present. Change-Id: Ie7bce667b3fad2b1a083bbcbc0a773f9f04254b1 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-01-15 14:43:42 +00:00
[TB_FW_CONFIG_ID] = {
.path = TB_FW_CONFIG_NAME,
ARM Platforms: Load HW_CONFIG in BL2 The patch adds the necessary changes to load HW_CONFIG in BL2 for ARM Platforms : 1. The load address of HW_CONFIG is specified via the `hw_config_addr` property in TB_FW_CONFIG is loaded by BL1. The `hw_config_max_size` property defines the maximum size to be expected for the HW_CONFIG. The `arm_dyn_cfg_helpers.c` and corresponding header implements utility functions to parse these DT properties defined. The `arm_dyn_cfg.c` implements wrappers to these helpers to enable them to be invoked from ARM platform layer. 2. `HW_CONFIG` is added to the `bl2_mem_params_descs[]` array which is the list of images to be loaded by BL2. 3. The `libfdt` sources are now included when BL2 is built 4. A new helper `populate_next_bl_params_config()` is introduced in desc_image_load.c to populate the subsequent executable BL images with the `hw_config` and the corresponding `fw_config` if available. The `plat_get_next_bl_params()` API for ARM platforms is modified to invoke this new helper. 5. The implementation of `bl2_early_platform_setup2()` is modified to consider `arg0` as well in addition to `arg1` passed from BL1. 6. Bump up the BL2 size for Juno to accommodate the inclusion of libfdt. Change-Id: I80f1554adec41753e0d179a5237364f04fe13a3f Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-01-15 14:45:33 +00:00
.mode = FOPEN_MODE_RB
},
[HW_CONFIG_ID] = {
.path = HW_CONFIG_NAME,
ARM Platorms: Load TB_FW_CONFIG in BL1 This patch modifies the bl1_platform_setup() API to load and authenticate TB_FW_CONFIG in BL1. The load address of the same is passed on to BL2 in `arg0` of entrypoint info. The fvp_io_storage.c and arm_io_storage.c also adds entries corresponding to TB_FW_CONFIG. A helper function `arm_load_tb_fw_config()` is added to load and authenticate TB_FW_CONFIG if present. Change-Id: Ie7bce667b3fad2b1a083bbcbc0a773f9f04254b1 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-01-15 14:43:42 +00:00
.mode = FOPEN_MODE_RB
},
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
#if TRUSTED_BOARD_BOOT
TBB: apply TBBR naming convention to certificates and extensions 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
2015-12-03 10:19:21 +00:00
[TRUSTED_BOOT_FW_CERT_ID] = {
.path = TRUSTED_BOOT_FW_CERT_NAME,
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
.mode = FOPEN_MODE_RB
},
[TRUSTED_KEY_CERT_ID] = {
.path = TRUSTED_KEY_CERT_NAME,
.mode = FOPEN_MODE_RB
},
TBB: apply TBBR naming convention to certificates and extensions 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
2015-12-03 10:19:21 +00:00
[SOC_FW_KEY_CERT_ID] = {
.path = SOC_FW_KEY_CERT_NAME,
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
.mode = FOPEN_MODE_RB
},
TBB: apply TBBR naming convention to certificates and extensions 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
2015-12-03 10:19:21 +00:00
[TRUSTED_OS_FW_KEY_CERT_ID] = {
.path = TOS_FW_KEY_CERT_NAME,
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
.mode = FOPEN_MODE_RB
},
TBB: apply TBBR naming convention to certificates and extensions 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
2015-12-03 10:19:21 +00:00
[NON_TRUSTED_FW_KEY_CERT_ID] = {
.path = NT_FW_KEY_CERT_NAME,
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
.mode = FOPEN_MODE_RB
},
TBB: apply TBBR naming convention to certificates and extensions 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
2015-12-03 10:19:21 +00:00
[SOC_FW_CONTENT_CERT_ID] = {
.path = SOC_FW_CONTENT_CERT_NAME,
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
.mode = FOPEN_MODE_RB
},
TBB: apply TBBR naming convention to certificates and extensions 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
2015-12-03 10:19:21 +00:00
[TRUSTED_OS_FW_CONTENT_CERT_ID] = {
.path = TOS_FW_CONTENT_CERT_NAME,
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
.mode = FOPEN_MODE_RB
},
TBB: apply TBBR naming convention to certificates and extensions 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
2015-12-03 10:19:21 +00:00
[NON_TRUSTED_FW_CONTENT_CERT_ID] = {
.path = NT_FW_CONTENT_CERT_NAME,
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
.mode = FOPEN_MODE_RB
},
#endif /* TRUSTED_BOARD_BOOT */
};
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
Remove variables from .data section Update code base to remove variables from the .data section, mainly by using const static data where possible and adding the const specifier as required. Most changes are to the IO subsystem, including the framework APIs. The FVP power management code is also affected. Delay initialization of the global static variable, next_image_type in bl31_main.c, until it is realy needed. Doing this moves the variable from the .data to the .bss section. Also review the IO interface for inconsistencies, using uintptr_t where possible instead of void *. Remove the io_handle and io_dev_handle typedefs, which were unnecessary, replacing instances with uintptr_t. Fixes ARM-software/tf-issues#107. Change-Id: I085a62197c82410b566e4698e5590063563ed304
2014-04-23 13:47:06 +01:00
static int open_semihosting(const uintptr_t spec)
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
{
Remove deprecated IO return definitions Patch 7e26fe1f deprecates IO specific return definitions in favour of standard errno codes. This patch removes those definitions and its usage from the IO framework, IO drivers and IO platform layer. Following this patch, standard errno codes must be used when checking the return value of an IO function. Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
2015-11-02 10:47:01 +00:00
int result;
Remove variables from .data section Update code base to remove variables from the .data section, mainly by using const static data where possible and adding the const specifier as required. Most changes are to the IO subsystem, including the framework APIs. The FVP power management code is also affected. Delay initialization of the global static variable, next_image_type in bl31_main.c, until it is realy needed. Doing this moves the variable from the .data to the .bss section. Also review the IO interface for inconsistencies, using uintptr_t where possible instead of void *. Remove the io_handle and io_dev_handle typedefs, which were unnecessary, replacing instances with uintptr_t. Fixes ARM-software/tf-issues#107. Change-Id: I085a62197c82410b566e4698e5590063563ed304
2014-04-23 13:47:06 +01:00
uintptr_t local_image_handle;
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
/* See if the file exists on semi-hosting.*/
Migrate FVP port to use common code Major update to the FVP 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 add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
result = io_dev_init(sh_dev_handle, (uintptr_t)NULL);
Remove deprecated IO return definitions Patch 7e26fe1f deprecates IO specific return definitions in favour of standard errno codes. This patch removes those definitions and its usage from the IO framework, IO drivers and IO platform layer. Following this patch, standard errno codes must be used when checking the return value of an IO function. Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
2015-11-02 10:47:01 +00:00
if (result == 0) {
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
result = io_open(sh_dev_handle, spec, &local_image_handle);
Remove deprecated IO return definitions Patch 7e26fe1f deprecates IO specific return definitions in favour of standard errno codes. This patch removes those definitions and its usage from the IO framework, IO drivers and IO platform layer. Following this patch, standard errno codes must be used when checking the return value of an IO function. Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
2015-11-02 10:47:01 +00:00
if (result == 0) {
Rationalize console log output Fix the following issues with the console log output: * Make sure the welcome string is the first thing in the log output (during normal boot). * Prefix each message with the BL image name so it's clear which BL the output is coming from. * Ensure all output is wrapped in one of the log output macros so it can be easily compiled out if necessary. Change some of the INFO() messages to VERBOSE(), especially in the TSP. * Create some extra NOTICE() and INFO() messages during cold boot. * Remove all usage of \r in log output. Fixes ARM-software/tf-issues#231 Change-Id: Ib24f7acb36ce64bbba549f204b9cde2dbb46c8a3
2014-07-29 17:14:00 +01:00
VERBOSE("Using Semi-hosting IO\n");
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
io_close(local_image_handle);
}
}
return result;
}
Migrate FVP port to use common code Major update to the FVP 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 add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
void plat_arm_io_setup(void)
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
{
Migrate FVP port to use common code Major update to the FVP 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 add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
int io_result;
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
Migrate FVP port to use common code Major update to the FVP 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 add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
arm_io_setup();
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
Migrate FVP port to use common code Major update to the FVP 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 add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
/* Register the additional IO devices on this platform */
io_result = register_io_dev_sh(&sh_dev_con);
Remove deprecated IO return definitions Patch 7e26fe1f deprecates IO specific return definitions in favour of standard errno codes. This patch removes those definitions and its usage from the IO framework, IO drivers and IO platform layer. Following this patch, standard errno codes must be used when checking the return value of an IO function. Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
2015-11-02 10:47:01 +00:00
assert(io_result == 0);
Implement load_image in terms of IO abstraction The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
2014-02-10 17:04:32 +00:00
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
/* Open connections to devices and cache the handles */
Migrate FVP port to use common code Major update to the FVP 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 add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
io_result = io_dev_open(sh_dev_con, (uintptr_t)NULL, &sh_dev_handle);
Remove deprecated IO return definitions Patch 7e26fe1f deprecates IO specific return definitions in favour of standard errno codes. This patch removes those definitions and its usage from the IO framework, IO drivers and IO platform layer. Following this patch, standard errno codes must be used when checking the return value of an IO function. Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
2015-11-02 10:47:01 +00:00
assert(io_result == 0);
Add Firmware Image Package (FIP) driver The Firmware Image Package (FIP) driver allows for data to be loaded from a FIP on platform storage. The FVP supports loading bootloader images from a FIP located in NOR FLASH. The implemented FVP policy states that bootloader images will be loaded from a FIP in NOR FLASH if available and fall back to loading individual images from semi-hosting. NOTE: - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured to run from the BL33_BASE address. This is currently set to DRAM_BASE+128MB for the FVP. Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
2014-02-14 14:42:48 +00:00
Implement load_image in terms of IO abstraction The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
2014-02-10 17:04:32 +00:00
/* Ignore improbable errors in release builds */
(void)io_result;
}
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
/*
* FVP provides semihosting as an alternative to load images
*/
int plat_arm_get_alt_image_source(unsigned int image_id, uintptr_t *dev_handle,
uintptr_t *image_spec)
Implement load_image in terms of IO abstraction The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
2014-02-10 17:04:32 +00:00
{
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
int result = open_semihosting((const uintptr_t)&sh_file_spec[image_id]);
Remove deprecated IO return definitions Patch 7e26fe1f deprecates IO specific return definitions in favour of standard errno codes. This patch removes those definitions and its usage from the IO framework, IO drivers and IO platform layer. Following this patch, standard errno codes must be used when checking the return value of an IO function. Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
2015-11-02 10:47:01 +00:00
if (result == 0) {
Migrate FVP port to use common code Major update to the FVP 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 add support for Foundation FVP version 9.1 during FVP config setup to prevent a warning being emitted in the console. Change-Id: I254ca854987642ce09d1b924c9fd410a6e13e3bc
2015-03-19 19:17:53 +00:00
*dev_handle = sh_dev_handle;
Use numbers to identify images instead of names The Trusted firmware code identifies BL images by name. The platform port defines a name for each image e.g. the IO framework uses this mechanism in the platform function plat_get_image_source(). For a given image name, it returns the handle to the image file which involves comparing images names. In addition, if the image is packaged in a FIP, a name comparison is required to find the UUID for the image. This method is not optimal. This patch changes the interface between the generic and platform code with regard to identifying images. The platform port must now allocate a unique number (ID) for every image. The generic code will use the image ID instead of the name to access its attributes. As a result, the plat_get_image_source() function now takes an image ID as an input parameter. The organisation of data structures within the IO framework has been rationalised to use an image ID as an index into an array which contains attributes of the image such as UUID and name. This prevents the name comparisons. A new type 'io_uuid_spec_t' has been introduced in the IO framework to specify images identified by UUID (i.e. when the image is contained in a FIP file). There is no longer need to maintain a look-up table [iname_name --> uuid] in the io_fip driver code. Because image names are no longer mandatory in the platform port, the debug messages in the generic code will show the image identifier instead of the file name. The platforms that support semihosting to load images (i.e. FVP) must provide the file names as definitions private to the platform. The ARM platform ports and documentation have been updated accordingly. All ARM platforms reuse the image IDs defined in the platform common code. These IDs will be used to access other attributes of an image in subsequent patches. IMPORTANT: applying this patch breaks compatibility for platforms that use TF BL1 or BL2 images or the image loading code. The platform port must be updated to match the new interface. Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
2015-04-13 17:36:19 +01:00
*image_spec = (uintptr_t)&sh_file_spec[image_id];
}
fvp: plat_io_storage: remove duplicated code Fixes ARM-software/tf-issues#41 The policy functions for each file to be loaded were implemented by copy/pasting one method and then varying the data checked. This patch creates a generic function to check the policy based on the data stored in a table. This removes the amount of duplicated code but also makes the code simpler and more efficient. Change-Id: I1c52eacf6f18a1442dabbb33edd03d4bb8bbeae0 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
2014-02-18 17:40:24 +00:00
Implement load_image in terms of IO abstraction The modified implementation uses the IO abstraction rather than making direct semi-hosting calls. The semi-hosting driver is now registered for the FVP platform during initialisation of each boot stage where it is used. Additionally, the FVP platform includes a straightforward implementation of 'plat_get_image_source' which provides a generic means for the 'load_image' function to determine how to access the image data. Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
2014-02-10 17:04:32 +00:00
return result;
}