Because of command differences in some build environments the "inline"
method of generating the build directory structure is not portable.
(e.g. in DOS environments the mkdir shell command fails if a directory
already exists, whereas in UNIX environments it succeeds.)
To improve portability we generate the directories needed using make,
but use the "order-only prerequisites" feature of make to prevent writes
of files into the directories generating re-builds, as suggested in the
GNU make Manual (Version 4.1 September 2014).
Change-Id: Ic9af475831063c7fe6f8bccffef184d79e799419
In some build environments executable programs have a specific file
extension. The value of BIN_EXT is appended to the relevant tool file
names to allow for this.
The value of BIN_EXT is set, where appropriate, by the build environment
specific make helper (to .exe for Windows build environments).
.gitignore is updated to hide the new (.exe) files.
Change-Id: Icc32f64b750e425265075ad4e0dea18129640b86
Replace some "recursively expanded" make variables with "simply
expanded" variables (i.e. replace = with :=). This has no functional
impact but is more consistent and theoretically more efficient.
Change-Id: Iaf33d7c8ad48464ae0d39923515d1e7f230c95c1
Some build environments do not support symbolic links. This patch
removes the symlinks previously used to build fip_create and instead
copies the relevant header files.
The original motivation for using symlinks was to avoid Trusted Firmware
library headers conflicting with headers in the compiler standard
include path. Copying the header files instead has the same effect.
Like other build artefacts, the copied files are listed in .gitignore.
The distclean targets have also been updated to remove the copies.
Change-Id: Ie8b67bcb133f7f1d660ae93b857950aa15e42b1e
Add make helper files to select the appropriate settings for the build
environment. Selection is made in make_helpers/build_env.mk, which
selects other files to include using generic build environment settings.
The Trusted Firmware Makefile and supporting tool Makefiles are updated
to include build_env.mk instead of unix.mk.
NOTE: This change does not fully enable builds in other build
environments. It facilitates this without compromising the
existing build environments.
Change-Id: Ic4064ffe6ce158bbd16d7cc9f27dd4655a3580f6
To help diagnose make problems, we report an error if the make
program used does not provide the $(eval ) make functionality.
This will detect early versions of GNU make and other make programs.
Change-Id: I0ebb0f63694cf0b04eaeb7ea1e9e172fb9770ce0
Macros are inserted to replace direct invocations of commands that are
problematic on some build environments. (e.g. Some environments expect
\ in paths instead of /.)
The changes take into account mismatched command mappings across
environments.
The new helper file unix.mk retains existing makefile behaviour on unix
like build environments by providing the following macro definitions:
SHELL_COPY cp -f
SHELL_COPY_TREE cp -rf
SHELL_DELETE rm -f
SHELL_DELETE_ALL rm -rf
MAKE_PREREQ_DIR mkdir -p (As make target)
SHELL_REMOVE_DIR rm -rf
Change-Id: I1b5ca5e1208e78230b15284c4af00c1c006cffcb
As an initial stage of making Trusted Firmware build environment more
portable, we remove most uses of the $(shell ) function and replace them
with more portable make function based solutions.
Note that the setting of BUILD_STRING still uses $(shell ) since it's
not possible to reimplement this as a make function. Avoiding invocation
of this on incompatible host platforms will be implemented separately.
Change-Id: I768e2f9a265c78814a4adf2edee4cc46cda0f5b8
This patch adds an option to the ARM common platforms to load BL31 in the
TZC secured DRAM instead of the default secure SRAM.
To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options.
If TSP is present, then setting this option also sets the TSP location
to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag.
To use this feature, BL2 platform code must map in the DRAM used by
BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose.
Currently, only the FVP BL2 platform code maps in this DRAM.
Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
These macros are unused and redundant with other CPU system registers
functions.
Moreover enable_serror() function implementation may not reach its purpose
because it does not handle the value of SCR_EL3.EA.
Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>
Asynchronous abort exceptions generated by the platform during cold boot are
not taken in EL3 unless SCR_EL3.EA is set.
Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture
initialisation. Further write accesses to SCR_EL3 preserve these bits during
cold boot.
A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions
being trapped by EL3 after cold boot or not.
For further reference SError Interrupts are also known as asynchronous external
aborts.
On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in
EL3 whatever the SCR_EL3.EA value is.
Fixesarm-software/tf-issues#368
Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>
The Firmware Design document is meant to provide a general overview
of the Trusted Firmware code. Although it is useful to provide some
guidance around the responsibilities of the platform layer, it should
not provide too much platform specific implementation details. Right
now, some sections are too tied to the implementation on ARM
platforms. This makes the Firmware Design document harder to digest.
This patch simplifies this aspect of the Firmware Design document.
The sections relating the platform initialisations performed by the
different BL stages have been simplified and the extra details about
the ARM platforms implementation have been moved to the Porting Guide
when appropriate.
This patch also provides various documentation fixes and additions
in the Firmware Design and Platform Porting Guide. In particular:
- Update list of SMCs supported by BL1.
- Remove MMU setup from architectural inits, as it is actually
performed by platform code.
- Similarly, move runtime services initialisation, BL2 image
initialization and BL33 execution out of the platform
initialisation paragraph.
- List SError interrupt unmasking as part of BL1 architectural
initialization.
- Mention Trusted Watchdog enabling in BL1 on ARM platforms.
- Fix order of steps in "BL2 image load and execution" section.
- Refresh section about GICv3/GICv2 drivers initialisation on
ARM platforms.
Change-Id: I32113c4ffdc26687042629cd8bbdbb34d91e3c14
The assembler helper function `print_revision_warning` is used when a
CPU specific operation is enabled in the debug build (e.g. an errata
workaround) but doesn't apply to the executing CPU's revision/part number.
However, in some cases the system integrator may want a single binary to
support multiple platforms with different IP versions, only some of which
contain a specific erratum. In this case, the warning can be emitted very
frequently when CPUs are being powered on/off.
This patch modifies this warning print behaviour so that it is emitted only
when LOG_LEVEL >= LOG_LEVEL_VERBOSE. The `debug.h` header file now contains
guard macros so that it can be included in assembly code.
Change-Id: Ic6e7a07f128dcdb8498a5bfdae920a8feeea1345
Added a new platform porting function plat_panic_handler, to allow
platforms to handle unexpected error situations. It must be
implemented in assembly as it may be called before the C environment
is initialized. A default implementation is provided, which simply
spins.
Corrected all dead loops in generic code to call this function
instead. This includes the dead loop that occurs at the end of the
call to panic().
All unnecesary wfis from bl32/tsp/aarch64/tsp_exceptions.S have
been removed.
Change-Id: I67cb85f6112fa8e77bd62f5718efcef4173d8134
Hence memmap device can be used to load an image without being wrapped in a
FIP.
Fixesarm-software/tf-issues#371
Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>
This patch adds big core ARMPLL control in system suspend flow.
Change-Id: I27a45dbbb360f17ff0b524a125630358ee2277e2
Signed-off-by: Louis Yu <louis.yu@mediatek.com>
Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
We no longer need to control power signal via gpio during system off,
thus remove gpio driver support from platform code.
Change-Id: I6dfec129fa163330951f37b45b71ba5b90355c3b
Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
MT8173 platform code is incompatible with RESET_TO_BL31, add #error
directive to prevent the case.
We also move mt8173_def.h and plat_private.h to include directory, and
remove some unnecessary code.
Change-Id: I47b8d0a506820a4ea1fbe8c8fb0ec6c68d88feb5
Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
The previous reset code in BL1 performed the following steps in
order:
1. Warm/Cold boot detection.
If it's a warm boot, jump to warm boot entrypoint.
2. Primary/Secondary CPU detection.
If it's a secondary CPU, jump to plat_secondary_cold_boot_setup(),
which doesn't return.
3. CPU initialisations (cache, TLB...).
4. Memory and C runtime initialization.
For a secondary CPU, steps 3 and 4 are never reached. This shouldn't
be a problem in most cases, since current implementations of
plat_secondary_cold_boot_setup() either panic or power down the
secondary CPUs.
The main concern is the lack of secondary CPU initialization when
bare metal EL3 payloads are used in case they don't take care of this
initialisation themselves.
This patch moves the detection of primary/secondary CPU after step 3
so that the CPU initialisations are performed per-CPU, while the
memory and the C runtime initialisation are only performed on the
primary CPU. The diagrams used in the ARM Trusted Firmware Reset
Design documentation file have been updated to reflect the new boot
flow.
Platforms ports might be affected by this patch depending on the
behaviour of plat_secondary_cold_boot_setup(), as the state of the
platform when entering this function will be different.
FixesARM-software/tf-issues#342
Change-Id: Icbf4a0ee2a3e5b856030064472f9fa6696f2eb9e
This patch clarifies a porting API in the Porting Guide that do not
follow the ARM Architecture Program Calling Standards (AAPCS). The
list of registers that are allowed to be clobbered by this API has
been updated in the Porting Guide.
FixesARM-software/tf-issues#259
Change-Id: Ibf2adda2e1fb3e9b8f53d8a918d5998356eb8fce
The current translation table code maps in a series of regions, zeroing
the unmapped table entries before and in between the mapped regions. It
doesn't, however, zero the unmapped entries after the last mapped
region, leaving those entries at whatever value that memory has
initially.
This is bad because those values can look like valid translation table
entries, pointing to valid physical addresses. The CPU is allowed to do
speculative reads from any such addresses. If the addresses point to
device memory, the results can be unpredictable.
This patch zeroes the translation table entries following the last
mapped region, ensuring all table entries are either valid or zero
(invalid).
In addition, it limits the value of ADDR_SPACE_SIZE to those allowed by
the architecture and supported by the current code (see D4.2.5 in the
Architecture Reference Manual). This simplifies this patch a lot and
ensures existing code doesn't do unexpected things.
Change-Id: Ic28b6c3f89d73ef58fa80319a9466bb2c7131c21
At the moment, the memory translation library allows to create memory
mappings of 2 types:
- Device nGnRE memory (named MT_DEVICE in the library);
- Normal, Inner Write-back non-transient, Outer Write-back
non-transient memory (named MT_MEMORY in the library).
As a consequence, the library code treats the memory type field as a
boolean: everything that is not device memory is normal memory and
vice-versa.
In reality, the ARMv8 architecture allows up to 8 types of memory to
be used at a single time for a given exception level. This patch
reworks the memory attributes such that the memory type is now defined
as an integer ranging from 0 to 7 instead of a boolean. This makes it
possible to extend the list of memory types supported by the memory
translation library.
The priority system dictating memory attributes for overlapping
memory regions has been extended to cope with these changes but the
algorithm at its core has been preserved. When a memory region is
re-mapped with different memory attributes, the memory translation
library examines the former attributes and updates them only if
the new attributes create a more restrictive mapping. This behaviour
is unchanged, only the manipulation of the value has been modified
to cope with the new format.
This patch also introduces a new type of memory mapping in the memory
translation library: MT_NON_CACHEABLE, meaning Normal, Inner
Non-cacheable, Outer Non-cacheable memory. This can be useful to map
a non-cacheable memory region, such as a DMA buffer for example.
The rules around the Execute-Never (XN) bit in a translation table
for an MT_NON_CACHEABLE memory mapping have been aligned on the rules
used for MT_MEMORY mappings:
- If the memory is read-only then it is also executable (XN = 0);
- If the memory is read-write then it is not executable (XN = 1).
The shareability field for MT_NON_CACHEABLE mappings is always set as
'Outer-Shareable'. Note that this is not strictly needed since
shareability is only relevant if the memory is a Normal Cacheable
memory type, but this is to align with the existing device memory
mappings setup. All Device and Normal Non-cacheable memory regions
are always treated as Outer Shareable, regardless of the translation
table shareability attributes.
This patch also removes the 'ATTR_SO' and 'ATTR_SO_INDEX' #defines.
They were introduced to map memory as Device nGnRnE (formerly called
"Strongly-Ordered" memory in the ARMv7 architecture) but were not
used anywhere in the code base. Removing them avoids any confusion
about the memory types supported by the library.
Upstream platforms do not currently use the MT_NON_CACHEABLE memory
type.
NOTE: THIS CHANGE IS SOURCE COMPATIBLE BUT PLATFORMS THAT RELY ON THE
BINARY VALUES OF `mmap_attr_t` or the `attr` argument of
`mmap_add_region()` MAY BE BROKEN.
Change-Id: I717d6ed79b4c845a04e34132432f98b93d661d79
From version 4.0 onwards, the ARM64 Linux kernel expects the device
tree to indicate the cache hierarchy. Failing to provide this
information results in the following warning message to be printed by
the kernel:
`Unable to detect cache hierarchy from DT for CPU x`
All the FVP device trees provided in the TF source tree have been
modified to add this information.
FixesARM-software/tf-issues#325
Change-Id: I0ff888992e602b81a0fe1744a86151d625727511
Enable alternative boot flow where BL2 does not load BL33 from
non-volatile storage, and BL31 hands execution over to a preloaded
BL33.
The flag used to enable this bootflow is BL33_BASE, which must hold
the entrypoint address of the BL33 image. The User Guide has been
updated with an example of how to use this option with a bootwrapped
kernel.
Change-Id: I48087421a7b0636ac40dca7d457d745129da474f
All C files of stdlib were included into std.c, which was the file
that the Makefile actually compiled. This is a poor way of compiling
all the files and, while it may work fine most times, it's
discouraged.
In this particular case, each C file included its own headers, which
were later included into std.c. For example, this caused problems
because a duplicated typedef of u_short in both subr_prf.c and
types.h. While that may require an issue on its own, this kind of
problems are avoided if all C files are as independent as possible.
Change-Id: I9a7833fd2933003f19a5d7db921ed8542ea2d04a
The PL011 initialization function disables the UART, flushes the FIFO
and waits for the current character to be transmitted before applying
the configuration and enabling the UART. This waiting might result in
a deadlock if the FIFO is disabled while another CPU is printing a
message since the flush of FIFO will never finish.
This patch fixes the problem by removing the flush operation and the
loop for last character completion from the initialization function.
The UART is disabled, configured and enabled again.
Change-Id: I1ca0b6bd9f352c12856f10f174a9f6eaca3ab4ea
This patch fixes inconsistencies in bl1_tbbr_image_descs[]
and miscellaneous fixes in Firmware Update code.
Following are the changes:
* As part of the original FWU changes, a `copied_size`
field was added to `image_info_t`. This was a subtle binary
compatibility break because it changed the size of the
`bl31_params_t` struct, which could cause problems if
somebody used different versions of BL2 or BL31, one with
the old `image_info_t` and one with the new version.
This patch put the `copied_size` within the `image_desc_t`.
* EXECUTABLE flag is now stored in `ep_info.h.attr` in place
of `image_info.h.attr`, associating it to an entrypoint.
* The `image_info.image_base` is only relevant for secure
images that are copied from non-secure memory into secure
memory. This patch removes initializing `image_base` for
non secure images in the bl1_tbbr_image_descs[].
* A new macro `SET_STATIC_PARAM_HEAD` is added for populating
bl1_tbbr_image_descs[].ep_info/image_info.h members statically.
The version, image_type and image attributes are now
populated using this new macro.
* Added PLAT_ARM_NVM_BASE and PLAT_ARM_NVM_SIZE to avoid direct
usage of V2M_FLASH0_XXX in plat/arm/common/arm_bl1_fwu.c.
* Refactoring of code/macros related to SECURE and EXECUTABLE flags.
NOTE: PLATFORM PORTS THAT RELY ON THE SIZE OF `image_info_t`
OR USE the "EXECUTABLE" BIT WITHIN `image_info_t.h.attr`
OR USE THEIR OWN `image_desc_t` ARRAY IN BL1, MAY BE
BROKEN BY THIS CHANGE. THIS IS CONSIDERED UNLIKELY.
Change-Id: Id4e5989af7bf0ed263d19d3751939da1169b561d
`board_arm_def.h` contains multiple definitions of
`PLAT_ARM_MMAP_ENTRIES` and `MAX_XLAT_TABLES` that are optimised for
memory usage depending upon the chosen build configuration. To ease
maintenance of these constants, this patch replaces their multiple
definitions with a single set of definitions that will work on all ARM
platforms.
Platforms can override the defaults with optimal values by enabling the
`ARM_BOARD_OPTIMISE_MMAP` build option. An example has been provided in
the Juno ADP port.
Additionally, `PLAT_ARM_MMAP_ENTRIES` is increased by one to accomodate
future ARM platforms.
Change-Id: I5ba6490fdd1e118cc9cc2d988ad7e9c38492b6f0
