| a57b94ec | 06-Aug-2024 |
Chris Kay <chris.kay@arm.com> |
build: fix grouped targets on Make <= 4.2
Grouped targets are a feature introduced with GNU Make 4.3 which enable
rules with multiple targets to communicate that all of the targets of
that rule are
build: fix grouped targets on Make <= 4.2
Grouped targets are a feature introduced with GNU Make 4.3 which enable
rules with multiple targets to communicate that all of the targets of
that rule are built simultaneously, rather than independently.
For example, without grouped targets the following rule may be executed
twice:
a.txt b.txt:
touch a.txt b.txt
# $ remake -j2 a.txt b.txt
# touch a.txt b.txt
# touch a.txt b.txt
In this example, both `a.txt` and `b.txt` are touched twice, when the
rule should only be executed once. Instead, this rule can use a grouped
target:
a.txt b.txt &:
touch a.txt b.txt
# $ remake -j2 a.txt b.txt
# touch a.txt b.txt
# remake: 'b.txt' is up to date.
In this case, both `a.txt` and `b.txt` are created once only, as Make
now knows that the recipe will create both files.
Note that pattern rules with multiple targets always behave this way.
Previously, we assumed that the grouped target feature was available,
but on systems still packaging Make 4.2, most prominently Ubuntu 20.04,
this is not the case. This change adds a check to ensure that we do not
use grouped targets if they are unavailable.
Change-Id: Ifd9da35421ae11468d7a25d3cbc76f6036921749
Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| 4ec4e545 | 06-Sep-2024 |
Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com> |
feat(sctlr2): add support for FEAT_SCTLR2
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
feat(sctlr2): add support for FEAT_SCTLR2
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>
show more ...
|
| d2867397 | 26-Sep-2024 |
Chris Kay <chris.kay@arm.com> |
build: make Poetry optional
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
build: make Poetry optional
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>
show more ...
|
| 9cea2c36 | 29-Aug-2024 |
Chris Kay <chris.kay@arm.com> |
build: allow multiple toolchain defaults
This change enables a fairly commonly-requested use-case, which is to
fall back to the host system's native toolchain when building on AArch64
if the bare-me
build: allow multiple toolchain defaults
This change enables a fairly commonly-requested use-case, which is to
fall back to the host system's native toolchain when building on AArch64
if the bare-metal toolchain is not available.
In this situation, if the `aarch64-none-elf` GCC toolchain cannot be
located, the build system will look for `aarch64-linux-gnu` before
giving up.
Change-Id: I39d2a8837b651b28cf0eafa92f6003a7f66767a0
Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| 3789c3c0 | 03-Jun-2024 |
Chris Kay <chris.kay@arm.com> |
build: determine toolchain tools dynamically
Since the introduction of the toolchain detection framework into the
build system, we have done determination and identification of the
toolchain(s) used
build: determine toolchain tools dynamically
Since the introduction of the toolchain detection framework into the
build system, we have done determination and identification of the
toolchain(s) used for the build at the initialization of the build
system.
This incurs a large cost to the build every time - for every toolchain
that has been requested by the current makefile, we try to identify each
tool in the list of known tool classes, even if that tool doesn't
actually see any use.
For the clean and check-like targets we worked around this by disabling
most of the toolchains if we detect these targets, but this is
inflexible and not very reliable, and it still means that when building
normal targets we are incurring that cost for all tools whether they are
used or not.
This change instead modifies the toolchain detection framework to only
initialize a tool for a given toolchain when it is first used. This does
mean that we can no longer warn about an incorrectly-configured
toolchain at the beginning of build system invocation, but it has the
advantage of substantially reducing build time and the complexity of
*using* the framework (at the cost of an increase in complexity in the
framework itself).
Change-Id: I7f3d06b2eb58c1b26a846791a13b0037f32c8013
Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| 01faa994 | 22-Aug-2024 |
Soby Mathew <soby.mathew@arm.com> |
feat(rme): change the default max GPT block size to 512MB
Previously the max GPT block size was set to 2MB as a conservative
default. For workloads making use of SMMU in Normal world, and has
a Stag
feat(rme): change the default max GPT block size to 512MB
Previously the max GPT block size was set to 2MB as a conservative
default. For workloads making use of SMMU in Normal world, and has
a Stage 2 block mapping of large sizes like 512MB or 1GB, then a
max GPT block size of 2MB may result in performance regression.
Hence this patch changes the default max GPT block size from 2MB to 512MB.
Change-Id: If90f12f494ec0f44d3e5974df8d58fcb528cfd34
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
show more ...
|