MPMM is a core-specific microarchitectural feature. It has been present
in every Arm core since the Cortex-A510 and has been implemented in
exactly the same way. Despite that, it is enabled more like an
architectural feature with a top level enable flag. This utilised the
identical implementation.
This duality has left MPMM in an awkward place, where its enablement
should be generic, like an architectural feature, but since it is not,
it should also be core-specific if it ever changes. One choice to do
this has been through the device tree.
This has worked just fine so far, however, recent implementations expose
a weakness in that this is rather slow - the device tree has to be read,
there's a long call stack of functions with many branches, and system
registers are read. In the hot path of PSCI CPU powerdown, this has a
significant and measurable impact. Besides it being a rather large
amount of code that is difficult to understand.
Since MPMM is a microarchitectural feature, its correct placement is in
the reset function. The essence of the current enablement is to write
CPUPPMCR_EL3.MPMM_EN if CPUPPMCR_EL3.MPMMPINCTL == 0. Replacing the C
enablement with an assembly macro in each CPU's reset function achieves
the same effect with just a single close branch and a grand total of 6
instructions (versus the old 2 branches and 32 instructions).
Having done this, the device tree entry becomes redundant. Should a core
that doesn't support MPMM arise, this can cleanly be handled in the
reset function. As such, the whole ENABLE_MPMM_FCONF and platform hooks
mechanisms become obsolete and are removed.
Change-Id: I1d0475b21a1625bb3519f513ba109284f973ffdf
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
The same way it is done for neoverse_rd, create a plat_rse_comms_init()
function to call rse_comms_init().
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: I12f3b8a38a5369decb4b97f8aceeb0dc81cbea28
In order to support a platform without MHU in RSE, update the flag
PLAT_MHU_VERSION. It is renamed PLAT_MHU and can take the following
entries: NO_MHU, MHUv1, MHUv2, MHUv3...
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: Ia72e590088ce62ba8c9009f341b6135926947bee
* changes:
fix(cpus): clear CPUPWRCTLR_EL1.CORE_PWRDN_EN_BIT on reset
chore(docs): drop the "wfi" from `pwr_domain_pwr_down_wfi`
chore(psci): drop skip_wfi variable
feat(arm): convert arm platforms to expect a wakeup
fix(cpus): avoid SME related loss of context on powerdown
feat(psci): allow cores to wake up from powerdown
refactor: panic after calling psci_power_down_wfi()
refactor(cpus): undo errata mitigations
feat(cpus): add sysreg_bit_toggle
The PSA Crypto API is available with sending messages to RSE. Change
to invoke PSA Crypto API for getting entropy.
Change-Id: I4b2dc4eb99606c2425b64949d9c3f5c576883758
Signed-off-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Icen Zeyada <Icen.Zeyada2@arm.com>
Enable the trng on the platform, which can be used by other features.
`rng-seed` has been removed and enabled `FEAT_RNG_TRAP` to trap to EL3
when accessing system registers RNDR and RNDRRS
Change-Id: Ibde39115f285e67d31b14863c75beaf37493deca
Signed-off-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Icen Zeyada <Icen.Zeyada2@arm.com>
Travis' and Gelas' TRMs tell us to disable SME (set PSTATE.{ZA, SM} to
0) when we're attempting to power down. What they don't tell us is that
if this isn't done, the powerdown request will be rejected. On the
CPU_OFF path that's not a problem - we can force SVCR to 0 and be
certain the core will power off.
On the suspend to powerdown path, however, we cannot do this. The TRM
also tells us that the sequence could also be aborted on eg. GIC
interrupts. If this were to happen when we have overwritten SVCR to 0,
upon a return to the caller they would experience a loss of context. We
know that at least Linux may call into PSCI with SVCR != 0. One option
is to save the entire SME context which would be quite expensive just to
work around. Another option is to downgrade the request to a normal
suspend when SME was left on. This option is better as this is expected
to happen rarely enough to ignore the wasted power and we don't want to
burden the generic (correct) path with needless context management.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I698fa8490ebf51461f6aa8bba84f9827c5c46ad4
The simplistic view of a core's powerdown sequence is that power is
atomically cut upon calling `wfi`. However, it turns out that it has
lots to do - it has to talk to the interconnect to exit coherency, clean
caches, check for RAS errors, etc. These take significant amounts of
time and are certainly not atomic. As such there is a significant window
of opportunity for external events to happen. Many of these steps are
not destructive to context, so theoretically, the core can just "give
up" half way (or roll certain actions back) and carry on running. The
point in this sequence after which roll back is not possible is called
the point of no return.
One of these actions is the checking for RAS errors. It is possible for
one to happen during this lengthy sequence, or at least remain
undiscovered until that point. If the core were to continue powerdown
when that happens, there would be no (easy) way to inform anyone about
it. Rejecting the powerdown and letting software handle the error is the
best way to implement this.
Arm cores since at least the a510 have included this exact feature. So
far it hasn't been deemed necessary to account for it in firmware due to
the low likelihood of this happening. However, events like GIC wakeup
requests are much more probable. Older cores will powerdown and
immediately power back up when this happens. Travis and Gelas include a
feature similar to the RAS case above, called powerdown abandon. The
idea is that this will improve the latency to service the interrupt by
saving on work which the core and software need to do.
So far firmware has relied on the `wfi` being the point of no return and
if it doesn't explicitly detect a pending interrupt quite early on, it
will embark onto a sequence that it expects to end with shutdown. To
accommodate for it not being a point of no return, we must undo all of
the system management we did, just like in the warm boot entrypoint.
To achieve that, the pwr_domain_pwr_down_wfi hook must not be terminal.
Most recent platforms do some platform management and finish on the
standard `wfi`, followed by a panic or an endless loop as this is
expected to not return. To make this generic, any platform that wishes
to support wakeups must instead let common code call
`psci_power_down_wfi()` right after. Besides wakeups, this lets common
code handle powerdown errata better as well.
Then, the CPU_OFF case is simple - PSCI does not allow it to return. So
the best that can be done is to attempt the `wfi` a few times (the
choice of 32 is arbitrary) in the hope that the wakeup is transient. If
it isn't, the only choice is to panic, as the system is likely to be in
a bad state, eg. interrupts weren't routed away. The same applies for
SYSTEM_OFF, SYSTEM_RESET, and SYSTEM_RESET2. There the panic won't
matter as the system is going offline one way or another. The RAS case
will be considered in a separate patch.
Now, the CPU_SUSPEND case is more involved. First, to powerdown it must
wipe its context as it is not written on warm boot. But it cannot be
overwritten in case of a wakeup. To avoid the catch 22, save a copy that
will only be used if powerdown fails. That is about 500 bytes on the
stack so it hopefully doesn't tip anyone over any limits. In future that
can be avoided by having a core manage its own context.
Second, when the core wakes up, it must undo anything it did to prepare
for poweroff, which for the cores we care about, is writing
CPUPWRCTLR_EL1.CORE_PWRDN_EN. The least intrusive for the cpu library
way of doing this is to simply call the power off hook again and have
the hook toggle the bit. If in the future there need to be more complex
sequences, their direction can be advised on the value of this bit.
Third, do the actual "resume". Most of the logic is already there for
the retention suspend, so that only needs a small touch up to apply to
the powerdown case as well. The missing bit is the powerdown specific
state management. Luckily, the warmboot entrypoint does exactly that
already too, so steal that and we're done.
All of this is hidden behind a FEAT_PABANDON flag since it has a large
memory and runtime cost that we don't want to burden non pabandon cores
with.
Finally, do some function renaming to better reflect their purpose and
make names a little bit more consistent.
Change-Id: I2405b59300c2e24ce02e266f91b7c51474c1145f
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Enable the compiler's stack protector for detecting stack overflow
issues.
Though TC platform can generate RNG from RSE via MHU channel, the
stack protector canary is used prior to MHU channel initialization.
Thus, currently here simply returns a value of the combination of a
timer's value and a compile-time constant.
Signed-off-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Icen Zeyada <Icen.Zeyada2@arm.com>
Change-Id: I68fcc7782637b2b6b4dbbc81bc15df8c5ce0040b
Rename TC_FPGA_ANDROID_IMG_IN_RAM to TC_FPGA_FS_IMG_IN_RAM
to use it for debian loading to ram as well.
Change-Id: I70b68b06501d17dcebbe78bee8fec0a701106c92
Signed-off-by: Jagdish Gediya <jagdish.gediya@arm.com>
Signed-off-by: Icen.Zeyada <Icen.Zeyada2@arm.com>
Initialize MHU channels between TF-A and RSE, this is a preparation
for later sending messages to RSE.
Signed-off-by: Leo Yan <leo.yan@arm.com>
Signed-off-by: Icen Zeyada <Icen.Zeyada2@arm.com>
Change-Id: I66095cafcc1d48249cf957a49dc1dad3059a0010
The component-aware simple encoder has become outdated with the latest
upstream DRM subsystem changes since Linux kernel commit 4cfe5cc02e3f
("drm/arm/komeda: Remove component framework and add a simple encoder")
To address this we introduce a new compilation flag
`TC_DPU_USE_SIMPLE_PANEL` for control panel vs. encoder enablement.
This flag is set when the kernel version is >= 6.6 and 0 when the kernel
version is < 6.6.
We also rename the `vencoder_in` node to `lcd_in` to avoid unnecessary
conditional code for vencoder vs. simple panel enablement.
Signed-off-by: Jagdish Gediya <jagdish.gediya@arm.com>
Signed-off-by: Icen Zeyada <Icen.Zeyada2@arm.com>
Change-Id: Ibb14a56911cfb406b2181a22cc40db58d8ceaa8d
This patch enable support for loading FIP image into DRAM rather than
flash drive.
Change-Id: I00d2de7b22e315db7f3e8a835ddd414ab297b554
Signed-off-by: Vishnu Satheesh <vishnu.satheesh@arm.com>
Signed-off-by: Icen Zeyada <Icen.Zeyada2@arm.com>
Following recent commit [1], update the Makefile to mark
the TC2 platform as deprecated and trigger a build failure
if someone attempts to build the TC0 or TC1 platform.
[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/31702
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: Ib6ed4933328e35209443ceec59f1e2056881f927
Set the Make flags for TF-A to be able to enable SME and SME2 features.
Note that we enable these architectural features for both the secure and
non-secure worlds, which is required on TC4.
In the case of the non-secure world, we specify a value of 2 for the
flag which specifies that TF-A should check the feature register to
ensure that the feature is present before enabling it. This allows these
flags to be compatible with all platforms and stops TF-A doing anything
different if it does not detect that the feature is present.
Change-Id: I51f8c7e3eb1cf06767f4b155c93269e1f129f730
Signed-off-by: Jackson Cooper-Driver <jackson.cooper-driver@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
Add basic support for TARGET_VERSION=4. It extends the existing 'if'
statements in the Makefile and the header to allow them to take the
value of 4 and also specifies the SCMI platform info to use for TC4.
Change-Id: I8d8257671314277a133e88ef65fae8fada93d00e
Signed-off-by: Jackson Cooper-Driver <jackson.cooper-driver@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
Enable following erratas as per the TARGET_PLATFORM of TC
- ERRATA_A520_2938996
- ERRATA_X4_2726228
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ia552473740c34867dd9fd619faf378adcb784821
NI-Tower's component's registers are need to be accessed from
kernel NI-PMU driver so enable NS access to it.
Change-Id: I83a8b3a1d2778baf767ff93263e246d127ef8114
Signed-off-by: Jagdish Gediya <jagdish.gediya@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
Keeping the MTE2 enablement under the SPMD check is breaking for FPGA
and CI test, as SPMD is absent in these cases.
Enable MTE2 unconditionally so that all the supported platforms can use
it.
Change-Id: Id86893f0e2767a8686c3dca0ea092907d5c107ba
Signed-off-by: Tintu Thomas <tintu.thomas@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
TZC is being replaced by MSF module on TC3. For fixing boot failure on
TC3, don't enable TZC module on the TC3 platform.
Change-Id: I4434cb28bf523be8dd882f5f8799223642822ee2
Signed-off-by: Tintu Thomas <tintu.thomas@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
Add TC specific stubs for both soc_css_init_nic400 and
soc_css_init_pcie. We do not require any initialisation of these
components for TC platforms.
Change-Id: If0129acd1050a56878cb9c3041a033192c88da57
Signed-off-by: Jackson Cooper-Driver <jackson.cooper-driver@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
The usage for SMMU-700 is not consistent across TC platforms:
SMMU-700 on TC2:
| FVP | FPGA
--------+-------+------
Display | Used | Used
GPU | Used | Used
SMMU-700 on TC3:
| FVP | FPGA
--------+-------+------
Display | No | No
GPU | Used | No
This commit changes to use append mode for SMMU-700 to bind it on TC2
and TC3 separately. As a result, the TC_IOMMU_EN configuration is not
used, remove it.
Change-Id: Ic4152eb4c8ef97bf27b8a97c3c6cb86e32a2e8eb
Signed-off-by: Leo Yan <leo.yan@arm.com>
* changes:
feat(tc): add MHUv3 addresses between RSS and AP
feat(tc): specify MHU version based on platform
feat(tc): bind SCMI over MHUv3 for TC3
feat(tc): add MHUv3 DT binding for TC3
feat(tc): add MHUv3 doorbell support on TC3
refactor(tc): change tc_scmi_plat_info to single structure
Enable full-HD resolution (1920x1080p60) for the FVP model, and add
checking for the passed resolution parameter.
Change-Id: I5e37ae79b5ceac088a18d5acf00ff4a557bb56aa
Signed-off-by: Sergio Alves <sergio.dasilvalves@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
Platforms older than TC2 contain MHUv2 well as newer platforms contain
MHUv3. Set the Makefile variable accordingly.
Change-Id: I00b83a34908cdbf7d1d9ac39728e3fa6ef449d2c
Signed-off-by: Jackson Cooper-Driver <jackson.cooper-driver@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
This patch adds support for preserving DSU PMU registers
over a power cycle in TC platform.
These PMU registers need to be manually saved/restored
because they are part of cluster power domain and OS
doesn't know when DSU is powered OFF.
Change-Id: Ife9573f205d99d092039cb95674e7434bb5f9239
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
* changes:
refactor(tc): move SCMI nodes into the 'firmware' node
refactor(tc): move MHUv2 property to tc2.dts
refactor(tc): drop the 'mhu-protocol' property in DT binding
refactor(tc): append properties in DT bindings
refactor(tc): move SCMI clock DT binding into tc-base.dtsi
refactor(tc): introduce a new file tc-fpga.dtsi
refactor(tc): move out platform specific DT binding from tc-base.dtsi
refactor(tc): move out platform specific code from tc_vers.dtsi
refactor(tc): add platform specific DT files
refactor(tc): rename 'tc_fvp.dtsi' to 'tc-fvp.dtsi'
refactor(tc): introduce a new macro ADDRESSIFY()
Currently, the DT binding uses the file 'tc.dts' as a central place for
all TC platforms. And the variables (for different platforms, or FVP vs
FPGA, etc.) are maintained in 'tc_vers.dtsi'.
This patch renames 'tc.dts' to 'tc-base.dtsi' and creates an individual
.dts file for every platform. The purpose is to use 'tc-base.dtsi' for
maintaining common DT binding and every platform's specific definitions
will be moved into its own .dts file. This is a preparation for
sequential refactoring.
It changes to include the header files in platform DTS files but not in
the 'tc-base.dtsi'. This can allow 'tc-base.dtsi' is general enough and
platform DTS files covers platform specific defintions.
Change-Id: I034fb3f8836bcea36e8ad8ae01de41127693b0c6
Signed-off-by: Leo Yan <leo.yan@arm.com>
Commit c282384db ("refactor(mte): remove mte, mte_perm") removes the
option FEAT_MTE and introduces FEAT_MTE2 option. Afterwards, the
FEAT_MTE2 option is missed on the TC platform and the feature is
disabled. As a result, it causes the panic in secure world.
This patch enables the FEAT_MTE2 option for TC platform to allow the
secure world can access the MTE registers properly.
Change-Id: If697236aa59bf4fb374e0ff43b53455ac2154e9c
Fixes: c282384db ("refactor(mte): remove mte, mte_perm")
Signed-off-by: Leo Yan <leo.yan@arm.com>
Changes all occurrences of "RSS" and "rss" in the code and build files
to "RSE" and "rse".
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: Idec0bf7a90ae381f5bc968e1bb167daace24a11f
Currently both FEAT_MTE and FEAT_MTE_PERM aren't used for enabling
of any feature bits in EL3. So remove both FEAT handling.
All mte regs that are currently context saved/restored are needed
only when FEAT_MTE2 is enabled, so move to usage of FEAT_MTE2 and
remove FEAT_MTE usage.
BREAKING CHANGE: Any platform or downstream code trying to use
SCR_EL3.ATA bit(26) will see failures as this is now moved to be
used only with FEAT_MTE2 with
commit@ef0d0e5478a3f19cbe70a378b9b184036db38fe2
Change-Id: Id01e154156571f7792135639e17dc5c8d0e17cf8
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
pVMs on Android 14 has a platform requirement to support
SMCCC TRNG discovery. This implementation add a
dummy TRNG support to TC2.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: Iae0ca546cadf48a6a404ae578c7ccf5a84d057c4
Each client who wants to communicate with the DPE service
must own a valid context handle issued by the DPE service.
A context handle can be used for a single time then it will
be invalidated by the DPE service. In case of calls from
the same component, the next valid context handle is
returned in the response to a DPE command. When a component
finishes their job then the next component in the boot flow
inherits its first context handle from its parent.
How the inheritance is done can be client or
platform-dependent. It can be shared through shared
memory or be part of a DTB object passed to the next
bootloader stage.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Signed-off-by: David Vincze <david.vincze@arm.com>
Change-Id: Ic82f074f1c5b15953e78f9fa5404ed7f48674cbb
Child software components are inheriting their first valid
DPE context handle from their parent components (who loaded
and measured them). The context handle is shared through
the device tree object the following way:
- BL1 -> BL2 via TB_FW_CONFIG
- BL2 -> BL33 via NT_FW_CONFIG
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: I9bf7808fb13a310ad7ca1895674a0c7e6725e08b
The client platform relies on the DICE attestation
scheme. RSS provides the DICE Protection Environment
(DPE) service. TF-A measured boot framework supports
multiple backends. A given platform always enables
the corresponding backend which is required by the
attestation scheme.
Signed-off-by: Tamas Ban <tamas.ban@arm.com>
Change-Id: Idc3360d0d7216e4859e99b5db3d377407e0aeee5
They are very scattered, hard to read, and especially hard to track
down. As a result some are duplicate and some are overridden in the
downstream as it's simpler.
Put all variables at the top of the platform makefile. Also drop setting
variables that don't change from their default values
(CTX_INCLUDE_EL2_REGS, ARCH, ENABLE_FEAT_RAS, SDEI_SUPPORT,
EL3_EXCEPTION_HANDLING, HANDLE_EA_EL3_FIRST_NS, ENABLE_SPE_FOR_NS).
While we're at it, add some variables that are necessary. SPMD
requires MTE registers to be saved, BRANCH_PROTECTION, as well as
running at SEL2. All of our CPUs are Armv8.7 compliant so we can have
ARM_ARCH_MINOR=7 (and drop ENABLE_TRF_FOR_NS which it includes).
Finally, drop the override directives as there's no reason to prohibit
experimentation (even if incorrect).
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I6ac596934952aab8abf5d4db5220e13a4941a10c
Compile-time controls have been added for the following:
* SCMI power domain use for DPU and GPU.
* SMMU-700: planned rework required to use IOMMU correctly
for DPU and GPU.
These will allow easier experimentation in the future without
ad-hoc changes needed in the dts file for any sort of analysis
that requires testing different paths.
For TC3 however, the DPU is in an always on power domain so SCMI power
domains are not supported.
Co-developed-by: Tintu Thomas <tintu.thomas@arm.com>
Signed-off-by: Kshitij Sisodia <kshitij.sisodia@arm.com>
Change-Id: If6179a3e4784c1b69f0338a8d52b552452c0eac1
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
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
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>
