If Poetry is available in the build environment, use Poetry when
running sp_mk_gen.py script. This ensures dependencies that are needed
to run the script are accounted for.
Needed to successfully run the following config:
spm-l2-boot-tests/fvp-default,fvp-spm-optee-sp,fvp-default: \
fvp-spm.optee.sp
Change-Id: Icca4249dab929f1bcf5f4454d472cf6923e3ee17
Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
The `memmap` build system target was recently migrated over to an
independent Poetry project, but its build system target was not updated
to install its dependencies.
Change-Id: If46e2a4609d47467cac07426c1cde65e2e0944cb
Signed-off-by: Chris Kay <chris.kay@arm.com>
* changes:
feat(fvp): set defaults for build commandline
docs(arm): enable Linux boot from fip as BL33
feat(arm): enable Linux boot from fip as BL33
docs(fvp): update fvp build time options
docs(arm): add initrd props to dtb at build time
feat(arm): add initrd props to dtb at build time
Add initrd properties to the device tree blob at build time, giving
users the ability to run a linux kernel and successfully boot it to
the terminal. Users can boot a linux kernel in a normal flow as well
as in RESET_TO_BL31. This function is an extension of the build time
option "ARM_LINUX_KERNEL_AS_BL33=1".
The build time options INITRD_SIZE or INITRD_PATH will trigger the
insertion of initrd properties in to the DTB. If both options are
provided then the INITRD_SIZE will take precedence.
The available options are:
INITRD_SIZE: Provide the initrd size in dec or hex (hex format must
precede with '0x'.
Example: INITRD_SIZE=0x1000000
INITRD_PATH: Provide an initrd path for the build time to find its
exact size.
INITRD_BASE: A required build time option that sets the initrd base
address in hex format. A default value can be set by the platform.
Example: INITRD_BASE=0x90000000
Change-Id: Ief8de5f00c453509bcc6e978e0a95d768f1f509c
Signed-off-by: Salman Nabi <salman.nabi@arm.com>
This change refactors the memmap tool into a Poetry project, with its
own dependencies. You can continue to run it manually with:
poetry run memory <args>
Change-Id: I346283df1b8bfad4babc1f5a3861dab94d4a006a
Signed-off-by: Chris Kay <chris.kay@arm.com>
Currently the top level Makefile checks any invalid SPD build flags
before parsing platform makefile thus any invalid combination enabled
in platform makefile will go unnoticed.
Move handling of all invalid SPD build option checks after platform level makefile is parsed.
Change-Id: Ib3b384ca99403ebaf34f6ce662c93480827e2136
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
The current code is incredibly resilient to updates to the spec and
has worked quite well so far. However, recent implementations expose a
weakness in that this is rather slow. A large part of it is written in
assembly, making it opaque to the compiler for optimisations. The
future proofness requires reading registers that are effectively
`volatile`, making it even harder for the compiler, as well as adding
lots of implicit barriers, making it hard for the microarchitecutre to
optimise as well.
We can make a few assumptions, checked by a few well placed asserts, and
remove a lot of this burden. For a start, at the moment there are 4
group 0 counters with static assignments. Contexting them is a trivial
affair that doesn't need a loop. Similarly, there can only be up to 16
group 1 counters. Contexting them is a bit harder, but we can do with a
single branch with a falling through switch. If/when both of these
change, we have a pair of asserts and the feature detection mechanism to
guard us against pretending that we support something we don't.
We can drop contexting of the offset registers. They are fully
accessible by EL2 and as such are its responsibility to preserve on
powerdown.
Another small thing we can do, is pass the core_pos into the hook.
The caller already knows which core we're running on, we don't need to
call this non-trivial function again.
Finally, knowing this, we don't really need the auxiliary AMUs to be
described by the device tree. Linux doesn't care at the moment, and any
information we need for EL3 can be neatly placed in a simple array.
All of this, combined with lifting the actual saving out of assembly,
reduces the instructions to save the context from 180 to 40, including a
lot fewer branches. The code is also much shorter and easier to read.
Also propagate to aarch32 so that the two don't diverge too much.
Change-Id: Ib62e6e9ba5be7fb9fb8965c8eee148d5598a5361
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
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>
* 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
Now that all errata flags are all conveniently in a single list we can
make sweeping decisions about their values. The first use-case is to
enable all errata in TF-A. This is useful for CI runs where it is
impractical to list every single one. This should help with the long
standing issue of errata not being built or tested.
Also add missing CPUs with errata to `ENABLE_ERRATA_ALL` to enable all
errata builds in CI.
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I2b456d304d7bf3215c7c4f4fd70b56ecbcb09979
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>
Generate the rules for calling 'tlc' tool, and generating
a partition package as a TL:
- The data is aligned to 4k.
- Using TE types 0x103 for FF-A manifest, and 0x106 for
FF-A SP binary.
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I1941e3e8f43d8dad33cdd0dea0571cf4a0d5e8f3
After the change to allow overriding platform specific defaults [1],
the PLAT macro is forced to DEFAULT_PLAT in plat_helpers.mk. But this
makefile is also called for tools. For example in fiptool makefile, as
PLAT is reset to default plat (fvp), we cannot use specific platforms
plat_fiptool.mk files. Put back the setting of PLAT macro in Makefile.
[1]: 1b2fb6adb5 feat(build): add ability to define platform specific
defaults
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: Iadf8bc7fc831a728a9688d0afdd163c8dda737e5
FEAT_MOPS, mandatory from Arm v8.8, is typically managed in EL2.
However, in configurations where NS_EL2 is not enabled,
EL3 must set the HCRX_EL2.MSCEn bit to 1 to enable the feature.
This patch ensures FEAT_MOPS is enabled by setting HCRX_EL2.MSCEn to 1.
Change-Id: Ic4960e0cc14a44279156b79ded50de475b3b21c5
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
For a couple of releases now we have officially withdrawn support for
building TF-A on Windows using the native environment, relying instead
on POSIX emulation layers like MSYS2, Mingw64, Cygwin or WSL.
This change removes the remainder of the OS compatibility layer
entirely, and migrates the build system over to explicitly relying on a
POSIX environment.
Change-Id: I8fb60d998162422e958009afd17eab826e3bc39b
Signed-off-by: Chris Kay <chris.kay@arm.com>
* changes:
feat(smccc): implement SMCCC_ARCH_FEATURE_AVAILABILITY
refactor(cm): clean up per-world context
refactor(cm): change owning security state when a feature is disabled
Move platform.mk inclusion in top level Makefile to permit a platform
specifying BRANCH_PROTECTION option.
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I1f662f82cd949eedfdbb61b9f66de15c46fb3106
SMCCC_ARCH_FEATURE_AVAILABILITY [1] is a call to query firmware about
the features it is aware of and enables. This is useful when a feature
is not enabled at EL3, eg due to an older FW image, but it is present in
hardware. In those cases, the EL1 ID registers do not reflect the usable
feature set and this call should provide the necessary information to
remedy that.
The call itself is very lightweight - effectively a sanitised read of
the relevant system register. Bits that are not relevant to feature
enablement are masked out and active low bits are converted to active
high.
The implementation is also very simple. All relevant, irrelevant, and
inverted bits combined into bitmasks at build time. Then at runtime the
masks are unconditionally applied to produce the right result. This
assumes that context managers will make sure that disabled features
do not have their bits set and the registers are context switched if
any fields in them make enablement ambiguous.
Features that are not yet supported in TF-A have not been added. On
debug builds, calling this function will fail an assert if any bits that
are not expected are set. In combination with CI this should allow for
this feature to to stay up to date as new architectural features are
added.
If a call for MPAM3_EL3 is made when MPAM is not enabled, the call
will return INVALID_PARAM, while if it is FEAT_STATE_CHECK, it will
return zero. This should be fairly consistent with feature detection.
The bitmask is meant to be interpreted as the logical AND of the
relevant ID registers. It would be permissible for this to return 1
while the ID returns 0. Despite this, this implementation takes steps
not to. In the general case, the two should match exactly.
Finally, it is not entirely clear whether this call replies to SMC32
requests. However, it will not, as the return values are all 64 bits.
[1]: https://developer.arm.com/documentation/den0028/galp1/?lang=en
Co-developed-by: Charlie Bareham <charlie.bareham@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I1a74e7d0b3459b1396961b8fa27f84e3f0ad6a6f
The combination of ENABLE_RME=1 + ENABLE_PIE=1 build options is
prevented currently for no good reason. ENABLE_PIE in a 4 worlds
configuration is mostly for building BL31 with PIE support.
BL1 / BL2 (BL2_RUNS_AT_EL3=1) remain non-PIE. BL32 (TSP) is PIE capable
but typically unused in this configuration. TRP doesn't support PIE
but is loaded in place so isn't affected by this option.
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: Ia60e295534a92cb1b4e3eb88b3e240aea4f4fe1d
This patch enables support of FEAT_FPMR by enabling access
to FPMR register. It achieves it by setting the EnFPM bit of
SCR_EL3. This feature is currently enabled for NS world only.
Reference:
https://developer.arm.com/documentation/109697/2024_09/
Feature-descriptions/The-Armv9-5-architecture-extension?lang=en
Change-Id: I580c409b9b22f8ead0737502280fb9093a3d5dd2
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
According to Platform Initialization (PI) Specification [1] and
discussion on edk2 mailing list [2],
StandaloneMm shouldn't create Hob but it should be passed from TF-A.
IOW, TF-A should pass boot information via HOB list to initialise
StandaloneMm properly.
And this HOB lists could be delivered via
- SPM_MM: Transfer List according to the firmware handoff spec[3]
- FF-A v1.1 >= : FF-A boot protocol.
This patch introduces a TF-A HOB creation library and
some of definitions which StandaloneMm requires to boot.
Link: https://uefi.org/sites/default/files/resources/PI_Spec_1_6.pdf [1]
Link: https://edk2.groups.io/g/devel/topic/103675962#114283 [2]
Link: https://github.com/FirmwareHandoff/firmware_handoff [3]
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
Change-Id: I5e0838adce487110206998a8b79bc3adca922cec
The ROMLIB build currently has a strong dependency on MbedTLS. This
patch has been introduced to remove this dependency, making it more
flexible.
Change-Id: If8c4cc7cf557687f40b235a4b8f931cfb70943fd
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
This change centralises the logic that disables the default suffix rules
that Make provides. These rules are a hold-over from legacy standards of
Make, and occasionally conflict with our rules.
Change-Id: I9e023edbc01b5ae48a96fa1078d0b81faabb0cb9
Signed-off-by: Chris Kay <chris.kay@arm.com>
This change modifies the build rules for static libraries so that
individual rules which use those libraries depend directly on the
archive files that are generated, rather than their phony target aliases
and `-lX` link flags.
The goal of this is to clean up Make's view of the dependencies between
files, avoiding phony targets (which do not honour timestamps) making
their way into intermediate dependencies.
Change-Id: I96d655fcd94dc259ffa6e8970b2be7b8c7e11123
Signed-off-by: Chris Kay <chris.kay@arm.com>
Generated this change-log using below command:
npm run release -- --skip.commit --skip.tag --release-as 2.12.0
Change-Id: Idb74f6a31bf2691e7666e2738030d6f0e2b8c519
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
The TF_FLAGS variable must be recursively expanded as the rules that use
it are defined before it has been fully defined. That has the
unfortunate side effect of spawning a subshell that calls the compiler
for every file that is being built, thrashing multicore build times.
We don't cater to the possibility of the toolchain changing mid build so
precomputing this value would be more sensible. Doing a clean build on
an Intel dual socket Xeon Gold 5218 (i.e. 64 threads) workstation used
to take about 9 seconds. After this patch it takes about 1.5. Single
core performance went from ~45 seconds to about 25.
Change-Id: If56ed0ab3cc42bc482d9dd05a41ffbff4dd7f147
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Armv8.6 introduced the FEAT_LS64 extension, which provides a 64 *byte*
store instruction. A related instruction is ST64BV0, which will replace
the lowest 32 bits of the data with a value taken from the ACCDATA_EL1
system register (so that EL0 cannot alter them).
Using that ST64BV0 instruction and accessing the ACCDATA_EL1 system
register is guarded by two SCR_EL3 bits, which we should set to avoid a
trap into EL3, when lower ELs use one of those.
Add the required bits and pieces to make this feature usable:
- Add the ENABLE_FEAT_LS64_ACCDATA build option (defaulting to 0).
- Add the CPUID and SCR_EL3 bit definitions associated with FEAT_LS64.
- Add a feature check to check for the existing four variants of the
LS64 feature and detect future extensions.
- Add code to save and restore the ACCDATA_EL1 register on
secure/non-secure context switches.
- Enable the feature with runtime detection for FVP and Arm FPGA.
Please note that the *basic* FEAT_LS64 feature does not feature any trap
bits, it's only the addition of the ACCDATA_EL1 system register that
adds these traps and the SCR_EL3 bits.
Change-Id: Ie3e2ca2d9c4fbbd45c0cc6089accbb825579138a
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Update linker file and init codes to allow using separated
memory region for RW DATA. Init codes will copy the RW DATA
from the image to the linked address.
On some NXP platforms, after the BL31 image has been verified,
the bl31 image space will be locked/protected as RO only, so
need to move the RW DATA and NOBITS out of the bl31 image.
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Change-Id: I361d9a715890961bf30790a3325f8085a40c0c39
This patch disables trapping to EL3 when the FEAT_D128
specific registers are accessed by setting the SCR_EL3.D128En bit.
If FEAT_D128 is implemented, then FEAT_SYSREG128 is implemented.
With FEAT_SYSREG128 certain system registers are treated as 128-bit,
so we should be context saving and restoring 128-bits instead of 64-bit
when FEAT_D128 is enabled.
FEAT_SYSREG128 adds support for MRRS and MSRR instruction which
helps us to read write to 128-bit system register.
Refer to Arm Architecture Manual for further details.
Change the FVP platform to default to handling this as a dynamic option
so the right decision can be made by the code at runtime.
Change-Id: I1a53db5eac29e56c8fbdcd4961ede3abfcb2411a
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
It used to be the case that a FEAT_RME build could not be built with
FEAT_BRBE support. BRBE doesn't have a 3-world aware disable and
MDCR_EL3 was not context switched to allow for disabling in Realm world.
As of commit 123002f917 MDCR_EL3 is
context switched. Since the flag for BRBE support is
ENABLE_BRBE_FOR_NS, move brbe_enable() to only happen for NS world. The
other worlds will see BRBE disabled and branch recording prohibited.
This allows for a build with both RME and BRBE.
Note that EL2 BRBE registers are not context switched. Further work is
needed if non-NS support is required.
Change-Id: I82f0f08399dcd080902477dc9636bc4541685f89
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Add required SMCs by RMM to push attestation signing requests to EL3
and get responses. EL3 may then choose to push these requests to a HES
as suitable for a platform. This patch also supports the new
RMM_EL3_FEATURES interface, that RMM can use to query for support for
HES based signing. The new interface exposes a feature register with
different bits defining different discoverable features. This new
interface is available starting the 0.4 version of the RMM-EL3
interface, causing the version to bump up. This patch also adds a
platform port for FVP that implements the platform hooks required to
enable the new SMCs, but it does not push to a HES and instead copies a
zeroed buffer in EL3.
Change-Id: I69c110252835122a9533e71bdcce10b5f2a686b2
Signed-off-by: Raghu Krishnamurthy <raghupathyk@nvidia.com>
Arm v8.9 introduces FEAT_SCTLR2, adding SCTLR2_ELx registers.
Support this, context switching the registers and disabling
traps so lower ELs can access the new registers.
Change the FVP platform to default to handling this as a dynamic option
so the right decision can be made by the code at runtime.
Change-Id: I0c4cba86917b6b065a7e8dd6af7daf64ee18dcda
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Arm v8.9 introduces FEAT_THE, adding Translation Hardening Extension
Read-Check-Write mask registers, RCWMASK_EL1 and RCWSMASK_EL1.
Support this, context switching the registers and disabling
traps so lower ELs can access the new registers.
Change the FVP platform to default to handling this as a dynamic option
so the right decision can be made by the code at runtime.
Change-Id: I8775787f523639b39faf61d046ef482f73b2a562
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Due to change [1], the FIP tool was compiled with the default platform
instead of the one specified via the command line, as make_helpers.mk
set the PLAT option to default. This happened because the root Makefile
invoked FIP tool compilation without the PLAT option. The issue has
been fixed by explicitly providing the PLAT option for FIP tool
compilation.
[1]: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/26597
Change-Id: Icc516f8d44706df03c7e6ee123b58afeda72cea7
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
The Yocto team has requested that we do not use Poetry from within the
Makefile, as Yocto does not have network access during the build
process.
We want to maintain the current behaviour, so this change makes our use
of Poetry contigent on it being available in the environment.
Additionally, explicitly passing an empty toolchain parameter now allows
a tool to be *disabled* (e.g. passing `POETRY=` will prevent the build
system from trying to use Poetry).
Change-Id: Ibf552a3fee1eaadee767a1b948b559700083b401
Signed-off-by: Chris Kay <chris.kay@arm.com>
Make the process of compiling a TL from DT source flexible. Provide a
top level recipe to make it easier for developers to build a transfer
list. Clean up integration of TLC into the build system.
Change-Id: I4466e27a457dfd5bf709dc3a360a2b63bf6030ce
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
