SPM: Map devices in the 1st GB

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 Secur

SPM: Map devices in the 1st GB

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>

show more ...

docs: hikey: Fix typo

The correct name of the manufacturer is LeMaker.

Signed-off-by: Andreas Färber <afaerber@suse.de>

fiptool: Fix use after free

Commit 880b9e8b4c99ad99eee14079d5a6162733ef4931 (Add padding at the end
of the last entry) added code using toc_entry pointer, whose memory is
already freed via variable

fiptool: Fix use after free

Commit 880b9e8b4c99ad99eee14079d5a6162733ef4931 (Add padding at the end
of the last entry) added code using toc_entry pointer, whose memory is
already freed via variable buf. This causes enormous padding on openSUSE.

Free the memory buffer only after padding is done.

Signed-off-by: Andreas Färber <afaerber@suse.de>

show more ...

hikey: fix assert in sec_protect()

`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: c

hikey: fix assert in sec_protect()

`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>

show more ...

Merge pull request #1205 from petegriffin/hikey-protect-memory

Hikey protect optee / sdp memory

rockchip: Disable rdist before pwr_dm_suspend is called

This disables the redistributor before either of the pwr_dm_suspend
functions are called. This is because the rdist save code in the
rk3399 ro

rockchip: Disable rdist before pwr_dm_suspend is called

This disables the redistributor before either of the pwr_dm_suspend
functions are called. This is because the rdist save code in the
rk3399 rockchip_soc_sys_pwr_dm_suspend function requires that each
redistributor be disabled before saving state.

Signed-off-by: Derek Basehore <dbasehore@chromium.org>

show more ...

delay_timer: Guarantee that delay time can never be undershot

Delay functions like udelay() are often used to ensure that the
necessary time passed to allow some asynchronous event to finish, such
a

delay_timer: Guarantee that delay time can never be undershot

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>

show more ...

Merge pull request #1232 from masahir0y/uniphier

uniphier: migrate to BL2-AT-EL3

trusty: Pass cpu suspend/resume reason to trusty

Add off/on argument to SMC_FC_CPU_SUSPEND SMC_FC_CPU_RESUME and pass
1 when called from the cpu on/off hooks.

Change-Id: Ie233c446fd38b3ff8546e445a8

trusty: Pass cpu suspend/resume reason to trusty

Add off/on argument to SMC_FC_CPU_SUSPEND SMC_FC_CPU_RESUME and pass
1 when called from the cpu on/off hooks.

Change-Id: Ie233c446fd38b3ff8546e445a8d86a15d2816093
Signed-off-by: Arve Hjønnevåg <arve@android.com>

show more ...

trusty: Run bl33 in EL1 instead of EL2 is trusty image is 32-bit

The secure physical timer is inacessible from 32-bit S-EL1 (when EL3
is 64-bit) so trusty will use the non-secure physical timer in t

trusty: Run bl33 in EL1 instead of EL2 is trusty image is 32-bit

The secure physical timer is inacessible from 32-bit S-EL1 (when EL3
is 64-bit) so trusty will use the non-secure physical timer in this
case. Linux will use the virtual timer instead of the physical timer
when started in EL1.

Change-Id: Ie49348d9a27e5287676dd4a77f678ecbd6c2309f
Signed-off-by: Arve Hjønnevåg <arve@android.com>

show more ...

trusty: Add fpu/simd support

The original patch has been partly merged. This adds the missing
pieces.

Change-Id: I77fd434feab396ff05d9b8e0c1761e4dd588a701
Signed-off-by: Arve Hjønnevåg <arve@androi

trusty: Add fpu/simd support

The original patch has been partly merged. This adds the missing
pieces.

Change-Id: I77fd434feab396ff05d9b8e0c1761e4dd588a701
Signed-off-by: Arve Hjønnevåg <arve@android.com>

show more ...

trusty: Add generic-arm64 support

Add smc calls to return gic base address and print to the debug
console. Allows running a generic trusty binary.

Change-Id: I4b6540f140f11432cdff43c3f5a2097df09dc9

trusty: Add generic-arm64 support

Add smc calls to return gic base address and print to the debug
console. Allows running a generic trusty binary.

Change-Id: I4b6540f140f11432cdff43c3f5a2097df09dc9d1
Signed-off-by: Arve Hjønnevåg <arve@android.com>

show more ...

trusty: Restore working trusty setup code and include trusty image in build

Change-Id: I081901e7df22f78dd9c4fc4c6bfad2aceb870a2d
Signed-off-by: Arve Hjønnevåg <arve@android.com>

Merge pull request #1234 from SNG-ARM/master

SPM: Declare explicit width based types in secure_partition_boot_info…

Merge pull request #1231 from Leo-Yan/hikey960_enable_fiq_handling

Hikey960: Enable invalid FIQ handling

Merge pull request #1228 from dp-arm/dp/cve_2017_5715

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

Merge pull request #1223 from vchong/poplar_bl1loadsfip

poplar: Enable emmc and recovery build support

Merge pull request #1193 from jwerner-chromium/JW_coreboot

New console API and coreboot support [v4]

uniphier: switch to BL2-AT-EL3 and remove BL1 support

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

uniphier: switch to BL2-AT-EL3 and remove BL1 support

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>

show more ...

uniphier: set PROGRAMMABLE_RESET_ADDRESS to disable warm boot mailbox

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

The warm boot mailbox is useless for UniPhier

uniphier: set PROGRAMMABLE_RESET_ADDRESS to disable warm boot mailbox

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>

show more ...

Merge pull request #1233 from soby-mathew/sm/rm_uniphier_override

Allow API deprecation for uniphier platform

hikey: configure 4 MB of secure DRAM for OP-TEE Secure Data Path

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.

hikey: configure 4 MB of secure DRAM for OP-TEE Secure Data Path

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>

show more ...

hikey: configure the top 16MB of DRAM as secure

DRAM region 0x3f000000 - 0x3fffffff is reserved for OP-TEE and should
therefore be accessible only from secure world.

Signed-off-by: Jerome Forissier

hikey: configure the top 16MB of DRAM as secure

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>

show more ...

rockchip/rk3399: Save and restore GIC

This adds calls to the GICv3 save/restore functions for the GIC
distributor and redistributor.

Signed-off-by: Derek Basehore <dbasehore@chromium.org>

rockchip/rk3399: Add udelay to wait loops

We were looping for MAX_WAIT_COUNT in several places without any
delays, so this adds the delays to make those loops more predictable.

Signed-off-by: Derek

rockchip/rk3399: Add udelay to wait loops

We were looping for MAX_WAIT_COUNT in several places without any
delays, so this adds the delays to make those loops more predictable.

Signed-off-by: Derek Basehore <dbasehore@chromium.org>

show more ...