blob: d23044a1c368a1d7fd5435db1ba84280f18be5d5 [file] [log] [blame]
Marc Zyngierf510aea2014-07-12 14:24:03 +01001#ifndef __ASM_SECURE_H
2#define __ASM_SECURE_H
3
4#include <config.h>
5
Chen-Yu Tsaiafc1f652016-06-19 12:38:41 +08006#define __secure __attribute__ ((section ("._secure.text")))
Chen-Yu Tsaia5aa7ff2016-07-05 21:45:06 +08007#define __secure_data __attribute__ ((section ("._secure.data")))
Chen-Yu Tsaiafc1f652016-06-19 12:38:41 +08008
macro.wave.z@gmail.com9a561752016-12-08 11:58:25 +08009#if defined(CONFIG_ARMV7_SECURE_BASE) || defined(CONFIG_ARMV8_SECURE_BASE)
Marc Zyngierf510aea2014-07-12 14:24:03 +010010/*
11 * Warning, horror ahead.
12 *
13 * The target code lives in our "secure ram", but u-boot doesn't know
14 * that, and has blindly added reloc_off to every relocation
15 * entry. Gahh. Do the opposite conversion. This hack also prevents
16 * GCC from generating code veeners, which u-boot doesn't relocate at
17 * all...
18 */
19#define secure_ram_addr(_fn) ({ \
20 DECLARE_GLOBAL_DATA_PTR; \
21 void *__fn = _fn; \
22 typeof(_fn) *__tmp = (__fn - gd->reloc_off); \
23 __tmp; \
24 })
25#else
26#define secure_ram_addr(_fn) (_fn)
27#endif
28
29#endif