Merge changes Id711e387,I531a2ee1,Ic5b48514,I81f5f663,I6c529c13, ... into integration

* changes:
refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS
fix(build): simplify the -target options
fe

Merge changes Id711e387,I531a2ee1,Ic5b48514,I81f5f663,I6c529c13, ... into integration

* changes:
refactor(romlib): absorb WRAPPER_FLAGS into LDFLAGS
fix(build): simplify the -target options
feat(build): allow full LTO builds with clang
refactor(build): make sorting of sections generic
feat(build): use clang as a linker
fix(build): correctly detect that an option is missing with ld_option
feat(build): pass cflags to the linker when LTO is enabled

show more ...

fix(build): correctly detect that an option is missing with ld_option

We support building directly with ld and indirectly with gcc. The
`ld_option` macro is oblivious to this and does a check for bo

fix(build): correctly detect that an option is missing with ld_option

We support building directly with ld and indirectly with gcc. The
`ld_option` macro is oblivious to this and does a check for both styles
of invocation. However, the gcc one is incorrect - gcc returns `0` even
when it has printed an error saying that it doesn't recognise the
option. Add a discovery function for each linker we expect and
dynamically dispatch to the correct one.

While we're at it, also add a little bit of code to return the -Wl
prefix for gcc and not for ld.

All of the above is also true for clang and lld, although they don't
suffer from the problem that gcc does.

Change-Id: I4f7bdf40c01f4c5df9c177f5048f5e349bc2b9c9
Co-authored-by: Chris Kay <chris.kay@arm.com>
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...

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 changes from topic "clang-rockchip" into integration

* changes:
build(rk3399): m0: Makefile: respect verbosity for linkerfile
build(rk3399): m0: fail linker and assembler on warnings
bui

Merge changes from topic "clang-rockchip" into integration

* changes:
build(rk3399): m0: Makefile: respect verbosity for linkerfile
build(rk3399): m0: fail linker and assembler on warnings
build(rk3399): m0: remove redundant M0_CROSS_COMPILE
feat(build): rk3399: m0: add support for new binutils versions
fix(rk3399): m0: Makefile: fix outside array bounds warning
refactor(rk3399): m0: Makefile: use same tools as in build_macros.mk
refactor(rk3399): m0: Makefile: specify ARCH to be rk3399-m0
fix(rk3588): pmu: fix assembly symbol redefinition
fix(rockchip): pmu: Do not mark already defined functions as weak
fix(rk3399): dram: Fix build with gcc 11
fix(rk3288): remove unused function
fix(px30): remove unused function

show more ...

Merge changes Ibe44f19e,I9e023edb,I96d655fc into integration

* changes:
build: use parameters in calls to `MAKE_DEP`
build: disable suffix rules globally
build: use full paths for generated li

Merge changes Ibe44f19e,I9e023edb,I96d655fc into integration

* changes:
build: use parameters in calls to `MAKE_DEP`
build: disable suffix rules globally
build: use full paths for generated libraries

show more ...

build: disable suffix rules globally

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 occas

build: disable suffix rules globally

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>

show more ...

build(rk3399): m0: Makefile: respect verbosity for linkerfile

All commands in the Makefile respect the verbosity except this one, so
let's be consistent and respect it for that one as well.

Signed-

build(rk3399): m0: Makefile: respect verbosity for linkerfile

All commands in the Makefile respect the verbosity except this one, so
let's be consistent and respect it for that one as well.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Change-Id: I5d1af4ee321e29449b927509cfa5ece01765a99e

show more ...

build(rk3399): m0: fail linker and assembler on warnings

Match the top Makefile flags and fail on warnings for the linker (ld)
and assembler (as).

Signed-off-by: Quentin Schulz <quentin.schulz@cher

build(rk3399): m0: fail linker and assembler on warnings

Match the top Makefile flags and fail on warnings for the linker (ld)
and assembler (as).

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Change-Id: I53fbcbdbda109b1dfe39b390a41c1ef3fd7d3e04

show more ...

build(rk3399): m0: remove redundant M0_CROSS_COMPILE

The included toolchain.mk uses M0_CROSS_COMPILE if present, or defaults
to arm-none-eabi-, which is the value this variable holds in this
Makefil

build(rk3399): m0: remove redundant M0_CROSS_COMPILE

The included toolchain.mk uses M0_CROSS_COMPILE if present, or defaults
to arm-none-eabi-, which is the value this variable holds in this
Makefile.

Let's remove it.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Change-Id: Id805703cec0f118acdf4629e345924031b2c8c4b

show more ...

feat(build): rk3399: m0: add support for new binutils versions

c.f. 1f49db5f25cd ("feat(build): add support for new binutils versions")
for the actual reasons. This commit applies the same logic but

feat(build): rk3399: m0: add support for new binutils versions

c.f. 1f49db5f25cd ("feat(build): add support for new binutils versions")
for the actual reasons. This commit applies the same logic but for the
m0 FW for RK3399 since it uses a different set of flags.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Change-Id: I955b229a7d9d473892f3f3483eaf6e33ffe0e273

show more ...

fix(rk3399): m0: Makefile: fix outside array bounds warning

Both GCC and clang actually complain about:

"""
In file included from src/dram.c:12:
src/dram.c: In function 'm0_main':
include/rk3399_mc

fix(rk3399): m0: Makefile: fix outside array bounds warning

Both GCC and clang actually complain about:

"""
In file included from src/dram.c:12:
src/dram.c: In function 'm0_main':
include/rk3399_mcu.h:15:34: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=]
15 | (*(volatile unsigned int *)(c)); __v; })
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/rk3399_mcu.h:16:69: note: in definition of macro 'mmio_write_32'
16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v))
| ^
src/dram.c:67:23: note: in expansion of macro 'mmio_read_32'
67 | mmio_read_32(PARAM_ADDR + PARAM_FREQ_SELECT));
| ^~~~~~~~~~~~
cc1: note: source object is likely at address zero
In function 'ddr_set_pll',
inlined from 'm0_main' at src/dram.c:71:2:
include/rk3399_mcu.h:14:40: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=]
14 | #define mmio_read_32(c) ({unsigned int __v = \
| ^~~
include/rk3399_mcu.h:16:69: note: in definition of macro 'mmio_write_32'
16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v))
| ^
src/dram.c:47:23: note: in expansion of macro 'mmio_read_32'
47 | mmio_read_32(PARAM_ADDR + PARAM_DPLL_CON0));
| ^~~~~~~~~~~~
In function 'm0_main':
cc1: note: source object is likely at address zero
In function 'ddr_set_pll',
inlined from 'm0_main' at src/dram.c:71:2:
include/rk3399_mcu.h:14:40: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=]
14 | #define mmio_read_32(c) ({unsigned int __v = \
| ^~~
include/rk3399_mcu.h:16:69: note: in definition of macro 'mmio_write_32'
16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v))
| ^
src/dram.c:49:23: note: in expansion of macro 'mmio_read_32'
49 | mmio_read_32(PARAM_ADDR + PARAM_DPLL_CON1));
| ^~~~~~~~~~~~
In function 'm0_main':
cc1: note: source object is likely at address zero
include/rk3399_mcu.h:16:35: warning: array subscript 0 is outside array bounds of 'volatile unsigned int[0]' [-Warray-bounds=]
16 | #define mmio_write_32(c, v) ((*(volatile unsigned int *)(c)) = (v))
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/dram.c:80:9: note: in expansion of macro 'mmio_write_32'
80 | mmio_write_32(PARAM_ADDR + PARAM_M0_DONE, M0_DONE_FLAG);
| ^~~~~~~~~~~~~
cc1: note: source object is likely at address zero
"""

The global Makefile defines --param=min-pagesize=0 already, so let's
just apply the same fix for the m0 part of the RK3399 binary.

Suggested-by: Boyan Karatotev <boyan.karatotev@arm.com>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Change-Id: I4f29a579b9e4b01aa2540746ef46e2a382f0012e

show more ...

refactor(rk3399): m0: Makefile: use same tools as in build_macros.mk

This should make it easier to spot mistakes or reuse rules by comparing
this Makefile with build_macros.mk.

Additionally, this a

refactor(rk3399): m0: Makefile: use same tools as in build_macros.mk

This should make it easier to spot mistakes or reuse rules by comparing
this Makefile with build_macros.mk.

Additionally, this allows to provide flags that aren't supported by CC
(e.g. --no-warn-rwx-segments).

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Change-Id: Iba121d53959ff4f8bd10a14280c4d93a710dc9db

show more ...

refactor(rk3399): m0: Makefile: specify ARCH to be rk3399-m0

cortex-m0 is not a recognized ARCH in our build system so most macros
need to be redefined to use hardcoded strings which isn't ideal.

W

refactor(rk3399): m0: Makefile: specify ARCH to be rk3399-m0

cortex-m0 is not a recognized ARCH in our build system so most macros
need to be redefined to use hardcoded strings which isn't ideal.

While this now has limited use-case, a future commit will allow to make
use of this fixed variable via macros.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Change-Id: I6d1e588d2ab27d7a60f32e5369370c43d68b3a20

show more ...

Merge changes from topic "dynamic-toolchain" into integration

* changes:
build: allow multiple toolchain defaults
build: determine toolchain tools dynamically

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 ...

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 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 ...

build: remove the `NM` variable

No part of the build system uses the `NM` variable, which is usually
used to dump symbol tables from compiled images. This change removes all
declarations of it.

Cha

build: remove the `NM` variable

No part of the build system uses the `NM` variable, which is usually
used to dump symbol tables from compiled images. This change removes all
declarations of it.

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

show more ...

build: prefer `gcc-ar` over `ar`

The `gcc-ar` wrapper exists to make it easier to support LTO on some
versions of GCC. The two commands are compatible, accepting exactly the
same arguments, so this

build: prefer `gcc-ar` over `ar`

The `gcc-ar` wrapper exists to make it easier to support LTO on some
versions of GCC. The two commands are compatible, accepting exactly the
same arguments, so this change moves us to `gcc-ar` to ensure that we
are configuring LTO correctly.

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

show more ...