Merge "feat(cpufeat): fix build with ENABLE_FEAT_PAUTH_LR=1" into integration

feat(cpufeat): fix build with ENABLE_FEAT_PAUTH_LR=1

Since build system underwent some refactoring, the build has
been failing with ENABLE_FEAT_PAUTH_LR=1 so this patch fixes it

Change-Id: I1a3faad

feat(cpufeat): fix build with ENABLE_FEAT_PAUTH_LR=1

Since build system underwent some refactoring, the build has
been failing with ENABLE_FEAT_PAUTH_LR=1 so this patch fixes it

Change-Id: I1a3faad53b508d760a65656dad78057027a7d69c
Signed-off-by: John Powell <john.powell@arm.com>

show more ...

Merge changes I9bc7b609,Ie56dc965,Ic57d46bf,I3f2ab549,I3ad715fa, ... into integration

* changes:
refactor(build): initialise `arch-features` closer to where it is needed
refactor(build): define

Merge changes I9bc7b609,Ie56dc965,Ic57d46bf,I3f2ab549,I3ad715fa, ... into integration

* changes:
refactor(build): initialise `arch-features` closer to where it is needed
refactor(build): define the W and DEBUG flags in the standard way
refactor(build): put the cross referencing of options together
fix: use LDLIBS instead of LDFLAGS for library search paths
fix(build): remove redundant variables
fix(intel): fix variable may be used uninitialized error

show more ...

refactor(build): initialise `arch-features` closer to where it is needed

Change-Id: I9bc7b609e7cb5aa42528ba151b5a30c386de0792
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

Merge "build: skip toolchain detection for some targets" into integration

build: skip toolchain detection for some targets

Most developers run the `clean`, `checkpatch` and other similar targets
without specifying any other additional build options. When combined
with a f

build: skip toolchain detection for some targets

Most developers run the `clean`, `checkpatch` and other similar targets
without specifying any other additional build options. When combined
with a flow where the developer passes `CROSS_COMPILE` or `CC`
explicitly, and where the default-configured tools are not on the PATH,
these targets will warn about unrecognized toolchain tools.

This change is a workaround for this whereby the toolchain makefile is
not expanded unless a target *not* named `*clean`, `check*` `doc` or
`*tool` has been specified.

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

show more ...

Merge "build: use toolchain identifiers in conditions" into integration

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

build: use toolchain identifiers in conditions

The toolchain refactor change introduces the `${toolchain}-${tool}-id`
variables, which provide identifiers for all of the toolchain tools used
by the

build: use toolchain identifiers in conditions

The toolchain refactor change introduces the `${toolchain}-${tool}-id`
variables, which provide identifiers for all of the toolchain tools used
by the build system. This change replaces the various conditions that
are in use to identify these tools based on the path with a standard set
of comparisons against these new identifier variables.

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

show more ...

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

Merge changes from topic "gr/build_refac" into integration

* changes:
refactor(build): minor updates
refactor(build): remove enabling feat
fix(build): march handling with arch-features
refac

Merge changes from topic "gr/build_refac" into integration

* changes:
refactor(build): minor updates
refactor(build): remove enabling feat
fix(build): march handling with arch-features
refactor(build): refactor mandatory options

show more ...

fix(build): march handling with arch-features

Currently all march compiler option handling is moved to build
utility in march.mk.

We pass arch-features to build which appends to march options,
so t

fix(build): march handling with arch-features

Currently all march compiler option handling is moved to build
utility in march.mk.

We pass arch-features to build which appends to march options,
so this should be done once we decide march options and moving
it to march.mk file.

Change-Id: Ifaf99af5f371fd28db376a12657ccf4f363295c2
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

Merge "feat(build): march option selection" into integration

feat(build): march option selection

Current build infra uses ARM_ARCH_MAJOR/MINOR to come up with march
version and uses that march version with the compiler.

However in certain situations this is

feat(build): march option selection

Current build infra uses ARM_ARCH_MAJOR/MINOR to come up with march
version and uses that march version with the compiler.

However in certain situations this is not ideal, like for example when
we build with gcc-11 which supports only till march=armv8.5 but
we need to build for 8.8 build, this means we need to bump down
MAJOR/MINOR and we can't rely on major and minor values from the
platform to select march value and build infra doesn't even try
to compile and fails with not supported MAJOR/MINOR.

By adding a march build helper we try to check if compiler supports
given march value from MAJOR/MINOR values from platform, if compiler
doesn't support then we try to check what's the max or best supported
march version by compiler and choose that march value and try to
compile with that.

This is a supportive mechanism which will decouple march reliance on
MAJOR/MINOR values from platform and will pave way for setting up
enabling of features based on MAJOR/MINOR without worrying about the
compiler not supporting given MAJOR/MINOR.

Also in TF-A we use generic instructions without much reliance or need
for exact march necessity. So enabling and building features from
armv-8.8 using an armv-8.5 march value is still going to be fine.

Please note: Platforms are free to freeze their march values using
`MARCH_DIRECTIVE`. In absence of this define we are going to poke
the compiler and come up with a potential march value.

Change-Id: I673061a269ec9018ff12e75dc375979f5e33b7d1
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...