- 01 Feb, 2018 12 commits
-
-
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
This complicated if-conditional combo was introduced by commit 70d1fc53 ("Fix build error when `BL32` is not defined") in order to fix the compile error of "make all" when SPD=opteed is given. The requirement for the build system is like follows: - If both BL32 and BL32_SOURCES are defined, the former takes precedence. - If BL32 is undefined but BL32_SOURCES is defined, we compile BL32 from the source files. - We want to let the build fail if neither of them is defined, but we want to check it only when we are building FIP. Refactor the code to not call FIP_ADD_IMG twice. The behavior is still the same. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
We use $(call MAKE_TOOL_ARGS,...) or $(call FIP_ADD_IMG,...) where we expect externally built images. The difference between the two is check_* target. It now checks if the given path exists, so it is a good thing to use $(call FIP_ADD_IMG,...) in all the places. 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>
-
davidcunado-arm authored
RK3399 GIC save/restore
-
- 30 Jan, 2018 4 commits
-
-
davidcunado-arm authored
fiptool: Fix use after free
-
davidcunado-arm authored
Makefile: Use ld.bfd linker if available
-
davidcunado-arm authored
Correct the Makefile logic for disabling PIE
-
davidcunado-arm authored
Fix udelay issues that can make duration slightly too short
-
- 29 Jan, 2018 8 commits
-
-
davidcunado-arm authored
SPM: Map devices in the 1st GB
-
davidcunado-arm authored
Fix documentation for CnP bit
-
davidcunado-arm authored
docs: hikey: Fix typo
-
Julius Werner authored
Some toolchain distributions install both the BFD and GOLD linkers under the names <target>-ld.bfd and <target>-ld.gold. <target>-ld will then be a symlink that may point to either one of these. Trusted Firmware should always be linked with the BFD linker, since GOLD is meant primarily for userspace programs and doesn't support many of the more obscure linker script features that may be needed for firmware. With this patch the Makefile will auto-detect if ld.bfd is available and use it explicitly in that case. Change-Id: I7017055f67db3bd57d191d20a7af06ca646937d7 Signed-off-by: Julius Werner <jwerner@chromium.org>
-
Sandrine Bailleux authored
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>
-
davidcunado-arm authored
hikey: fix assert in sec_protect()
-
Sandrine Bailleux authored
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>
-
Andreas Färber authored
The correct name of the manufacturer is LeMaker. Signed-off-by: Andreas Färber <afaerber@suse.de>
-
- 27 Jan, 2018 2 commits
-
-
Andreas Färber authored
Commit 880b9e8b (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>
-
Victor Chong authored
`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>
-
- 26 Jan, 2018 2 commits
-
-
davidcunado-arm authored
Hikey protect optee / sdp memory
-
Derek Basehore authored
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>
-
- 25 Jan, 2018 5 commits
-
-
Julius Werner authored
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>
-
davidcunado-arm authored
uniphier: migrate to BL2-AT-EL3
-
davidcunado-arm authored
SPM: Declare explicit width based types in secure_partition_boot_info…
-
davidcunado-arm authored
Hikey960: Enable invalid FIQ handling
-
davidcunado-arm authored
Workarounds for CVE-2017-5715 on A9/A15 and A17 + serial console reporting
-
- 24 Jan, 2018 7 commits
-
-
davidcunado-arm authored
poplar: Enable emmc and recovery build support
-
davidcunado-arm authored
New console API and coreboot support [v4]
-
Masahiro Yamada authored
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>
-
Masahiro Yamada authored
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>
-
davidcunado-arm authored
Allow API deprecation for uniphier platform
-
Peter Griffin authored
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>
-
Jerome Forissier authored
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>
-