Since 2f1c5e7eb1 ("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
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>
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>
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>
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>
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>
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>
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>
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>
Fixed the check of the address range which the program is loaded to.
Use the addresses and sizes in the BL31 and BL32 certificates to check
that they are within the range of the target address and size
defined inside the TF-A.
It also uses the addresses and sizes in the BL33x certificates to check
that they are outside the protected area defined inside the TF-A.
Signed-off-by: Hideyuki Nitta <hideyuki.nitta.jf@hitachi.com>
Signed-off-by: Toshiyuki Ogasahara <toshiyuki.ogasahara.bo@hitachi.com>
Signed-off-by: Yoshifumi Hosoya <yoshifumi.hosoya.wj@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Code clean up
Change-Id: Iade15431fc86587489fb0ca9106f6baaf7e926e2
The memory area size of OP-TEE was changed from 1MB to 2MB
because the size of OP-TEE has increased.
Signed-off-by: Toshiyuki Ogasahara <toshiyuki.ogasahara.bo@hitachi.com>
Signed-off-by: Yoshifumi Hosoya <yoshifumi.hosoya.wj@renesas.com>
Change-Id: Ic8a165c83a3a9ef2829f68d5fabeed9ccb6da95e
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
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>
