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 I04ecd50f,I830b53e2 into integration

* changes:
fix(rcar3-drivers): disable A/B loader support by default
fix(rcar-layout): fix tool build

fix(rcar-layout): 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/a

fix(rcar-layout): 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.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Change-Id: I830b53e23f25c62da3583c1c3e02e0607a237d15

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(rcar-layout): split combined targets

This is a small change to split up the generation of the R-Car layout
images into unique targets. This is predominantly for cleanliness
reasons - Make curr

build(rcar-layout): split combined targets

This is a small change to split up the generation of the R-Car 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: I624bc0c62e99cead66a6d6e25ff016aecf6b985a
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 pull request #1914 from marex/arm/master/d3draak-v2.0.1

Arm/master/d3draak v2.0.1

rcar_gen3: plat: Add initial D3 support

Add R-Car D3 SoC platform specifics. Driver, PFC, QoS, DDR init code
will be added separately.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Merge pull request #1582 from ldts/rcar_gen3/upstream

rcar_gen3: initial support

rcar-gen3: initial commit for the rcar-gen3 boards

Reference code:
==============

rar_gen3: IPL and Secure Monitor Rev1.0.22
https://github.com/renesas-rcar/arm-trusted-firmware [rcar_gen3]

Author

rcar-gen3: initial commit for the rcar-gen3 boards

Reference code:
==============

rar_gen3: IPL and Secure Monitor Rev1.0.22
https://github.com/renesas-rcar/arm-trusted-firmware [rcar_gen3]

Author: Takuya Sakata <takuya.sakata.wz@bp.renesas.com>
Date: Thu Aug 30 21:26:41 2018 +0900
Update IPL and Secure Monitor Rev1.0.22

General Information:
===================

This port has been tested on the Salvator-X Soc_id r8a7795 revision
ES1.1 (uses an SPD).

Build Tested:
-------------
ATFW_OPT="LSI=H3 RCAR_DRAM_SPLIT=1 RCAR_LOSSY_ENABLE=1"
MBEDTLS_DIR=$mbedtls

$ make clean bl2 bl31 rcar PLAT=rcar ${ATFW_OPT} SPD=opteed

Other dependencies:
------------------
* mbed_tls:
git@github.com:ARMmbed/mbedtls.git [devel]

Merge: 68dbc94 f34a4c1
Author: Simon Butcher <simon.butcher@arm.com>
Date: Thu Aug 30 00:57:28 2018 +0100

* optee_os:
https://github.com/BayLibre/optee_os

Until it gets merged into OP-TEE, the port requires Renesas' Trusted
Environment with a modification to support power management.

Author: Jorge Ramirez-Ortiz <jramirez@baylibre.com>
Date: Thu Aug 30 16:49:49 2018 +0200
plat-rcar: cpu-suspend: handle the power level
Signed-off-by: Jorge Ramirez-Ortiz <jramirez@baylibre.com>

* u-boot:
The port has beent tested using mainline uboot.

Author: Fabio Estevam <festevam@gmail.com>
Date: Tue Sep 4 10:23:12 2018 -0300

*linux:
The port has beent tested using mainline kernel.

Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Sep 16 11:52:37 2018 -0700
Linux 4.19-rc4

Overview
---------

BOOTROM starts the cpu at EL3; In this port BL2 will therefore be entered
at this exception level (the Renesas' ATF reference tree [1] resets into
EL1 before entering BL2 - see its bl2.ld.S)

BL2 initializes DDR (and i2c to talk to the PMIC on some platforms)
before determining the boot reason (cold or warm).

During suspend all CPUs are switched off and the DDR is put in
backup mode (some kind of self-refresh mode). This means that BL2 is
always entered in a cold boot scenario.

Once BL2 boots, it determines the boot reason, writes it to shared
memory (BOOT_KIND_BASE) together with the BL31 parameters
(PARAMS_BASE) and jumps to BL31.

To all effects, BL31 is as if it is being entered in reset mode since
it still needs to initialize the rest of the cores; this is the reason
behind using direct shared memory access to BOOT_KIND_BASE and
PARAMS_BASE instead of using registers to get to those locations (see
el3_common_macros.S and bl31_entrypoint.S for the RESET_TO_BL31 use
case).

Depending on the boot reason BL31 initializes the rest of the cores:
in case of suspend, it uses a MBOX memory region to recover the
program counters.

[1] https://github.com/renesas-rcar/arm-trusted-firmware
Tests
-----

* cpuidle
-------
enable kernel's cpuidle arm_idle driver and boot

* system suspend
--------------
$ cat suspend.sh
#!/bin/bash
i2cset -f -y 7 0x30 0x20 0x0F
read -p "Switch off SW23 and press return " foo
echo mem > /sys/power/state

* cpu hotplug:
------------
$ cat offline.sh
#!/bin/bash
nbr=$1
echo 0 > /sys/devices/system/cpu/cpu$nbr/online
printf "ONLINE: " && cat /sys/devices/system/cpu/online
printf "OFFLINE: " && cat /sys/devices/system/cpu/offline

$ cat online.sh
#!/bin/bash
nbr=$1
echo 1 > /sys/devices/system/cpu/cpu$nbr/online
printf "ONLINE: " && cat /sys/devices/system/cpu/online
printf "OFFLINE: " && cat /sys/devices/system/cpu/offline

Signed-off-by: ldts <jramirez@baylibre.com>

show more ...