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>
J-Alves
Imre Kis
Anders Dellien
Olivier Deprez
Manish V Badarkhe
Ruari Phipps
Grant Likely
Manish Pandey
Antonio Nino Diaz