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
|
|
|
*/
|
|
|
|
|
|
2018-11-08 10:20:19 +00:00
|
|
|
#ifndef BL_COMMON_H
|
|
|
|
|
#define BL_COMMON_H
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2018-12-14 00:18:21 +00:00
|
|
|
#include <common/ep_info.h>
|
|
|
|
|
#include <common/param_header.h>
|
|
|
|
|
#include <lib/utils_def.h>
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2018-10-04 09:55:23 +01:00
|
|
|
#define UP U(1)
|
|
|
|
|
#define DOWN U(0)
|
2013-10-25 09:08:21 +01:00
|
|
|
|
|
|
|
|
/*******************************************************************************
|
2014-06-24 14:02:34 +01:00
|
|
|
* Constants to identify the location of a memory region in a given memory
|
|
|
|
|
* layout.
|
|
|
|
|
******************************************************************************/
|
2018-10-04 09:55:23 +01:00
|
|
|
#define TOP U(0x1)
|
|
|
|
|
#define BOTTOM U(0x0)
|
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.
|
|
|
|
|
*/
|
2018-10-04 09:55:23 +01:00
|
|
|
#define IMAGE_STATE_RESET U(0)
|
|
|
|
|
#define IMAGE_STATE_COPIED U(1)
|
|
|
|
|
#define IMAGE_STATE_COPYING U(2)
|
|
|
|
|
#define IMAGE_STATE_AUTHENTICATED U(3)
|
|
|
|
|
#define IMAGE_STATE_EXECUTED U(4)
|
|
|
|
|
#define IMAGE_STATE_INTERRUPTED U(5)
|
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
|
|
|
|
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.
|
|
|
|
|
******************************************************************************/
|
2018-10-04 09:55:23 +01:00
|
|
|
#define SYNC_EXCEPTION_SP_EL0 U(0x0)
|
|
|
|
|
#define IRQ_SP_EL0 U(0x1)
|
|
|
|
|
#define FIQ_SP_EL0 U(0x2)
|
|
|
|
|
#define SERROR_SP_EL0 U(0x3)
|
|
|
|
|
#define SYNC_EXCEPTION_SP_ELX U(0x4)
|
|
|
|
|
#define IRQ_SP_ELX U(0x5)
|
|
|
|
|
#define FIQ_SP_ELX U(0x6)
|
|
|
|
|
#define SERROR_SP_ELX U(0x7)
|
|
|
|
|
#define SYNC_EXCEPTION_AARCH64 U(0x8)
|
|
|
|
|
#define IRQ_AARCH64 U(0x9)
|
|
|
|
|
#define FIQ_AARCH64 U(0xa)
|
|
|
|
|
#define SERROR_AARCH64 U(0xb)
|
|
|
|
|
#define SYNC_EXCEPTION_AARCH32 U(0xc)
|
|
|
|
|
#define IRQ_AARCH32 U(0xd)
|
|
|
|
|
#define FIQ_AARCH32 U(0xe)
|
|
|
|
|
#define SERROR_AARCH32 U(0xf)
|
2015-10-02 17:56:48 +01:00
|
|
|
|
2014-04-15 18:08:08 +01:00
|
|
|
#ifndef __ASSEMBLY__
|
2018-12-14 00:18:21 +00:00
|
|
|
|
2014-06-24 14:02:34 +01:00
|
|
|
#include <stddef.h>
|
2017-02-13 12:46:28 +00:00
|
|
|
#include <stdint.h>
|
2015-03-04 10:34:27 +00:00
|
|
|
|
2018-12-14 00:18:21 +00:00
|
|
|
#include <lib/cassert.h>
|
2018-03-21 11:40:57 +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
|
2018-03-21 11:40:57 +00:00
|
|
|
IMPORT_SYM(unsigned long, __TEXT_START__, BL_CODE_BASE);
|
|
|
|
|
IMPORT_SYM(unsigned long, __TEXT_END__, BL_CODE_END);
|
|
|
|
|
IMPORT_SYM(unsigned long, __RODATA_START__, BL_RO_DATA_BASE);
|
|
|
|
|
IMPORT_SYM(unsigned long, __RODATA_END__, BL_RO_DATA_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
|
2018-03-21 11:40:57 +00:00
|
|
|
IMPORT_SYM(unsigned long, __RO_START__, BL_CODE_BASE);
|
|
|
|
|
IMPORT_SYM(unsigned long, __RO_END__, BL_CODE_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
|
|
|
|
|
|
2018-12-18 13:49:46 +00:00
|
|
|
#if defined(IMAGE_BL1)
|
|
|
|
|
IMPORT_SYM(uintptr_t, __BL1_ROM_END__, BL1_ROM_END);
|
|
|
|
|
|
|
|
|
|
IMPORT_SYM(uintptr_t, __BL1_RAM_START__, BL1_RAM_BASE);
|
|
|
|
|
IMPORT_SYM(uintptr_t, __BL1_RAM_END__, BL1_RAM_LIMIT);
|
|
|
|
|
#elif defined(IMAGE_BL2)
|
2018-03-21 11:40:57 +00:00
|
|
|
IMPORT_SYM(unsigned long, __BL2_END__, BL2_END);
|
2016-12-25 14:36:24 +00:00
|
|
|
#elif defined(IMAGE_BL2U)
|
2018-03-21 11:40:57 +00:00
|
|
|
IMPORT_SYM(unsigned long, __BL2U_END__, BL2U_END);
|
2016-12-25 14:36:24 +00:00
|
|
|
#elif defined(IMAGE_BL31)
|
2018-10-14 08:09:22 +01:00
|
|
|
IMPORT_SYM(unsigned long, __BL31_START__, BL31_START);
|
2018-03-21 11:40:57 +00:00
|
|
|
IMPORT_SYM(unsigned long, __BL31_END__, BL31_END);
|
2016-12-25 14:36:24 +00:00
|
|
|
#elif defined(IMAGE_BL32)
|
2018-03-21 11:40:57 +00:00
|
|
|
IMPORT_SYM(unsigned long, __BL32_END__, BL32_END);
|
2015-04-27 11:49:22 +01:00
|
|
|
#endif /* IMAGE_BLX */
|
|
|
|
|
|
2018-12-18 13:49:46 +00:00
|
|
|
/* The following symbols are only exported from the BL2 at EL3 linker script. */
|
|
|
|
|
#if BL2_IN_XIP_MEM && defined(IMAGE_BL2)
|
|
|
|
|
extern uintptr_t __BL2_ROM_END__;
|
|
|
|
|
#define BL2_ROM_END (uintptr_t)(&__BL2_ROM_END__)
|
|
|
|
|
|
|
|
|
|
extern uintptr_t __BL2_RAM_START__;
|
|
|
|
|
extern uintptr_t __BL2_RAM_END__;
|
|
|
|
|
#define BL2_RAM_BASE (uintptr_t)(&__BL2_RAM_START__)
|
|
|
|
|
#define BL2_RAM_LIMIT (uintptr_t)(&__BL2_RAM_END__)
|
|
|
|
|
#endif /* BL2_IN_XIP_MEM */
|
|
|
|
|
|
2018-03-21 11:40:57 +00:00
|
|
|
/*
|
|
|
|
|
* The next 2 constants identify the extents of the coherent memory region.
|
|
|
|
|
* These addresses are used by the MMU setup code and therefore they must be
|
|
|
|
|
* page-aligned. It is the responsibility of the linker script to ensure that
|
|
|
|
|
* __COHERENT_RAM_START__ and __COHERENT_RAM_END__ linker symbols refer to
|
|
|
|
|
* page-aligned addresses.
|
|
|
|
|
*/
|
2015-04-27 11:49:22 +01:00
|
|
|
#if USE_COHERENT_MEM
|
2018-03-21 11:40:57 +00:00
|
|
|
IMPORT_SYM(unsigned long, __COHERENT_RAM_START__, BL_COHERENT_RAM_BASE);
|
|
|
|
|
IMPORT_SYM(unsigned long, __COHERENT_RAM_END__, BL_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;
|
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
|
|
|
uint32_t image_max_size;
|
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
|
|
|
/* 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;
|
|
|
|
|
|
2013-10-25 09:08:21 +01:00
|
|
|
/*******************************************************************************
|
|
|
|
|
* Function & variable prototypes
|
|
|
|
|
******************************************************************************/
|
2018-05-04 11:18:26 +01:00
|
|
|
size_t get_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
|
|
|
int load_auth_image(unsigned int image_id, image_info_t *image_data);
|
|
|
|
|
|
2018-03-26 12:43:37 +01:00
|
|
|
#if TRUSTED_BOARD_BOOT && defined(DYN_DISABLE_AUTH)
|
|
|
|
|
/*
|
|
|
|
|
* API to dynamically disable authentication. Only meant for development
|
|
|
|
|
* systems.
|
|
|
|
|
*/
|
|
|
|
|
void dyn_disable_auth(void);
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-09-12 16:08:41 +01:00
|
|
|
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
|
|
|
|
2018-10-19 16:44:18 +01:00
|
|
|
struct mmap_region;
|
|
|
|
|
|
|
|
|
|
void setup_page_tables(const struct mmap_region *bl_regions,
|
|
|
|
|
const struct mmap_region *plat_regions);
|
|
|
|
|
|
2013-10-25 09:08:21 +01:00
|
|
|
#endif /*__ASSEMBLY__*/
|
|
|
|
|
|
2018-11-08 10:20:19 +00:00
|
|
|
#endif /* BL_COMMON_H */
|
