Husky is a tool for managing Git hooks within the repository itself.
Traditionally, commit hooks need to be manually installed on a per-user
basis, but Husky allows us to install these hooks either automatically
when `npm install` is invoked within the repository, or manually with
`npx husky install`.
This will become useful for us in the next few patches when we begin
introducing tools for enforcing a commit message style.
Change-Id: I64cae147e9ea910347416cfe0bcc4652ec9b4830
Signed-off-by: Chris Kay <chris.kay@arm.com>
The SCMI power domain protocol in firmware has been updated to v2.0,
thus update the corresponding version in TF-A too.
Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com>
Change-Id: If3920ff71136dce94b2780e29a47f24aa09876c0
The number of ITS have changed from 4 to 1, resulting
in GICR base address change.
Signed-off-by: Usama Arif <usama.arif@arm.com>
Change-Id: I28101f0d1faf9f3c58591b642033c3fd49a275e7
Updated the documentation with latest Mbed TLS supported
version i.e. Mbed TLS v2.26.0
Fixes available in this version of Mbed TLS mainly affect
key generation/writing and certificates writing, which
are features used in the cert_create tool.
Release notes of Mbed TLSv2.26.0 are available here:
https://github.com/ARMmbed/mbedtls/releases/tag/v2.26.0
Change-Id: Ie15ee45d878b7681e15ec4bf64d54b416a31aa2f
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
NT_FW_CONFIG file is meant to be passed from BL31 to be consumed by
BL33, fvp platforms use this to pass measured boot configuration and
the x0 register is used to pass the base address of it.
In case of hafnium used as hypervisor in normal world, hypervisor
manifest is expected to be passed from BL31 and its base address is
passed in x0 register.
As only one of NT_FW_CONFIG or hypervisor manifest base address can be
passed in x0 register and also measured boot is not required for SPM so
disable passing NT_FW_CONFIG.
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ifad9d3658f55ba7d70f468a88997d5272339e53e
* changes:
plat/st: do not keep mmc_device_info in stack
plat/intel: do not keep mmc_device_info in stack
plat/hisilicon: do not keep mmc_device_info in stack
Makefile for fiptool already prints verbose line when is (re)building
fiptool, so there is no need to print it also from top level Makefile.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I6936a508702f1bf796d17578bb1f043f06365319
Create a dedicated static struct mmc_device_info mmc_info mmc_info
instead of having this in stack.
A boot issue has been seen on some platform when applying patch [1].
[1] 13f3c5166f ("mmc:prevent accessing to the released space in case of wrong usage")
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Change-Id: I73a079715253699d903721c865d6470d58f6bd30
Create a dedicated static struct mmc_device_info mmc_info mmc_info
instead of having this in stack.
A boot issue has been seen on some platform when applying patch [1].
[1] 13f3c5166f ("mmc:prevent accessing to the released space in case of wrong usage")
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Change-Id: Id52c0be61a30f453a551385883eaf3cbe32b04b9
This reverts commit 13f3c5166f.
The STM32MP1 platform can no more boot qwith this change.
The driver will not be aware when the static struct in framework is updated.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Change-Id: Icc544e243136ee3b0067f316b71dff7dfd6526d6
Create a dedicated static struct mmc_device_info mmc_info mmc_info
instead of having this in stack.
A boot issue has been seen on some platform when applying patch [1].
[1] 13f3c5166f ("mmc:prevent accessing to the released space in case of wrong usage")
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Change-Id: If5db8857cccec2e677b16a38eb3eeb41628a264c
Calling 'make clean' in 'all' target is causing recompilation of binary
at every 'make' call, which is wrong.
Also building a new target via 'make TARGET' can cause infinite loop as
it is not defined as explicit make dependency. Dependent targets must be
specified after colon when defining target, which also prevents infinite
loops as make is able to detect these circular dependencies.
Moreover calling 'make clean' is supposed to be done by user when
configuration is changing.
So remove calling 'make clean' in 'all' target and define dependency for
'${PROJECT}' at correct place.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I70e7fd2b04b02f6a0650c82df91d58c9a4cb24d9
* changes:
drivers: marvell: comphy-a3700: Set TXDCLK_2X_SEL bit during PCIe initialization
drivers: marvell: comphy-a3700: Set mask parameter for every reg_set call
drivers: marvell: comphy-a3700: Fix configuring polarity invert bits
Since there is a secure and non-secure version of the timer registers
there is no need to preserve their context in EL3.
With that, following registers were removed from EL3 save/restore
routine:
cnthps_ctl_el2
cnthps_tval_el2
cnthps_cval_el2
cnthvs_ctl_el2
cnthvs_tval_el2
cnthvs_cval_el2
cnthp_ctl_el2
cnthp_cval_el2
cnthp_tval_el2
cnthv_ctl_el2
cnthv_cval_el2
cnthv_tval_el2
Signed-off-by: Max Shvetsov <maksims.svecovs@arm.com>
Change-Id: I6e2fc09c74a7375c4fccc11f12af4e39e6dc616b
Marvell Armada 3700 Functional Specifications, section 52.2 PCIe Link
Initialization says that TXDCLK_2X_SEL bit needs to be enabled for PCIe
Root Complex mode. Both U-Boot and Linux kernel support only Root Complex
mode. Set this bit.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: Id2a538c379b911b62597f9463b4842b7b5c24df7
The third argument of the reg_set() function has name 'mask', which
indicates that it is a mask applied to the register value which is
going to be updated. But the implementation of this function uses
this argument to clear prior value of the register, i.e. instead of
new_val = (old_val & ~mask) | (data & mask);
it does
new_val = (new_val & ~mask) | data;
(The more proper name for this function should be reg_clrsetbits(),
since internally it calls mmio_clrsetbits_32().)
To make code more readable set 'mask' argument to real mask, i.e. bits
of register values which are going to be updated.
This patch does not make any functional change, only cosmetic, due to
how 'mask' is interpreted.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: Ifa0339e79c07d1994c7971b65d966b92cb735f65
TXD_INVERT_BIT or RXD_INVERT_BIT needs to be set only in case when
appropriate polarity is inverted. Otherwise these bits should be
cleared.
Signed-off-by: Pali Rohár <pali@kernel.org>
Change-Id: I8b09fab883a7b995fd72a7d8ae6233f0fa07011b
Refine the function plat_add_sp_images_load_info() by saving the
previous node and only setting its next link when the current node is
valid. This can reduce the check for the next node and simply the
total logic.
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: I4061428bf49ef0c3816ac22aaeb2e50315531f88
The traverse flow in function plat_add_sp_images_load_info() will find
the last node in the main load info list, with its
next_load_info==NULL. However this node is still useful and should not
be overridden with SP node info.
The bug will cause below error on RDN2 for spmd enabled:
ERROR: Invalid NT_FW_CONFIG DTB passed
Fix the bug by only setting the next_load_info of the last node in the
original main node list.
Signed-off-by: Heyi Guo <guoheyi@linux.alibaba.com>
Change-Id: Icaee5da1f2d53b29fdd6085a8cc507446186fd57
Cortex A77 erratum 1946167 is a Cat B erratum that applies to revisions
<= r1p1. This erratum is avoided by inserting a DMB ST before acquire
atomic instructions without release semantics through a series of
writes to implementation defined system registers.
SDEN can be found here:
https://documentation-service.arm.com/static/600057a29b9c2d1bb22cd1be?token=
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Change-Id: I53e3b4fb7e7575ec83d75c2f132eda5ae0b4f01f
As per the new multi-console framework, updating the JTAG DCC support.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Change-Id: I77994ce387caf0d695986df3d01d414a920978d0
As per the new multi-console framework, updating the JTAG DCC support.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Change-Id: I62cfbb57ae7e454fbc91d1c54aafa6e99f9a35c8
The legacy console is gone. Re-add DCC console support based
on the multi-console framework.
Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@xilinx.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Change-Id: Ia8388721093bc1be3af40974530d7c9a9ae5f43e
* changes:
plat/sgi: allow usage of secure partions on rdn2 platform
board/rdv1mc: initialize tzc400 controllers
plat/sgi: allow access to TZC controller on all chips
plat/sgi: define memory regions for multi-chip platforms
plat/sgi: allow access to nor2 flash and system registers from s-el0
plat/sgi: define default list of memory regions for dmc620 tzc
plat/sgi: improve macros defining cper buffer memory region
plat/sgi: refactor DMC-620 error handling SMC function id
plat/sgi: refactor SDEI specific macros
Add the secure partition mmap table and the secure partition boot
information to support secure partitions on RD-N2 platform. In addition
to this, add the required memory region mapping for accessing the
SoC peripherals from the secure partition.
Signed-off-by: Omkar Anand Kulkarni <omkar.kulkarni@arm.com>
Change-Id: I2c75760d6c8c3da3ff4885599be420e924aeaf3c
A TZC400 controller is placed inline on DRAM channels and regulates
the secure and non-secure accesses to both secure and non-secure
regions of the DRAM memory. Configure each of the TZC controllers
across the Chips.
For use by secure software, configure the first chip's trustzone
controller to protect the upper 16MB of the memory of the first DRAM
block for secure accesses only. The other regions are configured for
non-secure read write access. For all the remote chips, all the DRAM
regions are allowed for non-secure read and write access.
Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
Change-Id: I809f27eccadfc23ea0ef64e2fd87f95eb8f195c1
On a multi-chip platform, the boot CPU on the first chip programs the
TZC controllers on all the remote chips. Define a memory region map for
the TZC controllers for all the remote chips and include it in the BL2
memory map table.
In addition to this, for SPM_MM enabled multi-chip platforms, increase
the number of mmap entries and xlat table counts for EL3 execution
context as well because the shared RAM regions and GIC address space of
remote chips are accessed.
Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
Change-Id: I6f0b5fd22f9f28046451e382eef7f1f9258d88f7
For multi-chip platforms, add a macro to define the memory regions on
chip numbers >1 and its associated access permissions. These memory
regions are marked with non-secure access.
Signed-off-by: Aditya Angadi <aditya.angadi@arm.com>
Change-Id: If3d6180fd8ea61f45147c39d3140d694abf06617
Allow the access of system registers and nor2 flash memory region
from s-el0. This allows the secure parititions residing at s-el0
to access these memory regions.
Signed-off-by: Thomas Abraham <thomas.abraham@arm.com>
Change-Id: I3887a86770de806323fbde0d20fdc96eec6e0c3c
Define a default DMC-620 TZC memory region configuration and use it to
specify the TZC memory regions on sgi575, rdn1edge and rde1edge
platforms. The default DMC-620 TZC memory regions are defined
considering the support for secure paritition as well.
Signed-off-by: Thomas Abraham <thomas.abraham@arm.com>
Change-Id: Iedee3e57d0d3de5b65321444da51ec990d3702db
