2013-10-25 09:08:21 +01:00
|
|
|
/*
|
2018-02-12 12:36:17 +00:00
|
|
|
* Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved.
|
2013-10-25 09:08:21 +01:00
|
|
|
*
|
2017-05-03 09:38:09 +01:00
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
2013-10-25 09:08:21 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __BL_COMMON_H__
|
|
|
|
|
#define __BL_COMMON_H__
|
|
|
|
|
|
2017-02-13 12:46:28 +00:00
|
|
|
#include <ep_info.h>
|
|
|
|
|
#include <param_header.h>
|
2018-02-21 01:16:39 +00:00
|
|
|
#include <utils_def.h>
|
2013-10-25 09:08:21 +01:00
|
|
|
|
|
|
|
|
#define UP 1
|
|
|
|
|
#define DOWN 0
|
|
|
|
|
|
|
|
|
|
/*******************************************************************************
|
2014-06-24 14:02:34 +01:00
|
|
|
* Constants to identify the location of a memory region in a given memory
|
|
|
|
|
* layout.
|
|
|
|
|
******************************************************************************/
|
|
|
|
|
#define TOP 0x1
|
|
|
|
|
#define BOTTOM !TOP
|
2013-10-25 09:08:21 +01:00
|
|
|
|
Add descriptor based image management support in BL1
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
2015-10-09 18:06:13 +01:00
|
|
|
/*
|
|
|
|
|
* The following are used for image state attributes.
|
|
|
|
|
* Image can only be in one of the following state.
|
|
|
|
|
*/
|
|
|
|
|
#define IMAGE_STATE_RESET 0
|
|
|
|
|
#define IMAGE_STATE_COPIED 1
|
|
|
|
|
#define IMAGE_STATE_COPYING 2
|
|
|
|
|
#define IMAGE_STATE_AUTHENTICATED 3
|
|
|
|
|
#define IMAGE_STATE_EXECUTED 4
|
|
|
|
|
#define IMAGE_STATE_INTERRUPTED 5
|
|
|
|
|
|
2018-02-21 01:16:39 +00:00
|
|
|
#define IMAGE_ATTRIB_SKIP_LOADING U(0x02)
|
|
|
|
|
#define IMAGE_ATTRIB_PLAT_SETUP U(0x04)
|
2014-04-15 18:08:08 +01:00
|
|
|
|
2018-02-21 01:16:39 +00:00
|
|
|
#define INVALID_IMAGE_ID U(0xFFFFFFFF)
|
Add descriptor based image management support in BL1
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
2015-10-09 18:06:13 +01:00
|
|
|
|
2015-10-02 17:56:48 +01:00
|
|
|
/*******************************************************************************
|
|
|
|
|
* Constants to indicate type of exception to the common exception handler.
|
|
|
|
|
******************************************************************************/
|
|
|
|
|
#define SYNC_EXCEPTION_SP_EL0 0x0
|
|
|
|
|
#define IRQ_SP_EL0 0x1
|
|
|
|
|
#define FIQ_SP_EL0 0x2
|
|
|
|
|
#define SERROR_SP_EL0 0x3
|
|
|
|
|
#define SYNC_EXCEPTION_SP_ELX 0x4
|
|
|
|
|
#define IRQ_SP_ELX 0x5
|
|
|
|
|
#define FIQ_SP_ELX 0x6
|
|
|
|
|
#define SERROR_SP_ELX 0x7
|
|
|
|
|
#define SYNC_EXCEPTION_AARCH64 0x8
|
|
|
|
|
#define IRQ_AARCH64 0x9
|
|
|
|
|
#define FIQ_AARCH64 0xa
|
|
|
|
|
#define SERROR_AARCH64 0xb
|
|
|
|
|
#define SYNC_EXCEPTION_AARCH32 0xc
|
|
|
|
|
#define IRQ_AARCH32 0xd
|
|
|
|
|
#define FIQ_AARCH32 0xe
|
|
|
|
|
#define SERROR_AARCH32 0xf
|
|
|
|
|
|
2014-04-15 18:08:08 +01:00
|
|
|
#ifndef __ASSEMBLY__
|
2014-05-15 18:27:15 +01:00
|
|
|
#include <cassert.h>
|
2014-06-24 14:02:34 +01:00
|
|
|
#include <stddef.h>
|
2017-02-13 12:46:28 +00:00
|
|
|
#include <stdint.h>
|
2016-06-16 14:52:04 +01:00
|
|
|
#include <types.h>
|
2017-04-10 19:45:52 +01:00
|
|
|
#include <utils_def.h> /* To retain compatibility */
|
2015-03-04 10:34:27 +00:00
|
|
|
|
2015-04-27 11:49:22 +01:00
|
|
|
/*
|
|
|
|
|
* Declarations of linker defined symbols to help determine memory layout of
|
|
|
|
|
* BL images
|
|
|
|
|
*/
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
2016-07-08 14:37:40 +01:00
|
|
|
#if SEPARATE_CODE_AND_RODATA
|
2016-06-16 14:52:04 +01:00
|
|
|
extern uintptr_t __TEXT_START__;
|
|
|
|
|
extern uintptr_t __TEXT_END__;
|
|
|
|
|
extern uintptr_t __RODATA_START__;
|
|
|
|
|
extern uintptr_t __RODATA_END__;
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
2016-07-08 14:37:40 +01:00
|
|
|
#else
|
2016-06-16 14:52:04 +01:00
|
|
|
extern uintptr_t __RO_START__;
|
|
|
|
|
extern uintptr_t __RO_END__;
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
2016-07-08 14:37:40 +01:00
|
|
|
#endif
|
|
|
|
|
|
2016-12-25 14:36:24 +00:00
|
|
|
#if defined(IMAGE_BL2)
|
2016-06-16 14:52:04 +01:00
|
|
|
extern uintptr_t __BL2_END__;
|
2016-12-25 14:36:24 +00:00
|
|
|
#elif defined(IMAGE_BL2U)
|
2016-06-16 14:52:04 +01:00
|
|
|
extern uintptr_t __BL2U_END__;
|
2016-12-25 14:36:24 +00:00
|
|
|
#elif defined(IMAGE_BL31)
|
2016-06-16 14:52:04 +01:00
|
|
|
extern uintptr_t __BL31_END__;
|
2016-12-25 14:36:24 +00:00
|
|
|
#elif defined(IMAGE_BL32)
|
2016-06-16 14:52:04 +01:00
|
|
|
extern uintptr_t __BL32_END__;
|
2015-04-27 11:49:22 +01:00
|
|
|
#endif /* IMAGE_BLX */
|
|
|
|
|
|
|
|
|
|
#if USE_COHERENT_MEM
|
2016-06-16 14:52:04 +01:00
|
|
|
extern uintptr_t __COHERENT_RAM_START__;
|
|
|
|
|
extern uintptr_t __COHERENT_RAM_END__;
|
2015-04-27 11:49:22 +01:00
|
|
|
#endif
|
|
|
|
|
|
2013-10-25 09:08:21 +01:00
|
|
|
/*******************************************************************************
|
|
|
|
|
* Structure used for telling the next BL how much of a particular type of
|
|
|
|
|
* memory is available for its use and how much is already used.
|
|
|
|
|
******************************************************************************/
|
2014-04-10 15:37:22 +01:00
|
|
|
typedef struct meminfo {
|
2016-06-16 14:52:04 +01:00
|
|
|
uintptr_t total_base;
|
2014-06-24 14:02:34 +01:00
|
|
|
size_t total_size;
|
2016-09-12 16:08:41 +01:00
|
|
|
#if !LOAD_IMAGE_V2
|
2016-06-16 14:52:04 +01:00
|
|
|
uintptr_t free_base;
|
2014-06-24 14:02:34 +01:00
|
|
|
size_t free_size;
|
2016-09-12 16:08:41 +01:00
|
|
|
#endif
|
2014-04-10 15:37:22 +01:00
|
|
|
} meminfo_t;
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2014-04-15 18:08:08 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
* Image info binary provides information from the image loader that
|
|
|
|
|
* can be used by the firmware to manage available trusted RAM.
|
|
|
|
|
* More advanced firmware image formats can provide additional
|
|
|
|
|
* information that enables optimization or greater flexibility in the
|
|
|
|
|
* common firmware code
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
typedef struct image_info {
|
|
|
|
|
param_header_t h;
|
|
|
|
|
uintptr_t image_base; /* physical address of base of image */
|
|
|
|
|
uint32_t image_size; /* bytes read from image file */
|
2016-09-12 16:08:41 +01:00
|
|
|
#if LOAD_IMAGE_V2
|
|
|
|
|
uint32_t image_max_size;
|
|
|
|
|
#endif
|
2014-04-15 18:08:08 +01:00
|
|
|
} image_info_t;
|
2013-10-25 09:08:21 +01:00
|
|
|
|
Add descriptor based image management support in BL1
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
2015-10-09 18:06:13 +01:00
|
|
|
/*****************************************************************************
|
|
|
|
|
* The image descriptor struct definition.
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
typedef struct image_desc {
|
|
|
|
|
/* Contains unique image id for the image. */
|
|
|
|
|
unsigned int image_id;
|
|
|
|
|
/*
|
|
|
|
|
* This member contains Image state information.
|
|
|
|
|
* Refer IMAGE_STATE_XXX defined above.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int state;
|
2016-02-01 11:04:46 +00:00
|
|
|
uint32_t copied_size; /* image size copied in blocks */
|
2016-01-12 10:30:59 +00:00
|
|
|
image_info_t image_info;
|
|
|
|
|
entry_point_info_t ep_info;
|
Add descriptor based image management support in BL1
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
2015-10-09 18:06:13 +01:00
|
|
|
} image_desc_t;
|
|
|
|
|
|
2016-09-12 16:08:41 +01:00
|
|
|
#if LOAD_IMAGE_V2
|
|
|
|
|
/* BL image node in the BL image loading sequence */
|
|
|
|
|
typedef struct bl_load_info_node {
|
|
|
|
|
unsigned int image_id;
|
|
|
|
|
image_info_t *image_info;
|
|
|
|
|
struct bl_load_info_node *next_load_info;
|
|
|
|
|
} bl_load_info_node_t;
|
|
|
|
|
|
|
|
|
|
/* BL image head node in the BL image loading sequence */
|
|
|
|
|
typedef struct bl_load_info {
|
|
|
|
|
param_header_t h;
|
|
|
|
|
bl_load_info_node_t *head;
|
|
|
|
|
} bl_load_info_t;
|
|
|
|
|
|
|
|
|
|
/* BL image node in the BL image execution sequence */
|
|
|
|
|
typedef struct bl_params_node {
|
|
|
|
|
unsigned int image_id;
|
|
|
|
|
image_info_t *image_info;
|
|
|
|
|
entry_point_info_t *ep_info;
|
|
|
|
|
struct bl_params_node *next_params_info;
|
|
|
|
|
} bl_params_node_t;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* BL image head node in the BL image execution sequence
|
|
|
|
|
* It is also used to pass information to next BL image.
|
|
|
|
|
*/
|
|
|
|
|
typedef struct bl_params {
|
|
|
|
|
param_header_t h;
|
|
|
|
|
bl_params_node_t *head;
|
|
|
|
|
} bl_params_t;
|
|
|
|
|
|
|
|
|
|
#else /* LOAD_IMAGE_V2 */
|
|
|
|
|
|
2014-02-19 17:18:23 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
|
* This structure represents the superset of information that can be passed to
|
|
|
|
|
* BL31 e.g. while passing control to it from BL2. The BL32 parameters will be
|
2014-04-15 18:08:08 +01:00
|
|
|
* populated only if BL2 detects its presence. A pointer to a structure of this
|
2015-12-14 09:35:25 +00:00
|
|
|
* type should be passed in X0 to BL31's cold boot entrypoint.
|
2014-04-15 18:08:08 +01:00
|
|
|
*
|
2015-12-14 09:35:25 +00:00
|
|
|
* Use of this structure and the X0 parameter is not mandatory: the BL31
|
2014-04-15 18:08:08 +01:00
|
|
|
* platform code can use other mechanisms to provide the necessary information
|
2015-12-14 09:35:25 +00:00
|
|
|
* about BL32 and BL33 to the common and SPD code.
|
2014-04-15 18:08:08 +01:00
|
|
|
*
|
2015-12-14 09:35:25 +00:00
|
|
|
* BL31 image information is mandatory if this structure is used. If either of
|
|
|
|
|
* the optional BL32 and BL33 image information is not provided, this is
|
2014-04-15 18:08:08 +01:00
|
|
|
* indicated by the respective image_info pointers being zero.
|
2014-02-19 17:18:23 +00:00
|
|
|
******************************************************************************/
|
2014-04-15 18:08:08 +01:00
|
|
|
typedef struct bl31_params {
|
|
|
|
|
param_header_t h;
|
|
|
|
|
image_info_t *bl31_image_info;
|
|
|
|
|
entry_point_info_t *bl32_ep_info;
|
|
|
|
|
image_info_t *bl32_image_info;
|
|
|
|
|
entry_point_info_t *bl33_ep_info;
|
|
|
|
|
image_info_t *bl33_image_info;
|
|
|
|
|
} bl31_params_t;
|
|
|
|
|
|
2016-09-12 16:08:41 +01:00
|
|
|
#endif /* LOAD_IMAGE_V2 */
|
2014-04-15 18:08:08 +01:00
|
|
|
|
2013-10-25 09:08:21 +01:00
|
|
|
/*******************************************************************************
|
|
|
|
|
* Function & variable prototypes
|
|
|
|
|
******************************************************************************/
|
2016-06-16 14:52:04 +01:00
|
|
|
size_t image_size(unsigned int image_id);
|
2016-09-12 16:08:41 +01:00
|
|
|
|
2016-11-08 14:27:10 +00:00
|
|
|
int is_mem_free(uintptr_t free_base, size_t free_size,
|
|
|
|
|
uintptr_t addr, size_t size);
|
|
|
|
|
|
2016-09-12 16:08:41 +01:00
|
|
|
#if LOAD_IMAGE_V2
|
|
|
|
|
|
|
|
|
|
int load_auth_image(unsigned int image_id, image_info_t *image_data);
|
|
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
2014-06-24 14:02:34 +01:00
|
|
|
int load_image(meminfo_t *mem_layout,
|
2015-04-13 17:36:19 +01:00
|
|
|
unsigned int image_id,
|
2015-05-19 11:54:12 +01:00
|
|
|
uintptr_t image_base,
|
2014-06-24 14:02:34 +01:00
|
|
|
image_info_t *image_data,
|
|
|
|
|
entry_point_info_t *entry_point_info);
|
2015-05-19 11:54:12 +01:00
|
|
|
int load_auth_image(meminfo_t *mem_layout,
|
2016-09-12 16:08:41 +01:00
|
|
|
unsigned int image_id,
|
2015-05-19 11:54:12 +01:00
|
|
|
uintptr_t image_base,
|
|
|
|
|
image_info_t *image_data,
|
|
|
|
|
entry_point_info_t *entry_point_info);
|
2016-06-16 14:52:04 +01:00
|
|
|
void reserve_mem(uintptr_t *free_base, size_t *free_size,
|
|
|
|
|
uintptr_t addr, size_t size);
|
2014-06-24 14:02:34 +01:00
|
|
|
|
2016-09-12 16:08:41 +01:00
|
|
|
#endif /* LOAD_IMAGE_V2 */
|
|
|
|
|
|
|
|
|
|
extern const char build_message[];
|
|
|
|
|
extern const char version_string[];
|
|
|
|
|
|
2015-09-28 17:03:06 +01:00
|
|
|
void print_entry_point_info(const entry_point_info_t *ep_info);
|
2018-02-12 12:36:17 +00:00
|
|
|
uintptr_t page_align(uintptr_t value, unsigned dir);
|
2015-09-28 17:03:06 +01:00
|
|
|
|
2013-10-25 09:08:21 +01:00
|
|
|
#endif /*__ASSEMBLY__*/
|
|
|
|
|
|
|
|
|
|
#endif /* __BL_COMMON_H__ */
|
