Merge "refactor(build): avoid implicit pattern rules" into integration

refactor(build): avoid implicit pattern rules

This change translates any implicit pattern rules into the equivalent
static pattern rules, i.e. rules like:

%.o: %.s
...

... become:

refactor(build): avoid implicit pattern rules

This change translates any implicit pattern rules into the equivalent
static pattern rules, i.e. rules like:

%.o: %.s
...

... become:

$(OBJS): %.o: %.s
...

These behave similarly, but have some subtle differences. The former
defines a rule "for any target matching %.o where there is not a more
specific rule", whereas the latter defines a rule "for these targets,
which match %.o".

Where possible it is better to use a static pattern rule as it reduces
the rule space that Make needs to search.

Change-Id: Ifba4f44bcecf4e74980c31347e192cdf1e42003e
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge "fix(tools): renesas: rzg: Fix tool build" into integration

fix(tools): renesas: rzg: Fix tool build

Since 2f1c5e7eb177 ("build: use GCC to link by default") the
code does not even compile with GCC14 on debian/unstable with
the following error:

/usr/lib/gcc

fix(tools): renesas: rzg: Fix tool build

Since 2f1c5e7eb177 ("build: use GCC to link by default") the
code does not even compile with GCC14 on debian/unstable with
the following error:

/usr/lib/gcc-cross/aarch64-linux-gnu/14/../../../../aarch64-linux-gnu/bin/ld: bootparam_sa0.elf: error: PHDR segment not covered by LOAD segment
/usr/lib/gcc-cross/aarch64-linux-gnu/14/../../../../aarch64-linux-gnu/bin/ld: cert_header_sa6.elf: error: PHDR segment not covered by LOAD segment

Fix the tools build.

This change is similar to commit 72f4b70e8e8e ("fix(rcar-layout): fix tool build") done for R-Car tools.

Change-Id: Ie4fb6c4d32982a8ce399e1fde0736cb43c18b34d
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

show more ...

Merge "build: consolidate directory creation rules" into integration

build: consolidate directory creation rules

This commit streamlines directory creation by introducing a single
pattern rule to automatically make directories for which there is a
dependency.

We cur

build: consolidate directory creation rules

This commit streamlines directory creation by introducing a single
pattern rule to automatically make directories for which there is a
dependency.

We currently use several macros to generate rules to create directories
upon dependence, which is a significant amount of code and a lot of
redundancy. The rule introduced by this change represents a catch-all:
any rule dependency on a path ending in a forward slash is automatically
created.

Now, rules can rely on an unordered dependency (`|`) on `$$(@D)/` which,
when secondary expansion is enabled, expands to the directory of the
target being built, e.g.:

build/main.o: main.c | $$(@D)/ # automatically creates `build/`

Change-Id: I7e554efa2ac850e779bb302fd9c7fbb239886c9f
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge changes from topic "ck/tf-a/target-properties" into integration

* changes:
build(rzg-layout): split combined targets
build(rcar-layout): split combined targets

build(rzg-layout): split combined targets

This is a small change to split up the generation of the RZ/G layout
images into unique targets. This is predominantly for cleanliness
reasons - Make curren

build(rzg-layout): split combined targets

This is a small change to split up the generation of the RZ/G layout
images into unique targets. This is predominantly for cleanliness
reasons - Make current doesn't know about the `.bin` and `.srec`
binaries generated by the `.elf` target.

Change-Id: I81251ac647b85c5eec8f910ddc841a5a32b49e67
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge changes from topic "ck/tf-a/verbosity-cleanup" into integration

* changes:
build: unify verbosity handling
build: add facilities for interpreting boolean values
build: add string casing

Merge changes from topic "ck/tf-a/verbosity-cleanup" into integration

* changes:
build: unify verbosity handling
build: add facilities for interpreting boolean values
build: add string casing facilities to utilities

show more ...

build: unify verbosity handling

This change introduces a few helper variables for dealing with verbose
and silent build modes: `silent`, `verbose`, `q` and `s`.

The `silent` and `verbose` variables

build: unify verbosity handling

This change introduces a few helper variables for dealing with verbose
and silent build modes: `silent`, `verbose`, `q` and `s`.

The `silent` and `verbose` variables are boolean values determining
whether the build system has been configured to run silently or
verbosely respectively (i.e. with `--silent` or `V=1`).

These two modes cannot be used together - if `silent` is truthy then
`verbose` is always falsy. As such:

make --silent V=1

... results in a silent build.

In addition to these boolean variables, we also introduce two new
variables - `s` and `q` - for use in rule recipes to conditionally
suppress the output of commands.

When building silently, `s` expands to a value which disables the
command that follows, and `q` expands to a value which supppresses
echoing of the command:

$(s)echo 'This command is neither echoed nor executed'
$(q)echo 'This command is executed but not echoed'

When building verbosely, `s` expands to a value which disables the
command that follows, and `q` expands to nothing:

$(s)echo 'This command is neither echoed nor executed'
$(q)echo 'This command is executed and echoed'

In all other cases, both `s` and `q` expand to a value which suppresses
echoing of the command that follows:

$(s)echo 'This command is executed but not echoed'
$(q)echo 'This command is executed but not echoed'

The `s` variable is predominantly useful for `echo` commands, where you
always want to suppress echoing of the command itself, whilst `q` is
more useful for all other commands.

Change-Id: I8d8ff6ed714d3cb401946c52955887ed7dca602b
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge "build: use GCC to link by default" into integration

build: use GCC to link by default

When configuring GNU GCC as the C compiler, we usually use the GNU BFD
linker directly to link by default. However, this complicates things
because we also need to

build: use GCC to link by default

When configuring GNU GCC as the C compiler, we usually use the GNU BFD
linker directly to link by default. However, this complicates things
because we also need to support LTO, which can only be done when linking
is done via the C compiler, and we cannot change the linker later on if
some other part of the build system wants to enable LTO.

This change migrates the default choice of linker to GCC if the C
compiler is GCC, in order to enable this use-case. This should have no
impact on anything outside of the build system, as by default GCC merely
acts as a wrapper around BFD.

Change-Id: I40771be2b0571def67bbfde9e877e7629ec8cdaa
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge "build: use new toolchain variables for tools" into integration

Merge "build: refactor toolchain detection" into integration

build: use new toolchain variables for tools

This change migrates the values of `CC`, `CPP`, `AS` and other toolchain
variables to the new `$(toolchain)-$(tool)` variables, which were
introduced by

build: use new toolchain variables for tools

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>

show more ...

build: refactor toolchain detection

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 to

build: refactor toolchain detection

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>

show more ...

Merge changes from topics "rcar-tools-fix", "toolchain-cleanup" into integration

* changes:
build: remove the `NM` variable
build: prefer `gcc-ar` over `ar`
build: add `--no-warn-rwx-segments`

Merge changes from topics "rcar-tools-fix", "toolchain-cleanup" into integration

* changes:
build: remove the `NM` variable
build: prefer `gcc-ar` over `ar`
build: add `--no-warn-rwx-segments` when linking with GCC
build: always use the C compiler to assemble
build: always use the C compiler to preprocess
fix(rcar): fix implicit rule invocations in tools

show more ...

fix(rcar): fix implicit rule invocations in tools

The `rzg_layout_create` and `rcar_layout_create` tools have a rule to
build object files from C files, but it depends on object files in the
parent

fix(rcar): fix implicit rule invocations in tools

The `rzg_layout_create` and `rcar_layout_create` tools have a rule to
build object files from C files, but it depends on object files in the
parent directory when it should depend on object files in the current
directory. Consequently, the rule is not triggering and the implicit C
compilation rule is executed instead. This rule works, so I have
replaced the broken rule with exactly the same command as what the
implicit rule is executing and fixed the dependency.

Change-Id: Ib8d640361adff8c4d660738dda230e5536bec629
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

Merge changes Ic9bacaf3,I99a18dbb,I34803060,I3ed55aa4,Ic8eed072, ... into integration

* changes:
doc: renesas: Update RZ/G2 code owner list
plat: renesas: rzg: DT memory node enhancements
rene

Merge changes Ic9bacaf3,I99a18dbb,I34803060,I3ed55aa4,Ic8eed072, ... into integration

* changes:
doc: renesas: Update RZ/G2 code owner list
plat: renesas: rzg: DT memory node enhancements
renesas: rzg: emmc: Enable RZ/G2M support
plat: renesas: rzg: Add HopeRun HiHope RZ/G2M board support
drivers: renesas: rzg: Add HiHope RZ/G2M board support
tools: renesas: Add tool support for RZ/G2 platforms

show more ...

tools: renesas: Add tool support for RZ/G2 platforms

Add tool support for creating bootparam and cert_header images
for RZ/G2 SoC based platforms.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.co

tools: renesas: Add tool support for RZ/G2 platforms

Add tool support for creating bootparam and cert_header images
for RZ/G2 SoC based platforms.

Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Change-Id: Iab8ba6eda442c8d75f23c5633b8178f86339e4c9

show more ...