|
|
|
|
#
|
|
|
|
|
# Copyright (c) 2024, Arm Limited. All rights reserved.
|
|
|
|
|
# Copyright (c) 2019-2022, Linaro Limited. All rights reserved.
|
|
|
|
|
#
|
|
|
|
|
# SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
BUILD_INFO ?= 1
|
|
|
|
|
DEBUG := 0
|
|
|
|
|
ENCTOOL ?= encrypt_fw${BIN_EXT}
|
|
|
|
|
BINARY := $(notdir ${ENCTOOL})
|
|
|
|
|
OPENSSL_DIR := /usr
|
|
|
|
|
|
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>
1 year ago
|
|
|
toolchains := host
|
|
|
|
|
|
|
|
|
|
MAKE_HELPERS_DIRECTORY := ../../make_helpers/
|
|
|
|
|
include ${MAKE_HELPERS_DIRECTORY}build_macros.mk
|
|
|
|
|
include ${MAKE_HELPERS_DIRECTORY}build_env.mk
|
build: unify verbosity handling
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>
6 months ago
|
|
|
include ${MAKE_HELPERS_DIRECTORY}common.mk
|
|
|
|
|
include ${MAKE_HELPERS_DIRECTORY}defaults.mk
|
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>
1 year ago
|
|
|
include ${MAKE_HELPERS_DIRECTORY}toolchain.mk
|
|
|
|
|
|
|
|
|
|
OBJECTS := src/encrypt.o \
|
|
|
|
|
src/cmd_opt.o \
|
|
|
|
|
src/main.o
|
|
|
|
|
|
|
|
|
|
HOSTCCFLAGS := -Wall -std=c99
|
|
|
|
|
|
|
|
|
|
# Select OpenSSL version flag according to the OpenSSL build selected
|
|
|
|
|
# from setting the OPENSSL_DIR path.
|
|
|
|
|
$(eval $(call SELECT_OPENSSL_API_VERSION))
|
|
|
|
|
|
|
|
|
|
ifeq (${DEBUG},1)
|
|
|
|
|
HOSTCCFLAGS += -g -O0 -DDEBUG -DLOG_LEVEL=40
|
|
|
|
|
else
|
|
|
|
|
ifeq (${BUILD_INFO},1)
|
|
|
|
|
HOSTCCFLAGS += -O2 -DLOG_LEVEL=20
|
|
|
|
|
else
|
|
|
|
|
HOSTCCFLAGS += -O2 -DLOG_LEVEL=10
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
HOSTCCFLAGS += ${DEFINES}
|
|
|
|
|
# USING_OPENSSL3 flag will be added to the HOSTCCFLAGS variable with the proper
|
|
|
|
|
# computed value.
|
|
|
|
|
HOSTCCFLAGS += -DUSING_OPENSSL3=$(USING_OPENSSL3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Make soft links and include from local directory otherwise wrong headers
|
|
|
|
|
# could get pulled in from firmware tree.
|
|
|
|
|
INC_DIR := -I ./include -I ../../include/tools_share -I ${OPENSSL_DIR}/include
|
|
|
|
|
|
|
|
|
|
# Include library directories where OpenSSL library files are located.
|
|
|
|
|
# For a normal installation (i.e.: when ${OPENSSL_DIR} = /usr or
|
|
|
|
|
# /usr/local), binaries are located under the ${OPENSSL_DIR}/lib/
|
|
|
|
|
# directory. However, for a local build of OpenSSL, the built binaries are
|
|
|
|
|
# located under the main project directory (i.e.: ${OPENSSL_DIR}, not
|
|
|
|
|
# ${OPENSSL_DIR}/lib/).
|
|
|
|
|
LIB_DIR := -L ${OPENSSL_DIR}/lib -L ${OPENSSL_DIR}
|
|
|
|
|
LIB := -lssl -lcrypto
|
|
|
|
|
|
|
|
|
|
.PHONY: all clean realclean --openssl
|
|
|
|
|
|
|
|
|
|
all: --openssl ${BINARY}
|
|
|
|
|
|
|
|
|
|
${BINARY}: ${OBJECTS} Makefile
|
build: unify verbosity handling
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>
6 months ago
|
|
|
$(s)echo " HOSTLD $@"
|
|
|
|
|
$(q)$(host-cc) ${OBJECTS} ${LIB_DIR} ${LIB} -o $@
|
|
|
|
|
|
|
|
|
|
%.o: %.c
|
build: unify verbosity handling
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>
6 months ago
|
|
|
$(s)echo " HOSTCC $<"
|
|
|
|
|
$(q)$(host-cc) -c ${HOSTCCFLAGS} ${INC_DIR} $< -o $@
|
|
|
|
|
|
|
|
|
|
--openssl:
|
|
|
|
|
ifeq ($(DEBUG),1)
|
build: unify verbosity handling
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>
6 months ago
|
|
|
$(s)echo "Selected OpenSSL version: ${OPENSSL_CURRENT_VER}"
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
clean:
|
|
|
|
|
$(call SHELL_DELETE_ALL,${OBJECTS})
|
|
|
|
|
|
|
|
|
|
realclean: clean
|
|
|
|
|
$(call SHELL_DELETE,${BINARY})
|
