| 73f7b7dd | 15-Aug-2024 |
Chris Kay <chris.kay@arm.com> |
fix(cot-dt2c): fix various breakages
This change fixes several breakages that were introduced in some build
configurations by the introduction of the cot-dt2c tool.
Some Python environments cannot
fix(cot-dt2c): fix various breakages
This change fixes several breakages that were introduced in some build
configurations by the introduction of the cot-dt2c tool.
Some Python environments cannot be managed directly via `pip`, and
invocations of `make`, including `make distclean`, would cause errors
along the lines of:
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
This change has been resolved by ensuring that calls to the cot-dt2c
tool from the build system happen exclusively through Poetry, which
automatically sets up a virtual environment that *can* be modified.
Some environments saw the following error when building platforms where
the cot-dt2c tool was used:
make: *** No rule to make target '<..>/debug/bl2_cot.c', needed
by '<..>/debug/bl2/bl2_cot.o'. Stop.
Additionally, environments with a more recent version of Python saw the
following error:
File "<...>/lib/python3.12/site-packages/cot_dt2c/cot_parser.py",
line 637, in img_to_c
if ifdef:
^^^^^
NameError: name 'ifdef' is not defined
Both of these errors have now been resolved by modifications to the
build system and the cot-dt2c tool to enable preprocessing of the device
tree source file before it is processed by the tool.
As a consequence of this change, the `pydevicetree` library is no longer
vendored into the repository tree, and we instead pull it in via a
dependency in Poetry.
This change also resolves several MyPy warnings and errors related to
missing type hints.
Change-Id: I72b2d01caca3fcb789d3fe2549f318a9c92d77d1
Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| 31120993 | 17-Jun-2024 |
Charlie Bareham <charlie.bareham@arm.com> |
feat: add creating transfer lists from yaml files
This commit adds a command create-from-yaml to tlc, which
creates a transfer list from a yaml file. It also changes
the files structure of the fixtu
feat: add creating transfer lists from yaml files
This commit adds a command create-from-yaml to tlc, which
creates a transfer list from a yaml file. It also changes
the files structure of the fixtures in the unit tests so
they are in a directory called trusted-firmware-a. This
is necessary because blob file paths in the yaml file are
relative to the root of TF-A.
The blob files are not verified by TLC, so it can be used
to load arbitrary binary information into the transfer
list. The authenticity of the transfer list must be
ensured by the loader.
Change-Id: Idf704ce5d9b7e28b31f471ac337e4aef33d0ad8a
Signed-off-by: Charlie Bareham <charlie.bareham@arm.com>
show more ...
|
| e182f438 | 17-Jun-2024 |
Charlie Bareham <charlie.bareham@arm.com> |
build: make poetry use existing lock file
This makes the build reproducible.
When `make dev-install` was run, it would ignore the existing
poetry lock file, install different versions of all the
li
build: make poetry use existing lock file
This makes the build reproducible.
When `make dev-install` was run, it would ignore the existing
poetry lock file, install different versions of all the
libraries, then overwrite the lock file. Once `--no-update`
is added, it stops doing that, and installs exactly what is
in the poetry lock file.
Change-Id: If62637a40504d23deb47a05347a272e1c13bf41e
Signed-off-by: Charlie Bareham <charlie.bareham@arm.com>
show more ...
|
| 3ed72444 | 04-Jun-2024 |
Chris Kay <chris.kay@arm.com> |
build(rzg-layout): split combined targets
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 curren
build(rzg-layout): split combined targets
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>
show more ...
|
| 415049a2 | 14-Jun-2024 |
Chris Kay <chris.kay@arm.com> |
build(encrypt-fw): don't generate `build_msg.c`
This change avoids generating a build message source file on the shell,
instead using the `__DATE__` and `__TIME__` macros directly.
Change-Id: Ida53
build(encrypt-fw): don't generate `build_msg.c`
This change avoids generating a build message source file on the shell,
instead using the `__DATE__` and `__TIME__` macros directly.
Change-Id: Ida537d4c3e550f2fbbd977472ed6573491d17c23
Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| e639ad23 | 08-Apr-2024 |
Donald Chan <donachan@tesla.com> |
fix(cert-create): use a salt length equal to digest length for RSA-PSS
Currently when RSA-PSS signing is invoked, a salt length of 32 bytes
is assumed. This works well when SHA-256 is the digest alg
fix(cert-create): use a salt length equal to digest length for RSA-PSS
Currently when RSA-PSS signing is invoked, a salt length of 32 bytes
is assumed. This works well when SHA-256 is the digest algorithm, but
the standard industry practice is that the salt length should follow
the digest length (e.g. 48/64 bytes for SHA-384/SHA-512).
Various cloud services' key management services (KMS) offering have
such restrictions in place, so if someone wants to integrate cert_create
against these services for signing key/content certs, they will have
problem with integration.
Furthermore, JWS (RFC7518) defined these specific combinations as valid
specs and other combinations are not supported:
- PS256: RSASSA-PSS using SHA-256 and MGF1 with SHA-256
- PS384: RSASSA-PSS using SHA-384 and MGF1 with SHA-384
- PS512: RSASSA-PSS using SHA-512 and MGF1 with SHA-512
Change-Id: Iafc7c60ccb36f4681053dbeb4147bac01b9d724d
Signed-off-by: Donald Chan <donachan@tesla.com>
show more ...
|
| cc277de8 | 20-Oct-2023 |
Chris Kay <chris.kay@arm.com> |
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 ...
|