The ROMLIB build currently has a strong dependency on MbedTLS. This
patch has been introduced to remove this dependency, making it more
flexible.
Change-Id: If8c4cc7cf557687f40b235a4b8f931cfb70943fd
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Remove the unused jmptbl.i file. The ROMLIB Makefile expects
platforms to provide the jmptbl according to their requirements.
Change-Id: I2784eaca5061aa77fdd99f7b2b5ef5a1145475e9
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
This change modifies the build rules for static libraries so that
individual rules which use those libraries depend directly on the
archive files that are generated, rather than their phony target aliases
and `-lX` link flags.
The goal of this is to clean up Make's view of the dependencies between
files, avoiding phony targets (which do not honour timestamps) making
their way into intermediate dependencies.
Change-Id: I96d655fcd94dc259ffa6e8970b2be7b8c7e11123
Signed-off-by: Chris Kay <chris.kay@arm.com>
When building with many cores (-j64), there's a good chance that the
rule to make the build directory is getting executed at the same time as
the rule for romlib.ldflags. On my machine, the former is slower,
resulting in romlib_generator.py not being able to write the file as the
directory doesn't exist yet.
Add an explicit dependency on the build directory for the target.
This ensures that we have a build directory before we start putting
stuff in it.
Change-Id: I120b0dc66c692c759ab1046c735be405b41db87c
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Grouped targets are a feature introduced with GNU Make 4.3 which enable
rules with multiple targets to communicate that all of the targets of
that rule are built simultaneously, rather than independently.
For example, without grouped targets the following rule may be executed
twice:
a.txt b.txt:
touch a.txt b.txt
# $ remake -j2 a.txt b.txt
# touch a.txt b.txt
# touch a.txt b.txt
In this example, both `a.txt` and `b.txt` are touched twice, when the
rule should only be executed once. Instead, this rule can use a grouped
target:
a.txt b.txt &:
touch a.txt b.txt
# $ remake -j2 a.txt b.txt
# touch a.txt b.txt
# remake: 'b.txt' is up to date.
In this case, both `a.txt` and `b.txt` are created once only, as Make
now knows that the recipe will create both files.
Note that pattern rules with multiple targets always behave this way.
Previously, we assumed that the grouped target feature was available,
but on systems still packaging Make 4.2, most prominently Ubuntu 20.04,
this is not the case. This change adds a check to ensure that we do not
use grouped targets if they are unavailable.
Change-Id: Ifd9da35421ae11468d7a25d3cbc76f6036921749
Signed-off-by: Chris Kay <chris.kay@arm.com>
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>
The problem that this resolves is a bit involved; the following
must be met at the same time for some function <to_be_wrapped>:
* to_be_wrapped must be specified as part of the romlib
* to_be_wrapped must _not_ be referenced by any translation unit
in TF-A
* to_be_wrapped must be referenced by a translation unit in a
dependent library, mbedtls for example.
Under these circumstances, to_be_wrapped will not be wrapped, and
will instead reference its original definition while simultaneously
residing in romlib.
This is a side effect of two issues with romlib prior to this patch:
1 to_be_wrapped is expected to wrap by duplicating its definition.
This causes any condition that links against both the base and
wrapper functions to be a link error (duplicate symbol definition).
2 to_be_wrapped is in its own translation unit
This causes the wrappers to be used by TF-A in an as needed.
The duplicate function definitions can be worked around using the
linker's `--wrap` flag, which redirects all references to a symbol
to resolve to `__wrap_<symbol>` and the original symbol to be
available as `__real_<symbol>`. Most of the changes handle creating
this arguments and passing them to the linker.
Further, once you use the linker's wrap, you will encounter another
issue: if TF-A does not use a function, its wrapper is not present.
This causes link issues when a library and not TF-A uses the wrapper.
Note that this issue would have been resolved previously by ignoring
the wrapper and using the base definition.
This further issue is worked around by concatenating the assembly for
all of the wrappers into a single translation unit. It's possible to
work around this issue in a few other ways, including reordering the
libraries passed to the linker to place libwrapper.a last or grouping
the libraries so that symbols from later libraries may be resolved
with prior libraries.
I chose the translation unit concatenation approach as it revealed
that a jumptable has duplicate symbols within it.
Change-Id: Ie57b5ae69bde2fc8705bdc7a93fae3ddb5341ed9
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
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 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>
The Makefile rule for the libwrappers object files places a dependency
on a timestamp file. This timestamp file is created by the recipe that
generates the libwrappers sources, and was presumably introduced to
indicate to Make that all of the source files are generated
simultaneously by that rule.
Instead, we can use a grouped target rule, which uses `&:` instead of
`:`. This communicates to Make that all of the targets listed are
generated at once.
To demonstrate, the following two Makefile rules differ in their
behaviour:
a.x b.x c.x: # targets may be updated independently
... # generate a.x, b.x and c.x
a.x b.x c.x &: # all targets are updated at once
... # generate a.x, b.x and c.x
While both recipes do generate all three files, only the second rule
communicates this fact to Make. As such, Make can reason that if one of
the files is up to date then all of them are, and avoid re-running the
rule for any generated file that it has not already run it for.
Change-Id: I10b49eb72b5276c7f9bd933900833b03a61cff2f
Signed-off-by: Chris Kay <chris.kay@arm.com>
The `romlib_generator.py` script may generate duplicate wrapper sources,
which is undesirable when using them to generate Makefile rules as Make
will warn about duplicated targets.
This change sorts the wrapper sources returned from this script, which
has the effect of also de-duplicating them.
Change-Id: I109607ef94f77113a48cc0d6e07877efd1971dbc
Signed-off-by: Chris Kay <chris.kay@arm.com>
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>
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 `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>
The ROM library is the only component in the repository that compiles
assembly files using the assembler directly. This change migrates it to
the C compiler instead, like the rest of the project.
Change-Id: I6c50660eeb9be2ca8dcb0e626c37c197466b0fa1
Signed-off-by: Chris Kay <chris.kay@arm.com>
We're a bit inconsistent about which tool we use to preprocess source
files; in some places we use `$(CC) -E` whilst in others we use `cpp`.
This change forces all invocations of the C preprocessor to use the
first scheme, which ensures that the preprocessor behaves the same way
as the C compiler used when compiling C source files.
Change-Id: Iede2f25ff86ea8b43d7a523e32648058d5023832
Signed-off-by: Chris Kay <chris.kay@arm.com>
Align entire TF-A to use Arm in copyright header.
Change-Id: Ief9992169efdab61d0da6bd8c5180de7a4bc2244
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
There are a variety of code styles used by the various linker scripts
around the code-base. This change brings them in line with one another
and attempts to make the scripts more friendly for skim-readers.
Change-Id: Ibee2afad0d543129c9ba5a8a22e3ec17d77e36ea
Signed-off-by: Chris Kay <chris.kay@arm.com>
If the user tries to change BUILD_BASE to put the build products outside
the build tree the compile will fail due to hard coded assumptions that
$BUILD_BASE is a relative path. Fix by using $(abspath $(BUILD_BASE))
to rationalize to an absolute path every time and remove the relative
path assumptions.
This patch also adds documentation that BUILD_BASE can be specified by
the user.
Signed-off-by: Grant Likely <grant.likely@arm.com>
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ib1af874de658484aaffc672f30029b852d2489c8
This patch adds 'fdtw_read_bytes' and 'fdtw_write_inplace_bytes'
functions for read/write array of bytes from/to a given property.
It also adds 'fdt_setprop_inplace_namelen_partial' to jmptbl.i
files for builds with USE_ROMLIB=1 option.
Change-Id: Ied7b5c8b38a0e21d508aa7bcf5893e656028b14d
Signed-off-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
NOTE: __ASSEMBLY__ macro is now deprecated in favor of __ASSEMBLER__.
All common C compilers predefine a macro called __ASSEMBLER__ when
preprocessing a .S file. There is no reason for TF-A to define it's own
__ASSEMBLY__ macro for this purpose instead. To unify code with the
export headers (which use __ASSEMBLER__ to avoid one extra dependency),
let's deprecate __ASSEMBLY__ and switch the code base over to the
predefined standard.
Change-Id: Id7d0ec8cf330195da80499c68562b65cb5ab7417
Signed-off-by: Julius Werner <jwerner@chromium.org>
The features of the previously existing gentbl, genvar and genwrappers
scripts were reimplemented in the romlib_generator.py Python script.
This resulted in more readable and maintainable code and the script
introduces additional features that help dependency handling in
makefiles. The assembly templates were separated from the script logic
and were collected in the 'templates' directory.
The targets and their dependencies were reorganized in the makefile and
the dependency handling of included index files is possible now.
Incremental build is available in case of modifying the index files.
Signed-off-by: Imre Kis <imre.kis@arm.com>
Change-Id: I79f65fab9dc5c70d1f6fc8f57b2a3009bf842dc5
When TF-A is compiled with BTI enabled, the branches in the ROMLIB
jumptable must be preceded by a "bti j" instruction.
Moreover, when the additional "bti" instruction is inserted, the
jumptable entries have a distance of 8 bytes between them instead of 4.
Hence, the wrappers are also modified accordinly.
If TF-A is compiled without BTI enabled, the ROMLIB jumptable and
wrappers are generated as before.
Change-Id: Iaa59897668f8e59888d39046233300c2241d8de7
Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
* Optimization flags were only provided for debug build.
* Set optimisation level to -O1
* Remove CFLAGS which is never used for romlib
* Remove the ignored -g flag from LDFLAGS
Change-Id: Id4b69026d8a322ed4cb0acf06c350f13d31571ad
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
Fixed the below bugs:
1) Bug related to build flag V=1: if the flag was V=0, building with
ROMLIB would fail.
2) Due to a syntax bug in genwrappers.sh, index file entries marked as
"patch" or "reserved" were ignored.
3) Added a prepending hash to constants that genwrappers is generating.
4) Due to broken dependencies, currently the inclusion functionality is
intentionally not utilised. This is why the contents of romlib/jmptbl.i
have been copied to platform specific jmptbl.i files. As a result of the
broken dependencies, when changing the index files, e.g. patching
functions, a clean build is always required. This is a known issue that
will be fixed in the future.
Change-Id: I9d92aa9724e86d8f90fcd3e9f66a27aa3cab7aaa
Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
Enforce full include path for includes. Deprecate old paths.
The following folders inside include/lib have been left unchanged:
- include/lib/cpus/${ARCH}
- include/lib/el3_runtime/${ARCH}
The reason for this change is that having a global namespace for
includes isn't a good idea. It defeats one of the advantages of having
folders and it introduces problems that are sometimes subtle (because
you may not know the header you are actually including if there are two
of them).
For example, this patch had to be created because two headers were
called the same way: e0ea0928d5 ("Fix gpio includes of mt8173 platform
to avoid collision."). More recently, this patch has had similar
problems: 46f9b2c3a2 ("drivers: add tzc380 support").
This problem was introduced in commit 4ecca33988 ("Move include and
source files to logical locations"). At that time, there weren't too
many headers so it wasn't a real issue. However, time has shown that
this creates problems.
Platforms that want to preserve the way they include headers may add the
removed paths to PLAT_INCLUDES, but this is discouraged.
Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
This patch allows platforms to define their
own jump table list for library at ROM. The
file has the list of functions to be used
from library at ROM. It can also include
other list files.
Change-Id: I721c35d7dad3dcadbb3a7f3277bfd5d3e1f6e00a
Signed-off-by: Sathees Balya <sathees.balya@arm.com>
This patch adds support to build a combined BL1
and ROMLIB binary file with the right page
alignment in Juno. When USE_ROMLIB=1 is set for
Juno, it generates the combined file
bl1_romlib.bin which needs to be used instead of
bl1.bin
Change-Id: I407efbe48d3e522fa6ef855538a9587193cb1919
Signed-off-by: Sathees Balya <sathees.balya@arm.com>
Register functions have to be added to the
jump table to allow patching in the
future
Change-Id: I57a885f7fc6290ea74a6096aea5b1867b2098eb7
Signed-off-by: Sathees Balya <sathees.balya@arm.com>
This change allows patching of functions in the
romlib. This can be done by adding "patch" at the
end of the jump table entry for the function that
needs to be patched in the file jmptbl.i.
Functions patched in the jump table list will be
built as part of the BL image and the romlib
version will not be used
Change-Id: Iefb200cb86e2a4b61ad3ee6180d3ecc39bad537f
Signed-off-by: Sathees Balya <sathees.balya@arm.com>
This patch fixes up the AArch64 assembly code to use
adrp/adr instructions instead of ldr instruction for
reference to symbols. This allows these assembly
sequences to be Position Independant. Note that the
the reference to sizes have been replaced with
calculation of size at runtime. This is because size
is a constant value and does not depend on execution
address and using PC relative instructions for loading
them makes them relative to execution address. Also
we cannot use `ldr` instruction to load size as it
generates a dynamic relocation entry which must *not*
be fixed up and it is difficult for a dynamic loader
to differentiate which entries need to be skipped.
Change-Id: I8bf4ed5c58a9703629e5498a27624500ef40a836
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
Romlib is a new image that is stored in ROM and contains the code of
several libraries that can be shared between different images. All
the functions within in the library are accessed using a jump table
which allows to update the romlib image whithout changing the binary
compatibility. This jump table can be also stored in RAM and it can
allow to patch a romlib with potential bugs fixes..
Change-Id: If980ccdaca24b7aaca900e32acc68baf6f94ab35
Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
