| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds changes in ARM platform code to use new
version of image loading.
Following are the major changes:
-Refactor the signatures for bl31_early_platform_setup()
and arm_bl31_early_platform_setup() function to use
`void *` instead of `bl31_params_t *`.
-Introduce `plat_arm_bl2_handle_scp_bl2()` to handle
loading of SCP_BL2 image from BL2.
-Remove usage of reserve_mem() function from
`arm_bl1_early_platform_setup()`
-Extract BL32 & BL33 entrypoint info, from the link list
passed by BL2, in `arm_bl31_early_platform_setup()`
-Provides weak definitions for following platform functions:
plat_get_bl_image_load_info
plat_get_next_bl_params
plat_flush_next_bl_params
bl2_plat_handle_post_image_load
-Instantiates a descriptor array for ARM platforms
describing image and entrypoint information for
`SCP_BL2`, `BL31`, `BL32` and `BL33` images.
All the above changes are conditionally compiled using the
`LOAD_IMAGE_V2` flag.
Change-Id: I5e88b9785a3df1a2b2bbbb37d85b8e353ca61049
|
|
This patch replaces all references to the SCP Firmware (BL0, BL30,
BL3-0, bl30) with the image terminology detailed in the TF wiki
(https://github.com/ARM-software/arm-trusted-firmware/wiki):
BL0 --> SCP_BL1
BL30, BL3-0 --> SCP_BL2
bl30 --> scp_bl2
This change affects code, documentation, build system, tools and
platform ports that load SCP firmware. ARM plaforms have been
updated to the new porting API.
IMPORTANT: build option to specify the SCP FW image has changed:
BL30 --> SCP_BL2
IMPORTANT: This patch breaks compatibility for platforms that use BL2
to load SCP firmware. Affected platforms must be updated as follows:
BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
BL30_BASE --> SCP_BL2_BASE
bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()
Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
|
|
This patch adds support for booting EL3 payloads on CSS platforms,
for example Juno. In this scenario, the Trusted Firmware follows
its normal boot flow up to the point where it would normally pass
control to the BL31 image. At this point, it jumps to the EL3
payload entry point address instead.
Before handing over to the EL3 payload, the data SCP writes for AP
at the beginning of the Trusted SRAM is restored, i.e. we zero the
first 128 bytes and restore the SCP Boot configuration. The latter
is saved before transferring the BL30 image to SCP and is restored
just after the transfer (in BL2). The goal is to make it appear that
the EL3 payload is the first piece of software to run on the target.
The BL31 entrypoint info structure is updated to make the primary
CPU jump to the EL3 payload instead of the BL31 image.
The mailbox is populated with the EL3 payload entrypoint address,
which releases the secondary CPUs out of their holding pen (if the
SCP has powered them on). The arm_program_trusted_mailbox() function
has been exported for this purpose.
The TZC-400 configuration in BL2 is simplified: it grants secure
access only to the whole DRAM. Other security initialization is
unchanged.
This alternative boot flow is disabled by default. A new build option
EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
payload's entry point address. The build system has been modified
such that BL31 and BL33 are not compiled and/or not put in the FIP in
this case, as those images are not used in this boot flow.
Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
|
|
The communication protocol used between the AP cores and the SCP
in CSS-based platforms like Juno has undergone a number of changes.
This patch makes the required modifications to the SCP Boot Protocol,
SCPI Protocol and MHU driver code in shared CSS platform code so that
the AP cores are still able to communicate with the SCP.
This patch focuses on the mandatory changes to make it work. The
design of this code needs to be improved but this will come in
a subsequent patch.
The main changes are:
- MHU communication protocol
- The command ID and payload size are no longer written into the
MHU registers directly. Instead, they are stored in the payload
area. The MHU registers are now used only as a doorbell to kick
off messages. Same goes for any command result, the AP has to
pick it up from the payload area.
- SCP Boot Protocol
- The BL3-0 image is now expected to embed a checksum. This
checksum must be passed to the SCP, which uses it to check the
integrity of the image it received.
- The BL3-0 image used to be transferred a block (4KB)
at a time. The SCP now supports receiving up to 128KB at a
time, which is more than the size of the BL3-0 image.
Therefore, the image is now sent in one go.
- The command IDs have changed.
- SCPI Protocol
- The size of the SCPI payload has been reduced down from 512
bytes to 256 bytes. This changes the base address of the
AP-to-SCP payload area.
- For commands that have a response, the response is the same SCPI
header that was sent, except for the size and the status, which
both must be updated appropriately. Success/Failure of a command
is determined by looking at the updated status code.
- Some command IDs have changed.
NOTE: THIS PATCH BREAKS COMPATIBILITY WITH FORMER VERSIONS OF THE SCP
FIRMWARE AND THUS REQUIRES AN UPDATE OF THIS BINARY. THE LATEST SCP
BINARY CAN BE OBTAINED FROM THE ARM CONNECTED COMMUNITY WEBSITE.
Change-Id: Ia5f6b95fe32401ee04a3805035748e8ef6718da7
|
|
This major change pulls out the common functionality from the
FVP and Juno platform ports into the following categories:
* (include/)plat/common. Common platform porting functionality that
typically may be used by all platforms.
* (include/)plat/arm/common. Common platform porting functionality
that may be used by all ARM standard platforms. This includes all
ARM development platforms like FVP and Juno but may also include
non-ARM-owned platforms.
* (include/)plat/arm/board/common. Common platform porting
functionality for ARM development platforms at the board
(off SoC) level.
* (include/)plat/arm/css/common. Common platform porting
functionality at the ARM Compute SubSystem (CSS) level. Juno
is an example of a CSS-based platform.
* (include/)plat/arm/soc/common. Common platform porting
functionality at the ARM SoC level, which is not already defined
at the ARM CSS level.
No guarantees are made about the backward compatibility of
functionality provided in (include/)plat/arm.
Also remove any unnecessary variation between the ARM development
platform ports, including:
* Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the
Juno implementation, which copies the information from BL2 memory
instead of expecting it to persist in shared memory.
* Unify the TZC configuration. There is no need to add a region
for SCP in Juno; it's enough to simply not allow any access to
this reserved region. Also set region 0 to provide no access by
default instead of assuming this is the case.
* Unify the number of memory map regions required for ARM
development platforms, although the actual ranges mapped for each
platform may be different. For the FVP port, this reduces the
mapped peripheral address space.
These latter changes will only be observed when the platform ports
are migrated to use the new common platform code in subsequent
patches.
Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
|
