- 03 Aug, 2018 1 commit
-
-
Roberto Vargas authored
This patch adds all the make macros needed to create a library archive and to use it in the link stage. Change-Id: I26597bfd6543649d0b68a9b1e06aec1ba353e6de Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 18 Jul, 2018 1 commit
-
-
Konstantin Porotchkin authored
Add support for BLx stages to use libraries in MAKE_BL macro. This change does not affect BL stages that do not have BL_LIBS variable defined in their makefiles. However in case that BL wants to use external library (for instance vendor-specific DDR initialization code supplied as a library), this patch will allow to build BL image linked with such library. Change-Id: Ife29069a72dc4aff833db6ef8b828736d6689b78 Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
-
- 18 Jun, 2018 1 commit
-
-
Yann Gautier authored
This is an add-on feature that allows processing device tree with external includes. "-Iinclude" is also added to INCLUDES. It allows inclusion of dt-bindings files either in dts files or drivers, as those files will be in include/dt-bindings/. "-i fdts" is added to the DTC command line. As the pre-processed files are in build directory, the DT source directory has to be explicitely included, to manages /include/ directives. fixes arm-software/tf-issues#595 Signed-off-by: Lionel Debieve <lionel.debieve@st.com> Signed-off-by: Yann Gautier <yann.gautier@st.com>
-
- 18 May, 2018 1 commit
-
-
Soby Mathew authored
This patch allows platforms to dynamically disable authentication of images during cold boot. This capability is controlled via the DYN_DISABLE_AUTH build flag and is only meant for development purposes. Change-Id: Ia3df8f898824319bb76d5cc855b5ad6c3d227260 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 04 May, 2018 3 commits
-
-
Jeenu Viswambharan authored
The ARMv8.4 RAS extensions introduce architectural support for software to inject faults into the system in order to test fault-handling software. This patch introduces the build option FAULT_HANDLING_SUPPORT to allow for lower ELs to use registers in the Standard Error Record to inject fault. The build option RAS_EXTENSIONS must also be enabled along with fault injection. This feature is intended for testing purposes only, and is advisable to keep disabled for production images. Change-Id: I6f7a4454b15aec098f9505a10eb188c2f928f7ea Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional extensions to base ARMv8.0 architecture. This patch adds build system support to enable RAS features in ARM Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for this. With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is inserted at all EL3 vector entry and exit. ESBs will synchronize pending external aborts before entering EL3, and therefore will contain and attribute errors to lower EL execution. Any errors thus synchronized are detected via. DISR_EL1 register. When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1. Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
At present, any External Abort routed to EL3 is reported as an unhandled exception and cause a panic. This patch enables ARM Trusted Firmware to handle External Aborts routed to EL3. With this patch, when an External Abort is received at EL3, its handling is delegated to plat_ea_handler() function. Platforms can provide their own implementation of this function. This patch adds a weak definition of the said function that prints out a message and just panics. In order to support handling External Aborts at EL3, the build option HANDLE_EA_EL3_FIRST must be set to 1. Before this patch, HANDLE_EA_EL3_FIRST wasn't passed down to compilation; this patch fixes that too. Change-Id: I4d07b7e65eb191ff72d63b909ae9512478cd01a1 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 23 Apr, 2018 1 commit
-
-
Antonio Nino Diaz authored
Due to differences in the bitfields of the SMC IDs, it is not possible to support SMCCC 1.X and 2.0 at the same time. The behaviour of `SMCCC_MAJOR_VERSION` has changed. Now, it is a build option that specifies the major version of the SMCCC that the Trusted Firmware supports. The only two allowed values are 1 and 2, and it defaults to 1. The value of `SMCCC_MINOR_VERSION` is derived from it. Note: Support for SMCCC v2.0 is an experimental feature to enable prototyping of secure partition specifications. Support for this convention is disabled by default and could be removed without notice. Change-Id: I88abf9ccf08e9c66a13ce55c890edea54d9f16a7 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 07 Apr, 2018 1 commit
-
-
Jiafei Pan authored
In some use-cases BL2 will be stored in eXecute In Place (XIP) memory, like BL1. In these use-cases, it is necessary to initialize the RW sections in RAM, while leaving the RO sections in place. This patch enable this use-case with a new build option, BL2_IN_XIP_MEM. For now, this option is only supported when BL2_AT_EL3 is 1. Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
-
- 05 Mar, 2018 1 commit
-
-
Heyi Guo authored
Since we use "?=" to set PLATFORM_ROOT, it is better to change the name to be more special, or else it may be overridden by some environment variables, such as in some CI build environments. Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
-
- 01 Mar, 2018 2 commits
-
-
Stephen Warren authored
This makes incremental builds work when the only change is to a definition in a makefile. This version of the patch has been fixed to avoid depending on the dependency makefiles that are generated at build time. Fixes arm-software/tf-issues#551 Signed-off-by: Stephen Warren <swarren@nvidia.com>
-
Dan Handley authored
For platforms that have not migrated to MULTI_CONSOLE_API == 1, there are a lot of confusing deprecated declaration warnings relating to use of console_init() and console_uninit(). Some of these relate to use by the generic code, not the platform code. These functions are not really deprecated but *removed* when MULTI_CONSOLE_API == 1. This patch consolidates these warnings into a single preprocessor warning. The __deprecated attribute is removed from the console_init() and console_uninit() declarations. For preprocessor warnings like this to not cause fatal build errors, this patch adds -Wno-error=cpp to the build flags when ERROR_DEPRECATED == 0. This option (and -Wno-error=deprecated-declarations) is now added to CPPFLAGS instead of TF_CFLAGS to ensure the build flags are used in the assembler as well as the compiler. This patch also disentangles the MULTI_CONSOLE_API and ERROR_DEPRECATED build flags by defaulting MULTI_CONSOLE_API to 0 instead of ERROR_DEPRECATED. This allows platforms that have not migrated to MULTI_CONSOLE_API to use ERROR_DEPRECATED == 1 to emit a more meaningful build error. Finally, this patch bans use of MULTI_CONSOLE_API == 1 and AARCH32, since the AArch32 console implementation does not support MULTI_CONSOLE_API == 1. Change-Id: If762165ddcb90c28aa7a4951aba70cb15c2b709c Signed-off-by: Dan Handley <dan.handley@arm.com>
-
- 28 Feb, 2018 1 commit
-
-
Dimitris Papastamos authored
Seems to have unintended side-effects on the build system such as rebuilding certain parts of TF even though nothing has changed. This reverts commit c6f651f9 . Change-Id: I1472e6c630cb6371ec629b7d97a5748d9a6fd096 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 26 Feb, 2018 1 commit
-
-
Soby Mathew authored
This patch makes some minor changes to `MAKE_DTBS` make macro and adds `dtbs` target to the `all` make target. Change-Id: I1c5b4a603ada31d2dac2ed73da9ff707b410dd11 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
- 22 Feb, 2018 1 commit
-
-
Stephen Warren authored
This makes incremental builds work when the only change is to a definition in a makefile. Fixes arm-software/tf-issues#551 Signed-off-by: Stephen Warren <swarren@nvidia.com>
-
- 01 Feb, 2018 12 commits
-
-
Masahiro Yamada authored
One typical usage of the pre-tool image filter is data compression, and GZIP is one of the most commonly used compression methods. I guess this is generic enough to be put in the common script instead of platform.mk. If you want to use this, you can add something like follows to your platform.mk: BL32_PRE_TOOL_FILTER := GZIP BL33_PRE_TOOL_FILTER := GZIP Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
There are cases where we want to process images before they are passed to cert_create / fiptool. My main motivation is data compression. By compressing images, we can save data storage, and possibly speed up loading images. The image verification will also get faster because certificates are generated based on compressed images. Other image transformation filters (for ex. encryption), and their combinations would be possible. So, our build system should support transformation filters in a generic manner. The choice of applied filters is up to platforms (so specified in platform.mk) To define a new filter, <FILTER_NAME>_RULE and <FILTER_NAME>_SUFFIX are needed. For example, the GZIP compression filter can be implemented as follows: ------------------------>8------------------------ define GZIP_RULE $(1): $(2) @echo " GZIP $$@" $(Q)gzip -n -f -9 $$< --stdout > $$@ endef GZIP_SUFFIX := .gz ------------------------>8------------------------ The _RULE defines how to create the target $(1) from the source $(2). The _SUFFIX defines the extension appended to the processed image path. The suffix is not so important because the file name information is not propagated to FIP, but adding a sensible suffix will be good to classify the data file. Platforms can specify which filter is applied to which BL image, like this: ------------------------>8------------------------ BL32_PRE_TOOL_FILTER := GZIP BL33_PRE_TOOL_FILTER := GZIP ------------------------>8------------------------ <IMAGE_NAME>_PRE_TOOL_FILTER specifies per-image filter. With this, different images can be transformed differently. For the case above, only BL32 and BL33 are GZIP-compressed. Nothing is done for other images. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
In the next commit, I need the image name in lowercase because output files are generally named in lowercase. Unfortunately, TOOL_ADD_IMG takes the first argument in uppercase since we generally use uppercase Make variables. make_helpers/build_macros.mk provides 'uppercase' macro to convert a string into uppercase, but 'lowercase' does not exist. We can implement it if we like, but it would be more straightforward to change the argument of TOOL_ADD_IMG. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The PHONY target "bl*" generate $(BIN) and $(DUMP), but host tools (fiptool, cert_create) only need $(BIN). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The third argument was given "true" by images, but it was moved to TOOL_ADD_PAYLOAD. No more caller of CERT_ADD_CMD_OPT uses this. So, the third argument is always empty. Remove it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Now FIP_ADD_IMG takes care of both fiptool and cert_create symmetrically. Rename it so that it matches the behavior. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Now FIP_ADD_PAYLOAD takes care of both fiptool and cert_create symmetrically. Rename it so that it matches the behavior. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The fiptool and cert_create use the same command options for images. It is pretty easy to handle both in the same, symmetrical way. Move CRT_ARGS and CRT_DEPS to FIP_ADD_PAYLOAD. This refactoring makes sense because FIP_ADD_PAYLOAD is called from MAKE_BL (when building images from source), and from FIP_ADD_IMG (when including external images). (FIP_ADD_PAYLOAD will be renamed later on since it now caters to both fiptool and cert_create). We can delete CERT_ADD_CMD_OPT for images in tbbr.mk. It still needs to call CERT_ADD_CMD_OPT directly for certificates. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The callers of these macros are supposed to use $(eval $(call, ...)). The $(eval ...) on the callee side is unneeded. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
The build system supports generating two FIP images, fip and fwu_fip. Accordingly, we have similar build macros. FIP_ADD_PAYLOAD <--> FWU_FIP_ADD_PAYLOAD CERT_ADD_CMD_OPT <--> FWU_CERT_ADD_CMD_OPT FIP_ADD_IMG <--> FWU_FIP_ADD_IMG The duplicated code increases the maintenance burden. Also, the build rule of BL2U looks clumsy - we want to call MAKE_BL to compile it from source files, but we want to put it in fwu_fip. We can not do it in a single macro call since the current MAKE_BL does not support fwu_fip. To refactor those in a clean way is to support one more argument to specify the FIP prefix. If it is empty, the images are targeted to fip, whereas if the argument is "FWU_", targeted to fwu_fip. The build macros prefixed with FWU_ go away. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Now, MAKE_TOOL_ARGS is only called from MAKE_BL. Squash it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
check_* targets check if the required option are given, but do not check the validity of the argument. If the specified file does not exist, let the build fail immediately instead of passing the invalid file path to tools. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 19 Jan, 2018 1 commit
-
-
Julius Werner authored
This patch adds the foundation for a platform-independent coreboot support library that can be shared by all platforms that boot BL31 from coreboot (acting as BL2). It adds code to parse the "coreboot table", a data structure that coreboot uses to communicate different kinds of information to later-stage firmware and certain OS drivers. As a first small use case for this information, allow platforms to access the serial console configuration used by coreboot, removing the need to hardcode base address and divisors and allowing Trusted Firmware to benefit from coreboot's user configuration (e.g. which UART to pick and which baud rate to use). Change-Id: I2bfb39cd2609ce6640b844ab68df6c9ae3f28e9e Signed-off-by: Julius Werner <jwerner@chromium.org>
-
- 18 Jan, 2018 2 commits
-
-
Roberto Vargas authored
It is better to not include BL2 in FIP when using `BL2 at EL3` as platforms using this config would not have the capability to parse the FIP format in Boot ROM and BL2 needs to be loaded independently. This patch does the required changes for the same. Change-Id: Iad285c247b3440e2d827fef97c3dd81f5c09cabc Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
Roberto Vargas authored
This patch enables BL2 to execute at the highest exception level without any dependancy on TF BL1. This enables platforms which already have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL stages without need for BL1. This is not currently possible because BL2 executes at S-EL1 and cannot jump straight to EL3. Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 24 Dec, 2017 1 commit
-
-
Masahiro Yamada authored
check_* targets just check necessary command line argument, not build any images. They should be specified as .PHONY. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 23 Dec, 2017 1 commit
-
-
Masahiro Yamada authored
Commit 8f0617ef ("Apply TBBR naming convention to the fip_create options") changed fiptool command options. We often forget to update documentation. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 12 Dec, 2017 1 commit
-
-
Julius Werner authored
This patch overhauls the console API to allow for multiple console instances of different drivers that are active at the same time. Instead of binding to well-known function names (like console_core_init), consoles now provide a register function (e.g. console_16550_register()) that will hook them into the list of active consoles. All console operations will be dispatched to all consoles currently in the list. The new API will be selected by the build-time option MULTI_CONSOLE_API, which defaults to ${ERROR_DEPRECATED} for now. The old console API code will be retained to stay backwards-compatible to older platforms, but should no longer be used for any newly added platforms and can hopefully be removed at some point in the future. The new console API is intended to be used for both normal (bootup) and crash use cases, freeing platforms of the need to set up the crash console separately. Consoles can be individually configured to be active active at boot (until first handoff to EL2), at runtime (after first handoff to EL2), and/or after a crash. Console drivers should set a sane default upon registration that can be overridden with the console_set_scope() call. Code to hook up the crash reporting mechanism to this framework will be added with a later patch. This patch only affects AArch64, but the new API could easily be ported to AArch32 as well if desired. Change-Id: I35c5aa2cb3f719cfddd15565eb13c7cde4162549 Signed-off-by: Julius Werner <jwerner@chromium.org>
-
- 30 Nov, 2017 1 commit
-
-
David Cunado authored
This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set to one EL3 will check to see if the Scalable Vector Extension (SVE) is implemented when entering and exiting the Non-secure world. If SVE is implemented, EL3 will do the following: - Entry to Non-secure world: SIMD, FP and SVE functionality is enabled. - Exit from Non-secure world: SIMD, FP and SVE functionality is disabled. As SIMD and FP registers are part of the SVE Z-registers then any use of SIMD / FP functionality would corrupt the SVE registers. The build option default is 1. The SVE functionality is only supported on AArch64 and so the build option is set to zero when the target archiecture is AArch32. This build option is not compatible with the CTX_INCLUDE_FPREGS - an assert will be raised on platforms where SVE is implemented and both ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1. Also note this change prevents secure world use of FP&SIMD registers on SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on such platforms unless ENABLE_SVE_FOR_NS is set to 0. Additionally, on the first entry into the Non-secure world the SVE functionality is enabled and the SVE Z-register length is set to the maximum size allowed by the architecture. This includes the use case where EL2 is implemented but not used. Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 29 Nov, 2017 2 commits
-
-
Soby Mathew authored
This patch fixes a couple of issues for AArch32 builds on ARM reference platforms : 1. The arm_def.h previously defined the same BL32_BASE value for AArch64 and AArch32 build. Since BL31 is not present in AArch32 mode, this meant that the BL31 memory is empty when built for AArch32. Hence this patch allocates BL32 to the memory region occupied by BL31 for AArch32 builds. As a side-effect of this change, the ARM_TSP_RAM_LOCATION macro cannot be used to control the load address of BL32 in AArch32 mode which was never the intention of the macro anyway. 2. A static assert is added to sp_min linker script to check that the progbits are within the bounds expected when overlaid with other images. 3. Fix specifying `SPD` when building Juno for AArch32 mode. Due to the quirks involved when building Juno for AArch32 mode, the build option SPD needed to specifed. This patch corrects this and also updates the documentation in the user-guide. 4. Exclude BL31 from the build and FIP when building Juno for AArch32 mode. As a result the previous assumption that BL31 must be always present is removed and the certificates for BL31 is only generated if `NEED_BL31` is defined. Change-Id: I1c39bbc0abd2be8fbe9f2dea2e9cb4e3e3e436a8 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
-
Dimitris Papastamos authored
The Cortex A75 has 5 AMU counters. The first three counters are fixed and the remaining two are programmable. A new build option is introduced, `ENABLE_AMU`. When set, the fixed counters will be enabled for use by lower ELs. The programmable counters are currently disabled. Change-Id: I4bd5208799bb9ed7d2596e8b0bfc87abbbe18740 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 23 Nov, 2017 1 commit
-
-
Matt Ma authored
This patch replaces the macro ASM_ASSERTION with the macro ENABLE_ASSERTIONS in ARM Cortex-A53/57/72 MPCore Processor related files. There is build error when ASM_ASSERTION is set to 1 and ENABLE_ASSERTIONS is set to 0 because function asm_assert in common/aarch32/debug.S is defined in the macro ENABLE_ASSERTIONS but is called with the macro ASM_ASSERTION. There is also the indication to use ENABLE_ASSERTIONS but not ASM_ASSERTION in the Makefile. Signed-off-by: Matt Ma <matt.ma@spreadtrum.com>
-
- 21 Nov, 2017 1 commit
-
-
Qixiang Xu authored
The flag support the following values: - sha256 (default) - sha384 - sha512 Change-Id: I7a49d858c361e993949cf6ada0a86575c3291066 Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
-
- 20 Nov, 2017 1 commit
-
-
Dimitris Papastamos authored
It is not possible to detect at compile-time whether support for an optional extension such as SPE should be enabled based on the ARM_ARCH_MINOR build option value. Therefore SPE is now enabled by default. Change-Id: I670db164366aa78a7095de70a0962f7c0328ab7c Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 13 Nov, 2017 1 commit
-
-
Jeenu Viswambharan authored
The implementation currently supports only interrupt-based SDEI events, and supports all interfaces as defined by SDEI specification version 1.0 [1]. Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in BL31. Update user guide and porting guide. SDEI documentation to follow. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf Change-Id: I758b733084e4ea3b27ac77d0259705565842241a Co-authored-by: Yousuf A <yousuf.sait@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-