Even though the FVP and FPGA are meant to be identical their RoS's (rest
of system) are different. Factor these in so the device tree works for
both. The differences are:
* addresses of GIC and UART
* displays (FPGA uses 4k)
* ethernet devices and SD card (it's non removable on the FPGA)
Their frequencies are also different. The FVP simulates certain
frequencies but isn't very sensitive when we disregard them. To keep
code similar, update them with the FPGA values. This keeps working on
FVP even if slightly incorrect.
Also add an option for the DPU to either use fixed clocks or SCMI set
clocks, hidden behind a flag. This is useful during bringup and because
SCMI may not necessarily work on FPGA.
Co-developed-by: Kshitij Sisodia <kshitij.sisodia@arm.com>
Co-developed-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>
Co-developed-by: Usama Arif <usama.arif@arm.com>
Co-developed-by: Angel Rodriguez Garcia <angel.rodriguezgarcia@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: Ic7a4bfc302673a3a6571757e23a9e6184fba2a13
TC is getting an FPGA port alongside the FVP. It is meant to be
identical, but the core configurations on TC2 differ (there are 14 in an
odd arrangement).
Introduce these differences and gate them behind a new TARGET_FLAVOUR
flag which defaults to FVP for compatibility.
While updating CPUs, it's a good time to do TC3 too. It has different
cores in a different configuration again, so it needs different capacity
values. Those have been derived using GeekBench 6.0 ST on the FPGA.
Finally GPU and DPU power domains are 1 above the CPUs so make that
relative.
In the end, the big/mid/little configurations are:
* TC2 FVP: 1/3/4
* TC2 FPGA: 2/3/5/4 (the 3 is a big "min" core)
* TC3 both: 2/4/2 (with new capacities)
Co-developed-by: Tintu Thomas <tintu.thomas@arm.com>
Co-developed-by: Kshitij Sisodia <kshitij.sisodia@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I3c3a10d6727f5010fd9026a404df27e9262dff6b
TC3 is a little different from TC2:
* new address for its second DRAM bank
* new CPUs
* a few interrupts have changed
* new SCP MHU base address.
* utility space address (needed for MPAM) is different
* no CMN (and therefore cmn-pmu)
* the uart clock is different
This requires the dts to be different between revisions for the first
time. Introduce a tc_vers.dtsi that includes only definitions for things
that are different.
Signed-off-by: Tintu Thomas <tintu.thomas@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I2940d87a69ea93502b7f5a22a539e4b70a63e827
In some occasions it is useful to boot with the rest of system (RoS)
disabled. With no RoS there's no flash so we need to put images
somewhere and that's in the DRAM1 bank. If we want to access it it needs
to be mapped to memory.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I45e0fbb016e8f615d41b6ad9da0d1e7b466ece72
Firmware update is a trusted service secure partition that implements
the PSA firmware update specification. It executes in the secure world
in total compute platform. To make it fit with Op-tee we need to reduce
its available memory.
Also, reserve 4 MB for stmm communication used for firmware update.
The firmware update secure partition and u-boot communicates using the
stmm communication layer and it needs a dedicated memory region.
Co-developed-by: Sergio Alves <sergio.dasilvalves@arm.com>
Co-developed-by: Davidson K <davidson.kumaresan@arm.com>
Signed-off-by: Tudor Cretu <tudor.cretu@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I0427549845f6c7650b8ef4e450d387fe9702a847
The manifests describe the same hardware layout with only the secure
partitions being different. Factor it out so it can be shared and only
add the VM information separately.
This has some deliberate side effects: the test configuration gets the
full secure memory address space and drops the 0x7000000 region as that
was accidentally copied over from the FVP platform and doesn't apply to
TC.
Also optee unconditionally gets the smaller mem_size as it's been
working fine and simplifies the manifest.
Small touch up is that mem_size-s are now in hex but otherwise the same
number.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: Iea23f9769235eea32afa374952b9a0e4f6d3e9a1
Also increase add PLAT_ARM_SP_MAX_SIZE to override the default
ARM_SP_MAX_SIZE to support Trusty image and move OPTEE_SP_FW_CONFIG
documentation to build-internals.rst as it's not externally set-able.
Signed-off-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: Ief90ae9113d32265ee2200f35f3e517b7b9a4bea
There are requirements in which the MPMM and Auxiliary AMU counters have
to be disabled. Hence removing the "override" here which helps in
disabling them during the build.
Change-Id: I2c0a808d5d9968082a508a9206e34f7a57f2e33a
Signed-off-by: Davidson K <davidson.kumaresan@arm.com>
On FVP's the default SRAM size is severly restrictive. However, more
recent models support larger SRAM configurations (> 256 Kb). We
introduced the flag FVP_TRUSTED_SRAM_SIZE to allow for TF to handle
different configurations.
BL31 automatically benefits from this optimisation since it starts from
the bottom of shared memory, and runs up to the end of SRAM. Increase
the size of all BL2 builds in proportion to FVP_TRUSTED_SRAM_SIZE so
that BL2 covers around a third of SRAM.
Change-Id: Idf37e8cb86507ea44b97ac8b3b90fffefe13f57a
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Increase the size of BL2 to build TC2 with GPT support enabled
and a config modification of mbedTLS.
Change-Id: I6d2f466144f2bbffd3387bc40bc86ab733febce1
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Update the TC's platform test Makefile and related common definitions
to correspond to newer TF-M code (commit hash: 4ab7a20).
Change-Id: I6ef3effe194a780a0533f9c0c2eab9d0f4efc1fc
Signed-off-by: David Vincze <david.vincze@arm.com>
Remap TF-A console logs from SoC UART2 (S1 terminal) to CSS
secure (UART1_AP terminal) and Linux logs from SoC UART2
(S1 terminal) to CSS non-secure (UART_AP terminal) to align
with the latest FVP TC2 model (version 11.23/17).
Change-Id: I7206e64b65346bfdcc48d6acd3792b436041e45f
Signed-off-by: Annam Sai Manisha <annam.saimanisha@arm.com>
Add a second SDS region on the TC platform for communication with RSS.
RSS needs to share data with AP during early boot over shared memory
to support DPE. Reserve a memory region right after the SCMI secure
payload areas from unused memory.
Change-Id: I3a3a6ea5ce76531595c88754418602133a283c42
Signed-off-by: David Vincze <david.vincze@arm.com>
Update SDS driver calls to align with recent
changes [1] of the SDS driver.
- The driver now requires us to explicitly pass
the SDS region id to act on.
- Implement plat_sds_get_regions() platform function
which is used by the driver to get SDS region
information per platform.
[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/24609/
Change-Id: I3447855fbe7427376d5f7aa0ba7356fe2f14d567
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Signed-off-by: David Vincze <david.vincze@arm.com>
Update SDS driver calls to align with recent
changes [1] of the SDS driver.
- The driver now requires us to explicitly pass
the SDS region id to act on.
- Implement plat_sds_get_regions() platform function
which is used by the driver to get SDS region
information per platform.
[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/24609/
Change-Id: I942599edb4d9734c0455f67c6b5673aace62e444
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Signed-off-by: David Vincze <david.vincze@arm.com>
Update SDS driver calls to align with recent
changes [1] of the SDS driver.
- The driver now requires us to explicitly pass
the SDS region id to act on.
- Implement plat_sds_get_regions() platform function
which is used by the driver to get SDS region
information per platform.
[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/24609/
Change-Id: I67aebfe0e2a82d1f5fc2d26653698a552350b387
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Signed-off-by: David Vincze <david.vincze@arm.com>
Update SDS driver calls to align with recent
changes [1] of the SDS driver.
- The driver now requires us to explicitly pass
the SDS region id to act on.
- Implement plat_sds_get_regions() platform function
which is used by the driver to get SDS region
information per platform.
[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/24609/
Change-Id: Ifa4595278e094849bea2796ead58e85de98baaf9
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Signed-off-by: David Vincze <david.vincze@arm.com>
Remove any residual RSS usage in the FVP platform, complementing the
changes made in commit dea307fd6c.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I9ced272503456361610ec0c7783d270349233926
qemu/qemu_sbsa platforms support wide selection of cpu cores. From
Cortex-A57 (v8.0) to Neoverse-N2 (v9.0) one. Only the last one (and
'max' which supports everything possible) supports FEAT_SB.
Runtime check for ENABLE_FEAT_SB does not work in our case and we want
to have working platform.
Change-Id: Ic27d5af20ad76ae44c4211d28694e91ec62bddc1
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Essentially revert [1] to permit specifying SME support along with
SPD=spmd on FVP platform.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/20764
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: Iab15d5a4c966b9f5b265ccde6711765e242abeaa
The toolchain refactor change introduces the `${toolchain}-${tool}-id`
variables, which provide identifiers for all of the toolchain tools used
by the build system. This change replaces the various conditions that
are in use to identify these tools based on the path with a standard set
of comparisons against these new identifier variables.
Change-Id: Ib60e592359fa6e415c19a012e68d660f87436ca7
Signed-off-by: Chris Kay <chris.kay@arm.com>
This change migrates the values of `CC`, `CPP`, `AS` and other toolchain
variables to the new `$(toolchain)-$(tool)` variables, which were
introduced by the toolchain refactor patch. These variables should be
equivalent to the values that they're replacing.
Change-Id: I644fe4ce82ef1894bed129ddb4b6ab94fb04985d
Signed-off-by: Chris Kay <chris.kay@arm.com>
This change refactors how we identify the toolchain, with the ultimate
aim of eventually cleaning up the various mechanisms that we employ to
configure default tools, identify the tools in use, and configure
toolchain flags.
To do this, we introduce three new concepts in this change:
- Toolchain identifiers,
- Tool class identifiers, and
- Tool identifiers.
Toolchain identifiers identify a configurable chain of tools targeting
one platform/machine/architecture. Today, these are:
- The host machine, which receives the `host` identifier,
- The AArch32 architecture, which receives the `aarch32` identifier, and
- The AArch64 architecture, which receivs the `aarch64` identifier.
The tools in a toolchain may come from different vendors, and are not
necessarily expected to come from one single toolchain distribution. In
most cases it is perfectly valid to mix tools from different toolchain
distributions, with some exceptions (notably, link-time optimization
generally requires the compiler and the linker to be aligned).
Tool class identifiers identify a class (or "role") of a tool. C
compilers, assemblers and linkers are all examples of tool classes.
Tool identifiers identify a specific tool recognized and supported by
the build system. Every tool that can make up a part of a toolchain must
receive a tool identifier.
These new identifiers can be used to retrieve information about the
toolchain in a more standardized fashion.
For example, logic in a Makefile that should only execute when the C
compiler is GNU GCC can now check the tool identifier for the C compiler
in the relevant toolchain:
ifeq ($($(ARCH)-cc-id),gnu-gcc)
...
endif
Change-Id: Icc23e43aaa32f4fd01d8187c5202f5012a634e7c
Signed-off-by: Chris Kay <chris.kay@arm.com>
Added SiP calls to FVP platform to protect/unprotect a
memory range.
These leverage rme features to change the PAS of a given
memory range from non-secure to secure.
The mentioned call is leveraged by the SPMC in the memory
sharing flow, when memory is shared from the normal world
onto the secure world.
More details in the SPM related patches.
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: Iaf15d8603a549d247ffb1fc14c16bfb94d0e178a
Add minimal compilation step when enabling STM32MP_USB_PROGRAMMER flag
on STM32MP2. Add DWL_BUFFER_BASE in platform.mk and the compilation
of the new file plat/st/stm32mp2/stm32mp2_usb_dfu.c (just stubs for
the moment).
Signed-off-by: Pankaj Dev <pankaj.dev@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: I8891ff23ddc3d40d7477ada3e49e439dd8af8316
As these definitions will be the same for STM32MP1 and STM32MP2, move
PLATFORM_MTD_MAX_PAGE_SIZE and DWL_BUFFER_SIZE macro definition to the
file: plat/st/common/include/stm32mp_common.h
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: I480669d009d15fec753298f47b136e34fa240132
PLAT_STM32MP_NS_IMAGE_OFFSET and PLAT_EMMC_BOOT_SSBL_OFFSET macros should
have been removed with patch [1].
[1] 981b9dcb87 ("refactor(stm32mp1): remove STM32MP_USE_STM32IMAGE")
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: Ice98c43c0257041226525199be06134fde8466c5
ti_sci_get_revision handles getting the firmware version and ti_sci_init
is just a wrapper around it with no added benefit.
Refactor the ti_sci_get_revision to give the version information and
remove ti_sci_init wrapper.
Change-Id: I39184af5b00bedc8b9220533f1ddac3b6672d2f1
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
spe_disable function, disables profiling and flushes all the buffers and
hence needs to be called on power-off/suspend path.
It needs to be invoked as SPE feature writes to memory as part of
regular operation and not disabling before exiting coherency
could potentially cause issues.
Currently, this is handled only for the FVP. Other platforms need
to replicate this behaviour and is covered as part of this patch.
Calling it from generic psci library code, before the platform specific
actions to turn off the CPUs, will make it applicable for all the
platforms which have ported the PSCI library.
Change-Id: I90b24c59480357e2ebfa3dfc356c719ca935c13d
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
When creating the Arm FPGA platform, we had plenty of memory available,
so assigned a generous four PEs per core for the potential CPU topology.
In reality we barely see implementations with two PEs per core, and
didn't have four at all so far.
With some design changes we now include more data per CPU type, and
since the Arm FPGA build supports many cores (and determines the correct
one at runtime), we run out of memory with certain build options.
Since we don't really need four PEs per core, just halve that number, to
reduce our memory footprint without sacrificing functionality.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Change-Id: Ieb37ccc9f362b10ff0ce038f72efca21512a71cb
This setup helps to mimic an end-to-end RAS handling flow inspired
by real world design with a dedicated RAS secure partition managed
by SPMC.
The detailed steps are documented as comments in the relevant source
files introduced in this patch.
Change-Id: I97737c66649f6e49840fa0bdf2e0af4fb6b08fc7
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>
Initialize generic delay timer to enable its use to insert delays
in execution paths as required.
Change-Id: I52232796f20d9692f0115d5e5395451a54b489c6
Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>
The trail bytes from the secure proxy driver were being overwritten,
increase the count each time to not overwrite the existing data and not
get the end data corrupted from secure proxy.
Fixes: d76fdd33e0 ("ti: k3: drivers: Add Secure Proxy driver")
Change-Id: I8e23f8b6959da886d6ab43049746f78765ae1766
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
When building TF-A (with SPMD support) with ARM_ARCH_MAJOR=8/
ARCH_ARCH_MINOR=8 options, this forces the -march=armv8.8-a compiler
option. In this condition, the compiler optimises statement [1] into
a store pair to an unaligned address resulting to a supposedly alignment
fault. With -march=armv8.7-a and earlier the compiler resolves with a
memcpy. Replacing this line by an explicit memcpy masks out the issue.
Prefer using the plain struct uuid in place of the uuid_helper union
for further clarity.
[1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/
plat/arm/common/fconf/arm_fconf_sp.c?h=v2.10#n77
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I509b7bc50c7c4a894885d24dc8279d0fe634e8f2
This feature provides support to context save the
SCXTNUM_ELx register. FEAT_CSV2_3 implies the implementation
of FEAT_CSV2_2. FEAT_CSV2_3 is supported in AArch64 state only
and is an optional feature in Arm v8.0 implementations.
This patch adds feature detection for v8.9 feature FEAT_CSV2_3,
adds macros for ID_AA64PFR0_EL1.CSV2 bits [59:56] for detecting
FEAT_CSV2_3 and macro for ENABLE_FEAT_CSV2_3.
Change-Id: Ida9f31e832b5f11bd89eebd6cc9f10ddad755c14
Signed-off-by: Sona Mathew <sonarebecca.mathew@arm.com>
In i.MX8MM/MQ it is possible to have two copies of bootloader in
SD/eMMC and switch between them. The switch is triggered either
by the BootROM in case the bootloader image is faulty OR can be
enforced by the user, and there is API introduced in
9ce232fe ("feat(plat/imx8m): add SiP call for secondary boot"),
which leverages this SoC feature.
However neither i.MX8MP nor i.MX8MN have a dedicated bit
which indicates what boot image set is currently booted.
According to AN12853 [1] "i.MX ROMs Log Events", it is
possible to determine whether fallback event occurred
by parsing the BootROM event log. In case ROM event ID 0x51 is
present,fallback event did occur and secondary boot image was booted.
Knowing which boot image was booted might be useful for reliable
bootloader A/B updates, detecting fallback event might be used for
making decision if boot firmware rollback is required.
This patche introduces implementation, that replicates the same
imx_src_handler() behaviour as on i.MX8MM/MQ SoCs.
The code is based on original U-Boot implementation [2].
[1]: https://www.nxp.com/webapp/Download?colCode=AN12853
[2]: a5ee05cf71
Change-Id: I9a4c5229aa0e53fa23b5261459da99cb3ce6bdbe
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
As of now, GPT setup is being handled from BL2 for plat/arm platforms.
However, for platforms having a separate entity to load firmware images,
it is possible for BL31 to setup the GPT. In order to address this
concern, move the GPT setup implementation from arm_bl2_setup.c file to
arm_common.c. Additionally, rename the API from arm_bl2_gpt_setup to
arm_gpt_setup to make it boot stage agnostic.
Signed-off-by: Rohit Mathew <Rohit.Mathew@arm.com>
Change-Id: I35d17a179c8746945c69db37fd23d763a7774ddc
For RME-enabled platforms, initializing L0 and L1 tables and enabling
GPC checks is necessary. For systems using BL2 to load firmware images,
the GPT initialization has to be done in BL2 prior to the image load.
The common Arm platform code currently implements this in the
"arm_bl2_plat_gpt_setup" function, relying on the FVP platform's
specifications (PAS definitions, GPCCR_PPS, and GPCCR_PGS).
Different Arm platforms may have distinct PAS definitions, GPCCR_PPS,
GPCCR_PGS, L0/L1 base, and size. To accommodate these variations,
introduce the "plat_arm_get_gpt_info" API. Platforms must implement
this API to provide the necessary data for GPT setup on RME-enabled
platforms. It is essential to note that these additions are relevant to
platforms under the plat/arm hierarchy that will reuse the
"arm_bl2_plat_gpt_setup" function.
As a result of these new additions, migrate data related to the FVP
platform to its source and header files.
Signed-off-by: Rohit Mathew <Rohit.Mathew@arm.com>
Change-Id: I4f4c8894c1cda0adc1f83e7439eb372e923f6147
In accordance with common naming conventions, macros specifying the base
address of a region typically use the prefix "BASE" combined with the
region name, rather than "ADDR_BASE."
Currently, the macros defining the base addresses for L0 and L1 GPT
tables within `arm_def.h` are named "ARM_L0_GPT_ADDR_BASE" and
"ARM_L1_GPT_ADDR_BASE" respectively. To adhere to the established naming
convention, rename these macros as "ARM_L1_GPT_BASE" and
"ARM_L0_GPT_BASE" respectively.
Signed-off-by: Rohit Mathew <Rohit.Mathew@arm.com>
Change-Id: Ibd50a58a1f63ba97d2df141f41a21a89ef97d6fb
The fused monotonic counter is checked by the ROM bootloader. The ROM
bootloader won't allow booting images build with a lower
STM32_TF_VERSION value.
On non-closed devices a user can easily circumvent this. But it is
annoying for a developer when open development hardware gets the counter
value fused.
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
Change-Id: Ie52561368a3178de9d9a44b9d089664241452651
The i.MX8MP exists in multiple SKUs, some of which lack the NPU or VPU.
Yet, we unconditionally enable NPU and VPU power domains in upstream
TF-A, causing it to hang on such SoCs, unless patched.
Enabling all power domains is an idiosyncrasy of the i.MX8MP support,
which we don't have on i.MX8MQ, i.MX8MM or i.MX8MN. Therefore let's drop
unconditional powering on of all power domains.
As only exception, we will keep enabling the USB power domains. These
are enabled in the BootROM if booting over SDPS and boot firmware may
expect them to be enabled for non-SDPS recovery too. As USB is
available unconditionally on the current i.MX8MP variants, this is
deemed acceptable and reduces the chance of breaking existing systems.
Fixes: a775ef25c3 ("plat: imx8mp: Add the basic support for i.MX8MP")
Change-Id: Idc6e8f770d240f4d929dffa91f9ccf8c476c6c12
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Add compilation and initialization of BSEC peripheral, to access OTP
fuses. Add the definition of OTP fuses.
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: If6403838b1e2c04c59effc8545b381aced5f7cda
Update nand driver to match GHRD design, fix row
address calculation method and other misc updates.
Signed-off-by: Girisha Dengi <girisha.dengi@intel.com>
Signed-off-by: Sieu Mun Tang <sieu.mun.tang@intel.com>
Change-Id: I1cb3dda43e767ba243fbe89bfa18818db321c5c2
As a part of removing DeviceTree from EDK2, we move functions to TF-A:
- counting the number of memory nodes
- checking NUMA node id
- checking the memory address
Signed-off-by: Xiong Yining <xiongyining1480@phytium.com.cn>
Signed-off-by: Chen Baozi <chenbaozi@phytium.com.cn>
Change-Id: Ib7bce3a65c817a5b3bef6c9e0a459c7ce76c7e35
Update the version to match release versioning scheme.
No functional change.
Signed-off-by: Hieu Nguyen <hieu.nguyen.dn@renesas.com>
Change-Id: Ib481fade925f74dbea1dd2b39c1abfab888379e4
Add cache operations because BL2 disabled MMU at the end of the boot
process, but did not clean/invalidate for the cache used by MMU.
Signed-off-by: Toshiyuki Ogasahara <toshiyuki.ogasahara.bo@hitachi.com>
Signed-off-by: Yoshifumi Hosoya <yoshifumi.hosoya.wj@renesas.com>
Change-Id: Id4070b46103ca2b50788b3a99f6961a35df24418
This commit changes ENABLE_STACK_PROTECTOR value to "strong" for
enabling the stack protector by canary.
Signed-off-by: Koichi Yamaguchi <koichi.yamaguchi.zb@hitachi.com>
Signed-off-by: Toshiyuki Ogasahara <toshiyuki.ogasahara.bo@hitachi.com>
Signed-off-by: Yoshifumi Hosoya <yoshifumi.hosoya.wj@renesas.com>
Change-Id: Ice351d23c98daf12737a5e65cef743035d62dabe
Boyan Karatotev
Tudor Cretu
Arunachalam Ganapathy
Davidson K
Harrison Mutai
Manish V Badarkhe
David Vincze
annsai01
Tamas Ban
Marcin Juszkiewicz
Olivier Deprez
Chris Kay
J-Alves
Yann Gautier
Manorit Chawdhry
Jayanth Dodderi Chidanand
Andre Przywara
Madhukar Pappireddy
Pranav Madhu
Sona Mathew
Igor Opaniuk
Rohit Mathew
Robin van der Gracht
Ahmad Fatoum
Girisha Dengi
Xiong Yining
Hieu Nguyen
Toshiyuki Ogasahara