2015-04-13 |
Juno: Move to the new ARM SCP Messaging Interfaces
...
The communication protocol used between the AP cores and the SCP
has undergone a number of changes. This patch makes the required
modifications to the SCP Boot Protocol, SCPI Protocol and MHU
driver code in the Juno 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.
- On Juno, 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
- On Juno, 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 ARM CONNECTED COMMUNITY WEBSITE.
Change-Id: Ia5f6b95fe32401ee04a3805035748e8ef6718da7
Sandrine Bailleux
authored
on 18 Mar 2015
Dan Handley
committed
on 13 Apr 2015
|
2015-01-22 |
Remove coherent memory from the BL memory maps
...
This patch extends the build option `USE_COHERENT_MEMORY` to
conditionally remove coherent memory from the memory maps of
all boot loader stages. The patch also adds necessary
documentation for coherent memory removal in firmware-design,
porting and user guides.
Fixes ARM-Software/tf-issues#106
Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
Soby Mathew
authored
on 8 Jan 2015
Dan Handley
committed
on 22 Jan 2015
|
2014-10-14 |
Juno: Reserve some DDR-DRAM for secure use
...
This patch configures the TrustZone Controller in Juno to split
the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure
regions:
- Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are
used by the SCP for DDR retraining
- Non-Secure DDR-DRAM: remaining DRAM starting at base address
Build option PLAT_TSP_LOCATION selects the location of the secure
payload (BL3-2):
- 'tsram' : Trusted SRAM (default option)
- 'dram' : Secure region in the DDR-DRAM (set by the TrustZone
controller)
The MMU memory map has been updated to give BL2 permission to load
BL3-2 into the DDR-DRAM secure region.
Fixes ARM-software/tf-issues#233
Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b
Juan Castillo
committed
on 14 Oct 2014
|
2014-10-09 |
Juno: Use TZC-400 driver calls
...
This patch replaces direct accesses to the TZC-400 registers by the
appropiate calls to the generic driver available in the Trusted
Firmware in order to initialize the TrustZone Controller.
Functions related to the initialization of the secure memory,
like the TZC-400 configuration, have been moved to a new file
'plat_security.c'. This reorganization makes easier to set up
the secure memory from any BL stage.
TZC-400 initialization has been moved from BL1 to BL2 because BL1
does not access the non-secure memory. It is BL2's responsibility
to enable and configure the TZC-400 before loading the next BL
images.
In Juno, BL3-0 initializes some of the platform peripherals, like
the DDR controller. Thus, BL3-0 must be loaded before configuring
the TrustZone Controller. As a consequence, the IO layer
initialization has been moved to early platform initialization.
Fixes ARM-software/tf-issues#234
Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
Juan Castillo
committed
on 9 Oct 2014
|
2014-08-21 |
Rationalize UART usage among different BL stages
...
This patch changes the UART port assignment for various BL stages
so as to make it consistent on the platform ports. The BL1, BL2 and
BL3-1 now uses UART0 on the FVP port and SoC UART0 on the Juno port.
The BL3-2 uses UART2 on the FVP port and FPGA UART0 on the Juno
port.
This provides an interim fix to ARM-software/tf-issues#220 until
support is added for changing the UART port for a BL image between
cold boot and runtime.
Change-Id: Iae5faea90be3d59e41e597b34a902f93e737505a
Soby Mathew
committed
on 21 Aug 2014
|
Juno: Read primary CPU MPID from SCC GPR_1
...
This patch removes the PRIMARY_CPU definition hardcoded in the
Juno port. Instead, the primary CPU is obtained at runtime by
reading the SCC General Purpose Register 1 (GPR_1), whose value
is copied by the SCP into shared memory during the boot process.
Change-Id: I3981daa92eb7142250712274cf7f655b219837f5
Juan Castillo
authored
on 12 Aug 2014
Soby Mathew
committed
on 21 Aug 2014
|
Juno: Implement initial platform port
...
This patch adds the initial port of the ARM Trusted Firmware on the Juno
development platform. This port does not support a BL3-2 image or any PSCI APIs
apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected
Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno
platform errata (Defect id 831273).
Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
Sandrine Bailleux
authored
on 17 Jul 2014
Soby Mathew
committed
on 21 Aug 2014
|