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>
mbedtls/version.h needs to be included before the use of any
mbedtls config variables.
Fixes a build failure regression from commit a8eadc51a.
Change-Id: Idd955d7955b0a55ffd127f31053335542cb15e22
Signed-off-by: Henrik Nordstrom <henrik.nordstrom@addiva.se>
Currently we include MBEDTLS_CONFIG_FILE directly and if a custom
config file is used it will included.
However from mbedtls-3.x onwards it discourages usage of
MBEDTLS_CONFIG_FILE include directly, so to resolve this and keep 2.28
compatibility include version.h which would include the custom config
file if present and also would expose us with mbedtls-major-version
number which could be used for selecting features and functions for
mbedtls 2.28 or 3.3
Change-Id: I029992311be2a38b588ebbb350875b03ea29acdb
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Change the binary image alignment from 4 to 16.
The PKCS signature verification fails for unaligned images.
Change-Id: Ieb08dc3ea128790f542ad93e3c948117567a65af
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Replace deprecated mbedtls_sha256 with mbedtls_sha256_ret
The mbedtls_pk_parse_key does not work correctly anymore
with the DER buffer embedded in the secure image extentson
using the buffer size as the the key length.
Move to mbedtls_pk_parse_subpubkey API that handles such
case correctly.
The DER format already contains the key length, so there
is no particular reason to supply it to the key parser.
Update the doimage version to 3.3
Change-Id: I0ec5ee84b7d1505b43138e0b7a6bdba44a6702b6
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Move doimage utility from toos/doimage to tools/marvell/doimage.
This is done for supporting mode Marvell tools in the future.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
