GitLab

Correct the Makefile logic for disabling PIE

Fix udelay issues that can make duration slightly too short

SPM: Map devices in the 1st GB

Fix documentation for CnP bit

docs: hikey: Fix typo

The CnP bit documentation in the Firmware Design Guide incorrectly
used the term "Page Entries" instead of "Processing Elements".
Fix that.

Change-Id: Ie44ee99c281b7b1a9ad90fba2c7d109f12425507
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

hikey: fix assert in sec_protect()

This patch maps the devices in the first GB of the system address map
on the FVP into the S-EL1&0 translation regime when SPM support is
enabled. This grants the Secure Partition access to the devices in
this region, for example the memory-mapped Generic Timer device.

Change-Id: I3aeea65f859ecbe83efde2acee20c55500c451bc
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

The correct name of the manufacturer is LeMaker.
Signed-off-by: Andreas Färber <afaerber@suse.de>

`assert(e)` was used in place of `if (e) ERROR()` when sec_protect()
was ported from hikey fork so the logic should have been reversed.

Fixes: 3d5d9f5a ("hikey: configure the top 16MB of DRAM as secure")
Fixes: 52988b38

 ("hikey: configure 4 MB of secure DRAM for OP-TEE
Secure Data Path")
Signed-off-by: Victor Chong <victor.chong@linaro.org>
Tested-by: Victor Chong <victor.chong@linaro.org>

Hikey protect optee / sdp memory

Delay functions like udelay() are often used to ensure that the
necessary time passed to allow some asynchronous event to finish, such
as the stabilization delay for a power rail. For these use cases it is
not very problematic if the delay is slightly longer than requested,
but it is critical that the delay must never be shorter.

The current udelay() implementation contains two hazards that may cause
the delay to be slightly shorter than intended: Firstly, the amount of
ticks to wait is calculated with an integer division, which may cut off
the last fraction of ticks needed. Secondly, the delay may be short by a
fraction of a tick because we do not know whether the initial ("start")
sample of the timer was near the start or near the end of the current
tick. Thus, if the code intends to wait for one tick, it might read the
timer value close to the end of the current tick and then read it again
right after the start of the next tick, concluding that the duration of
a full tick has passed when it in fact was just a fraction of it.

This patch rounds up the division and always adds one extra tick to
counteract both problems and ensure that delays will always be larger
but never smaller than requested.

Change-Id: Ic5fe5f858b5cdf3c0dbf3e488d4d5702d9569433
Signed-off-by: Julius Werner <jwerner@chromium.org>

uniphier: migrate to BL2-AT-EL3

SPM: Declare explicit width based types in secure_partition_boot_info…

Hikey960: Enable invalid FIQ handling

Workarounds for CVE-2017-5715 on A9/A15 and A17 + serial console reporting

poplar: Enable emmc and recovery build support

New console API and coreboot support [v4]

UniPhier platform implements non-TF boot ROM.  Prior to the BL2-AT-EL3
support, BL1 (worked as a pseudo ROM) was needed just for ensuring BL2
is entered at EL1-S.  Now, this platform is able to avoid this waste.

Enable the BL2_AT_EL3 option, and remove BL1.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The warm boot mailbox code is compiled if PROGRAMMABLE_RESET_ADDRESS
is disabled.

The warm boot mailbox is useless for UniPhier SoC family because BL1
is not the first image.  The UniPhier platform implements non-TF ROM,
then BL1 works as a pseudo ROM, so it is never executed in the warm
boot.

The reset vector address is not actually programmable for UniPhier
platform, but it should not hurt to enable PROGRAMMABLE_RESET_ADDRESS
to disable the mailbox and remove pointless plat_get_my_entrypoint.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Allow API deprecation for uniphier platform

Update the memory firewall configuration to reserve 4 MB of secure RAM
for use by the kernel and OP-TEE as the Secure Data Path pool.
Note that this address range (0x3E800000 - 0x3EC00000) falls in the
range already set aside by UEFI (which reserves the upper 32 MB of the
1GB DRAM for OP-TEE [1]) and was previously unused.

[1] https://github.com/96boards-hikey/edk2/blob/hikey/HisiPkg/HiKeyPkg/Library/HiKeyLib/HiKeyMem.c#L44

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Victor Chong <victor.chong@linaro.org>

DRAM region 0x3f000000 - 0x3fffffff is reserved for OP-TEE and should
therefore be accessible only from secure world.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Victor Chong <victor.chong@linaro.org>

In the Makefile we use findstring to locate gcc toolchains
that have PIE enabled by default.

Unfortunately the result of findstring is compared against
an integer, 1, rather than a non-empty string; the logic to
disable PIE then doesn't get applied.

This patch fixes the flag test.

Fixes: f7ec31db

 ("Disable PIE compilation option")
Change-Id: I4cd2866974e313d6b408f9681311d78a208ab468
Signed-off-by: Steve Capper <steve.capper@arm.com>

The current div_round_up() implementation relies on round_up() which
only works correctly for boundaries that are a power of 2. It is
documented as such, but this still seems dangerously easy to overlook,
especially since many other environments (e.g. the Linux kernel) have a
similar macro without these limitations.

There is a different way to calculate this that can deal with all kinds
of divisors without other drawbacks, so let's just use that instead.

Change-Id: Id382736683f5d4e880ef00c53cfa23a2f9208440
Signed-off-by: Julius Werner <jwerner@chromium.org>

The secure_partition_boot_info_t structure is used to communicate boot
parameters with the StandaloneMM code executing at S-EL0 through a
shared buffer. Certain data types used for members of this structure
are opaque with their size depending on the toolchain being used.

Declare the members of the structure with explicit width based data
types, which would maintain compatibility across toolchains.
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>

The `override ERROR_DEPRECATION = 1` setting in uniphier platform
makes deprecation of API difficult. Hence removing the same. This
flag should be specified on the command line if needed.

Change-Id: I8c82d8d13944e450a8cd636de3326137c04d7560
Signed-off-by: Soby Mathew <soby.mathew@arm.com>

Signed-off-by: Victor Chong <victor.chong@linaro.org>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>

Let bl1 and bl2 have the ability to load images from emmc instead of
dram (mmap).
Signed-off-by: Victor Chong <victor.chong@linaro.org>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>

When some interrupts are configured as group 0 in GICv2, these
interrupts trigger FIQ signal; this results in the Linux kernel panic
by reporting log: "Bad mode in FIQ handler detected on CPU0, code
0x00000000 -- Unknown/Uncategorized".  Unfortunately from kernel side it
has no permission to read the GIC register for group 0 interrupts so we
have no chance to get to know which interrupt is configured as secure
interrupt and cause the kernel panic.

For upper reason, this commit enables FIQ exception handling for
SPD_none case.  If the system has not enabled SPD the FIQ interrupt is
trapped into EL3 and the FIQ handler can report the interrupt number so
we can easily narrow down which FIQ introduce unexpected interrupt.
After enable SPD we can rely on SPD interrupt route model to handle FIQ.
Signed-off-by: Leo Yan <leo.yan@linaro.org>

lib/cpus: fix branching in reset function for cortex-a72 AARCH32 mode

emmc: add macros CMD21, BUS_WIDTH_DDR_4 and BUS_WIDTH_DDR_8

coreboot supports an in-memory console to store firmware logs even when
no serial console is available. It is widely supported by
coreboot-compatible bootloaders (including SeaBIOS and GRUB) and can be
read by the Linux kernel.

This patch allows BL31 to add its own log messages to this console. The
driver will be registered automatically if coreboot support is compiled
in and detects the presence of a console buffer in the coreboot tables.

Change-Id: I31254dfa0c2fdeb7454634134b5707b4b4154907
Signed-off-by: Julius Werner <jwerner@chromium.org>

This patch changes all Rockchip platforms to use the new
MULTI_CONSOLE_API. The platform-specific plat_crash_console
implementations are removed so that the platform can use the ones from
the common platform code instead.

Also change the registers used in plat_crash_print_regs. The existing
use of x16 and x17 has always been illegal, since those registers are
reserved for use by the linker as a temporary scratch registers in
intra-procedure-call veneers and can never be expected to maintain their
values across a function call.

Change-Id: I8249424150be8d5543ed4af93b56756795a5288f
Signed-off-by: Julius Werner <jwerner@chromium.org>

This patch changes all Rockchip platforms to initialize the serial
console with information supplied by coreboot rather than hardcoded
base address and divisor values if BL31 is run on top of coreboot.
Moving the BL2-to-BL31 parameter parsing as early as possible to ensure
that the console is available for all following code.

Also update the Rockchip platform to use MULTI_CONSOLE_API.

Change-Id: I670d350fa2f8b8133539f91ac14977ab47db60d9
Signed-off-by: Julius Werner <jwerner@chromium.org>

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>

This patch updates the Cadence CDNS console driver to support the new
console API. The driver will continue to support the old API as well by
checking the MULTI_CONSOLE_API compile-time flag.

Change-Id: I2ef8fb0d6ab72696997db1e0243a533499569d6b
Signed-off-by: Julius Werner <jwerner@chromium.org>

This patch updates the ARM PL011 console driver to support the new
console API. The driver will continue to support the old API as well by
checking the MULTI_CONSOLE_API compile-time flag.

Change-Id: Ic34e4158addbb0c5fae500c9cff899c05a4f4206
Signed-off-by: Julius Werner <jwerner@chromium.org>

This patch updates the TI 16550 console driver to support the new
console API. The driver will continue to support the old API as well by
checking the MULTI_CONSOLE_API compile-time flag.

Change-Id: I60a44b7ba3c35c74561824c04b8dbe3e3039324c
Signed-off-by: Julius Werner <jwerner@chromium.org>

This patch expands the weak stubs for the plat_crash_console_xxx
functions in common platform code to use the new console API for crash
output. This should make crash console output "just work" for most cases
without the need for the platform to explicitly set up a crash console.
For cases where the normal console framework doesn't work (e.g. very
early crashes, before the platform can register any consoles), platforms
are still able to override the functions just like before.

This feature requires the MULTI_CONSOLE_API compile-time flag to work.
For builds which don't have it set, this patch has no practical effect.

Change-Id: I80dd161cb43f9db59a0bad2dae33c6560cfac584
Signed-off-by: Julius Werner <jwerner@chromium.org>