StandaloneMM partition requires that the first memory region in its list
of reserved memory regions describe the full partition layout. Hafnium
SPMC checks that memory regions in FF-A manifest do not overlap.
Therefore, this region is added directly in HOB generation code rather
than as a memory region in the FF-A manifest for the StMM partition.
Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Change-Id: Ia22174d755a5776e20ecf9639584f3c08cf9e60e
Specify endianness encoding when packing HOB binary. Little-endian is
used as target platforms are expected to be little-endian.
Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Change-Id: I28d7b302f79482ed142c1964409c310f713a9b8c
If the "hob_path" has been introduced in the `args`
dictionary, use it when creating a Transfer List
type of package.
Create a HOB entry in the transfer list with the
respective transfer entry type.
Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: Ie5fefe90205cf89ee26c3683048bf42229cb4bee
Add an SP setup function that invokes the HOB creation
utilities.
It introduces an argument "hob_path" to the shared dictionary of args
with the location of the generated binary containing the HOB list.
Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I26a07027b6344c9d7ba732d022932736a62e2505
Add python library to build the Handoff Block list (HOB list) for an SP
at build time.
Signed-off-by: Kathleen Capella <kathleen.capella@arm.com>
Change-Id: I17d46f7ed21ce42a83f33dfdc4fad038653d1ec3
Generate the rules for calling 'tlc' tool, and generating
a partition package as a TL:
- The data is aligned to 4k.
- Using TE types 0x103 for FF-A manifest, and 0x106 for
FF-A SP binary.
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I1941e3e8f43d8dad33cdd0dea0571cf4a0d5e8f3
Calculate the secure partition number and saves it into the defined
macro NUM_SP.
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
Signed-off-by: Leo Yan <leo.yan@arm.com>
Change-Id: I4175a10d315482b65fd0f3eed4c6fd1e1e2b5e4d
For a couple of releases now we have officially withdrawn support for
building TF-A on Windows using the native environment, relying instead
on POSIX emulation layers like MSYS2, Mingw64, Cygwin or WSL.
This change removes the remainder of the OS compatibility layer
entirely, and migrates the build system over to explicitly relying on a
POSIX environment.
Change-Id: I8fb60d998162422e958009afd17eab826e3bc39b
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>
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>
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>
Silence warning from sp_mk_generator that 'is not' operator
is not meant for integers. This replaces the referred instance
with '!='.
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I0d31ad65466dbeafebbfc929e506c3e290913aca
The FF-A specification has made it such that SPs
may optionally specify their load address in the manifest.
This info was being retrieved to generate some information
for the SPMC manifest. However, it is not a mandatory utility.
This change relaxes the case in which the SP manifest doesn't
have a load address.
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: Ic4c1b1ec6666522900c113903be45ba0eb5d0bf6
TF-A makefile accepts a device-tree snippet to override hardcoded SP
nodes, via the `ARM_BL2_SP_LIST_DTS` variable. However the SPs declared
in `ARM_BL2_SP_LIST_DTS` must be in the same order as they are in the
FIP image, otherwise hash authentication will fail when loaded by BL2.
This patch generates the `ARM_BL2_SP_LIST_DTS` file from the
`sp_layout.json` file. The SPs in the FIP image are also generated from
`sp_layout.json`, so this ensures that there is only one source of truth
for the SP list, removing the possibility to have the lists disagree
with each other.
Signed-off-by: Karl Meakin <karl.meakin@arm.com>
Change-Id: I7d76715135c596605c6a02aad5196d967dfeb1ce
In the generated sp_gen.mk, add a dependency to the image described in
the sp_layout.json file to make sure that the pkg file is re-generated
if the SP image is updated.
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Change-Id: Id936f907d6baa6b0627c4bb9608323e5157c7a9b
Replace the "is/is not" operator by "==/!=" for literals, to fix the
syntax warnings below:
tools/sptool/sp_mk_generator.py:93: SyntaxWarning: "is not" with a literal. Did you mean "!="?
return len(sppkg_rule) is not 0
tools/sptool/sp_mk_generator.py:203: SyntaxWarning: "is" with a literal. Did you mean "=="?
assert(len(uuid_lines) is 1)
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I10800f6b607942542aa2cbaaecac86b854f6b56a
The script 'sp_mk_generator.py' was reworked in [1]. There was a
reference the variable 'data' left. This variable 'data' used to refer
to the json data of a the sp layout file.
This patch fixed the reference with the proper variable according to the
rework [1].
[1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=a96a07bfb66b7d38fe3da824e8ba183967659008
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I9ddbfa8d55a114bcef6997920522571e070fc7d2
Add dependency between rules to generate SP packages and their dtb files
to ensure the dtb files are built before the sptool attempts to generate
the SP package.
Change-Id: I071806f4aa09f39132e3e1990c91d71dc9acd728
Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
To cope with the changes/design decisions in the implementation of
boot protocol, from FF-A v1.1 specification in the S-EL2 SPM, we have
changed the format of the sp pkg header.
These changes need to be reflected in the sptool, used for packaging
the SP binary, and the SP's FF-A manifest. Now the SP pkg can
contain the boot information blob as defined by the FF-A specification.
To cater for these changes, bring to the TF-A project an equivalent to
the tool used in the Hafnium project.
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I046f5d6e3c2ef0ba6c87f65302e127dedef34c28
The "sp_mk_generator.py" is responsible for processing the SP layout
file, which contains information about the SPs to be deployed on top of
the SPM, to generate the "sp_gen.mk" file which appends information
specific to each SP that shall help with packing all SPs into a fip
binary.
Before this patch the "sp_mk_generator.py" was a monolithic script,
which has now been broken down into functions for each identified
configuration action.
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I8ee7487f2e07d53e508d17d0fe4510e22957f5ca
Developed python framework to help with SPs configuration. The framework
allows for functions (dubbed "actions" in the framework) to be defined
that should process the "sp_layout.json" file.
Signed-off-by: J-Alves <joao.alves@arm.com>
Change-Id: I278cd5a7aa0574168473e28f3b0fe231d7b548ee
Extract the UUID from the SP layout JSON file if the optional 'uuid'
field exists otherwise fall back to the current method for extracting
the SP UUID from the partition manifest file.
This change gives a way to decouple TF-A's dependency on the SP
manifest file's format which is tied to the SPMC.
Signed-off-by: Imre Kis <imre.kis@arm.com>
Change-Id: I13af066c1de58bfb9c3fd470ee137ea0275cd98c
The UUID conversion drops leading zeroes, so make sure that
all hex strings always are 8 digits long
Signed-off-by: Anders Dellien <anders.dellien@arm.com>
Change-Id: I5d7e3cf3b53403a02bf551f35f17dbdb96dec8ae
The UUID field in SP manifest DTS is represented as an array of four
integers that the SPMC consumes using the little endian representation.
The reason is that those values are directly mapped to the SMCCC section
5.3 recommendation and the way they are exposed to the
FFA_PARTITION_INFO_GET interface.
Per [1] TF-A build flow expects a big endian representation of the UUID
so the sp_mk_generator script is updated to accommodate this conversion.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9563
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I7c7b295225e23ea64f49170e27d97442b289703b
This patch: fafd3ec9c assumes that tools must build from
the main makefile folder.
This assumption leads to the error when somebody wants to
build a tool from the tool's folder.
Hence changes are done to provide the default binary name
in the tool's makefile.
Change-Id: Iae570a7f8d322151376b6feb19e739300eecc3fc
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Currently, the tool's makefile override the tool's binary name
which is already been defined in the main makefile.
Hence fix is provided so that the tool's makefile get the tool's
binary name from the main makefile instead of overriding it.
Change-Id: I8af2bd391a96bba2dbcddef711338a94ebf5f038
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
With recently introduced dualroot CoT for SPs where they are owned
either by SiP or by Platform. SiP owned SPs index starts at SP_PKG1_ID
while Plat owned SPs index starts at SP_PKG5_ID.
This patch modifies SP makefile generator script to take CoT as an
argument and if it is "dualroot" then generates SP_PKG in order
mentioned above, otherwise generates it sequentially.
Signed-off-by: Ruari Phipps <ruari.phipps@arm.com>
Change-Id: Iffad1131787be650a9462f6f8cc09b603cddb3b8
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
To support secure boot of SP's update cert tool arguments while
generating sp_gen.mk which in turn is consumed by build system.
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: I2293cee9b7c684c27d387aba18e0294c701fb1cc
Till now TF-A allows limited number of external images to be made part
of FIP. With SPM coming along, there may exist multiple SP packages
which need to be inserted into FIP. To achieve this we need a more
scalable approach to feed SP packages to FIP.
This patch introduces changes in build system to generate and add SP
packages into FIP based on information provided by platform.
Platform provides information in form of JSON which contains layout
description of available Secure Partitions.
JSON parser script is invoked by build system early on and generates
a makefile which updates FIP, SPTOOL and FDT arguments which will be
used by build system later on for final packaging.
"SP_LAYOUT_FILE" passed as a build argument and can be outside of TF-A
tree. This option will be used only when SPD=spmd.
For each SP, generated makefile will have following entries
- FDT_SOURCES += sp1.dts
- SPTOOL_ARGS += -i sp1.img:sp1.dtb -o sp1.pkg
- FIP_ARGS += --blob uuid=XXXX-XXX...,file=SP1.pkg
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ib6a9c064400caa3cd825d9886008a3af67741af7
Currently sptool generates a single blob containing all the Secure
Partitions, with latest SPM implementation, it is desirable to have
individual blobs for each Secure Partition. It allows to leverage
packaging and parsing of SP on existing FIP framework. It also allows
SP packages coming from different sources.
This patch modifies sptool so that it takes number of SP payload pairs
as input and generates number of SP blobs instead of a single blob.
Each SP blob can optionally have its own header containing offsets and
sizes of different payloads along with a SP magic number and version.
It is also associated in FIP with a UUID, provided by SP owner.
Usage example:
sptool -i sp1.bin:sp1.dtb -o sp1.pkg -i sp2.bin:sp2.dtb -o sp2.pkg ...
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Change-Id: Ie2db8e601fa1d4182d0a1d22e78e9533dce231bc
This tool packages Secure Partitions and Resource Descriptor blobs into
a simple file that can be loaded by SPM.
Change-Id: If3800064f30bdc3d7fc6a15ffbb3007ef632bcaa
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
