By default placing bl31 to addrexx 0x1000 is not good. Because this
location is used by U-Boot SPL. That's why move TF-A back to OCM where it
should be placed. BL31_BASE address exactly matches which requested address
for U-BOOT SPL boot flow.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Change-Id: I608c1b88baffec538c6ae528f057820e34971c4c
The cca chain of trust involves 3 root-of-trust public keys:
- The CCA components ROTPK.
- The platform owner ROTPK (PROTPK).
- The secure world ROTPK (SWD_ROTPK).
Use the cookie argument as a key ID for plat_get_rotpk_info() to return
the appropriate one.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: Ieaae5b0bc4384dd12d0b616596596b031179044a
- Use the development PROTPK and SWD_ROTPK if using cca CoT.
- Define a cca CoT build flag for the platform code to provide
different implementations where needed.
- When ENABLE_RME=1, CCA CoT is selected by default on Arm
platforms if no specific CoT is specified by the user.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I70ae6382334a58d3c726b89c7961663eb8571a64
When using the new cca chain of trust, a new root of trust key is needed
to authenticate the images belonging to the secure world. Provide a
development one to deploy this on Arm platforms.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I9ea7bc1c15c0c94c1021d879a839cef40ba397e3
The build system needs to drive the cert_create tool in a slightly
different manner when using the cca chain of trust.
- It needs to pass it the plat, core_swd, and swd ROT key files.
- It must now generate the cca, core_swd, and plat key certificates,
and exclude the non-relevant certificates.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I5759bfaf06913f86b47c7d04c897773bba16a807
Adding support in fconf for the cca CoT certificates for cca, core_swd,
and plat key.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I8019cbcb7ccd4de6da624aebf3611b429fb53f96
Added support for cca CoT in the fiptool by adding the cca,
core_swd, and plat key certificates.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I1ba559e188ad8c33cb0e643d7a2fc6fb96736ab9
Selection of the cca chain of trust is done through the COT build
option:
> make COT=cca
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I123c0a841f67434633a3123cc1fa3e2318585482
This chain of trust is targeted at Arm CCA solutions and defines 3
independent signing domains:
1) CCA signing domain. The Arm CCA Security Model (Arm DEN-0096.A.a) [1]
refers to the CCA signing domain as the provider of CCA components
running on the CCA platform. The CCA signing domain might be independent
from other signing domains providing other firmware blobs.
The CCA platform is a collective term used to identify all hardware and
firmware components involved in delivering the CCA security guarantee.
Hence, all hardware and firmware components on a CCA enabled system that
a Realm is required to trust.
In the context of TF-A, this corresponds to BL1, BL2, BL31, RMM and
associated configuration files.
The CCA signing domain is rooted in the Silicon ROTPK, just as in the
TBBR CoT.
2) Non-CCA Secure World signing domain. This includes SPMC (and
associated configuration file) as the expected BL32 image as well as
SiP-owned secure partitions. It is rooted in a new SiP-owned key called
Secure World ROTPK, or SWD_ROTPK for short.
3) Platform owner signing domain. This includes BL33 (and associated
configuration file) and the platform owner's secure partitions. It is
rooted in the Platform ROTPK, or PROTPK.
[1] https://developer.arm.com/documentation/DEN0096/A_a
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I6ffef3f53d710e6a2072fb4374401249122a2805
Increase the space for BL2 by 0xC000 to accommodate the increase in size
of BL2 when ARM_BL31_IN_DRAM is set.
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: Ifc99da51f2de3c152bbed1c8269dcc8b9100797a
Neoverse-V1 erratum 2294912 is a cat B erratum that applies to revisions
r0p0 - r1p1 and is still open. The workaround is to set bit[0] of
CPUACTLR2_EL1 to force PLDW/PFRM ST to behave like PLD/PRFM LD and not
cause invalidations to other PE caches.
SDEN can be found here:
https://developer.arm.com/documentation/SDEN1401781/latest
Signed-off-by: Bipin Ravi <bipin.ravi@arm.com>
Change-Id: Ia7afb4c42fe66b36fdf38a7d4281a0d168f68354
This patch splits the el2_sysregs_context_save/restore functions
into multiple functions based on features. This will allow us to
selectively save and restore EL2 context registers based on
features enabled for a particular configuration.
For now feature build flags are used to decide which registers
to save and restore. The long term plan is to dynamically check
for features that are enabled and then save/restore registers
accordingly. Splitting el2_sysregs_context_save/restore functions
into smaller assembly functions makes that task easier. For more
information please take a look at:
https://trustedfirmware-a.readthedocs.io/en/latest/design_documents/context_mgmt_rework.html
Signed-off-by: Zelalem Aweke <zelalem.aweke@arm.com>
Change-Id: I1819a9de8b70fa35c8f45568908025f790c4808c
Replay-protected memory block access is enabled by writing 0x3
to PARTITION_ACCESS (bit[2:0]). Instead the driver is using the
first boot partition, which does not provide any playback protection.
Additionally, it unconditionally activates the first boot partition,
potentially breaking boot for SoCs that consult boot partitions,
require boot ack or downgrading to an old bootloader if the first
partition happens to be the inactive one.
Also, neither enabling or disabling the RPMB observes the
PARTITION_SWITCH_TIME. As there are no in-tree users for these
functions, drop them for now until a properly functional implementation
is added. That one will likely share most code with the existing boot
partition switch, which doesn't suffer from the described issues.
Change-Id: Ia4a3f738f60a0dbcc33782f868cfbb1e1c5b664a
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
* changes:
feat(stm32mp1): extend STM32MP_EMMC_BOOT support to FIP format
refactor(mmc): replace magic value with new PART_CFG_BOOT_PARTITION_NO_ACCESS
refactor(mmc): export user/boot partition switch functions
Due to commit updating kernel yaml file [1], we need to align TF-A DT
files to what is done in kernel.
[1] c09acbc499e8 ("dt-bindings: pinctrl: use pinctrl.yaml")
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: Id717162e42d3959339d6c01883e87a9d4399f5d9
Instead of searching pinctrl node with its name, search with its
compatible. This will be necessary before pin-controller name changes
to pinctrl due to kernel yaml changes.
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: I00590414fa65e193c6a72941a372bcecac673f60
The link to commitlintrc.js file in the v2.7 changelog
is updated.
Change-Id: I24ee736180d8df72b2d831e110a9a3a80a6d9862
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Add support for new xck24 device.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
Change-Id: I913a34d5a48ea665aaa4348f573fc59566dd5a9b
This change adds "FEAT_TRBE" to be part of feature detection mechanism.
Previously feature enablement flags were of boolean type, containing
either 0 or 1. With the introduction of feature detection procedure
we now support three states for feature enablement build flags(0 to 2).
Accordingly, "ENABLE_TRBE_FOR_NS" flag is now modified from boolean
to numeric type to align with the feature detection.
Change-Id: I53d3bc8dc2f6eac63feef22dfd627f3a48480afc
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
This change adds "FEAT_BRBE" to be part of feature detection mechanism.
Previously feature enablement flags were of boolean type, possessing
either 0 or 1. With the introduction of feature detection procedure
we now support three states for feature enablement build flags(0 to 2).
Accordingly, "ENABLE_BRBE_FOR_NS" flag is now modified from boolean
to numeric type to align with the feature detection.
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: I1eb52863b4afb10b808e2f0b6584a8a210d0f38c
MISRA Violation: MISRA-C:2012 R.8.6
- Function is declared but never defined.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
Change-Id: I0df53ef4b2c91fa8ec3bf3e5491bf37dd7400685
MISRA Violation: MISRA-C:2012 R.4.6
- Using basic numerical type int rather than a typedef
that includes size and signedness information.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
Change-Id: I9fb686e7aa2b85af6dfcb7bb5f87eddf469fb85c
STM32MP_EMMC_BOOT allowed placing SSBL into the eMMC boot
partition along with FSBL. This allows atomic update of both
FSBL and SSBL at the same time. Previously, this was only
possible for the FSBL, as the eMMC layout expected by TF-A
had a single SSBL GPT partition in the eMMC user area.
TEE binaries remained in dedicated GPT partitions whether
STM32MP_EMMC_BOOT was on or off.
The new FIP format collects SSBL and TEE partitions into
a single binary placed into a GPT partition.
Extend STM32MP_EMMC_BOOT, so eMMC-booted TF-A first uses
a FIP image placed at offset 256K into the active eMMC boot
partition. If no FIP magic is detected at that offset or if
STM32MP_EMMC_BOOT is disabled, the GPT on the eMMC user area
will be consulted as before.
This allows power fail-safe update of all firmware using the
built-in eMMC boot selector mechanism, provided it fits into
the boot partition - SZ_256K. SZ_256K was chosen because it's
the same offset used with the legacy format and because it's
the size of the on-chip SRAM, where the STM32MP15x BootROM
loads TF-A into. As such, TF-A may not exceed this size limit
for existing SoCs.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Change-Id: Id7bec45652b3a289ca632d38d4b51316c5efdf8d
Disabling access to the boot partition reverts the MMC to read from the
user area. Add a macro to make this clearer.
Suggested-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Change-Id: I34a5a987980bb4690d08d255f465b11a4697ed5a
At the moment, mmc_boot_part_read_blocks() takes care to switch
to the boot partition before transfer and back afterwards.
This can introduce large overhead when reading small chunks.
Give consumers of the API more control by exporting
mmc_part_switch_current_boot() and mmc_part_switch_user().
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Change-Id: Ib641f188071bb8e0196f4af495ec9ad4a292284f
The STM32MP1 series includes STM32MP13 and STM32MP15. As some features
may be dedicated to one SoC variant, add the 2 entries in the scopes
list.
While at it, correct the title for STM32MP1.
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: I521d0e1dfdda0638ab9970c93821cf08efbd183a
With recent changes, TF-A now panics on MC-1, Avenger96 and Odyssey:
NOTICE: CPU: STM32MP157C?? Rev.B
NOTICE: Model: Linux Automation MC-1 board
ERROR: regul ldo3: max value 750 is invalid
PANIC at PC : 0x2ffeebb7
as the driver takes great offense at the content of the device
tree. The parts in question were copy-pasted from ST DTs, but
those ST DTs were fixed by commit 67d95409baae
("refactor(stm32mp1-fdts): update regulator description").
Fix the breakage by transplanting the same changes into all
remaining STM32MP1 DTs.
Change was boot-tested on MC-1, but only build tested for the
other two.
Fixes: bba9fdee589f ("feat(stm32mp1): add regulator framework compilation")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Change-Id: I143d0091625f62c313b3b71449c9ad99583d01c8
- Add security state attribute to memory and device regions.
- Rename device region reg attribution to base-address aligned with
memory regions.
- Add pages-count field to device regions.
- Refresh interrupt attributes description in device regions.
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I901f48d410edb8b10f65bb35398b80f18105e427
