Whitebox
/
u-boot
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
upstream u-boot with additional patches for our devices/boards: https://lists.denx.de/pipermail/u-boot/2017-March/282789.html (AXP crashes) ; Gbit ethernet patch for some LIME2 revisions ; with SPI flash support
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
52518 Commits
3 Branches
0 Tags
148 MiB
Tag: Branch: Tree: 45029758be
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '45029758be'
${ noResults }
u-boot/arch/arm/include/asm/omap_sec_common.h

66 lines
2.1 KiB
Raw Normal View History Unescape

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
7 years ago
/* SPDX-License-Identifier: GPL-2.0+ */
arm: omap-common: add secure rom call API for secure devices Adds a generic C-callable API for making secure ROM calls on OMAP and OMAP-compatible devices. This API provides the important function of flushing the ROM call arguments to memory from the cache, so that the secure world will have a coherent view of those arguments. Then is simply calls the omap_smc_sec routine. Signed-off-by: Daniel Allred <d-allred@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
9 years ago
/*
* (C) Copyright 2016
* Texas Instruments, <www.ti.com>
*
* Andreas Dannenberg <dannenberg@ti.com>
*/
#ifndef _OMAP_SEC_COMMON_H_
#define _OMAP_SEC_COMMON_H_
#include <common.h>
/*
* Invoke secure ROM API on high-security (HS) device variants. It formats
* the variable argument list into the format expected by the ROM code before
* triggering the actual low-level smc entry.
*/
u32 secure_rom_call(u32 service, u32 proc_id, u32 flag, ...);
arm: omap-common: secure ROM signature verify API Adds an API that verifies a signature attached to an image (binary blob). This API is basically a entry to a secure ROM service provided by the device and accessed via an SMC call, using a particular calling convention. Signed-off-by: Daniel Allred <d-allred@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
9 years ago
/*
* Invoke a secure ROM API on high-secure (HS) device variants that can be used
* to verify a secure blob by authenticating and optionally decrypting it. The
* exact operation performed depends on how the certificate that was embedded
* into the blob during the signing/encryption step when the secure blob was
* first created.
*/
int secure_boot_verify_image(void **p_image, size_t *p_size);
arm: omap5: secure API for EMIF memory reservations Create a few public APIs which rely on secure world ROM/HAL APIs for their implementation. These are intended to be used to reserve a portion of the EMIF memory and configure hardware firewalls around that region to prevent public code from manipulating or interfering with that memory. Signed-off-by: Daniel Allred <d-allred@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
8 years ago
/*
arm: mach-omap2: Factor out common FDT fixup suport Some of the fixups currently done for OMAP5 class boards are common to other OMAP family devices, move these to fdt-common.c. Signed-off-by: Andrew F. Davis <afd@ti.com>
7 years ago
* Return the start of secure reserved RAM, if a default start address has
* not been configured then return a region at the end of the external DRAM.
*/
u32 get_sec_mem_start(void);
/*
arm: omap5: secure API for EMIF memory reservations Create a few public APIs which rely on secure world ROM/HAL APIs for their implementation. These are intended to be used to reserve a portion of the EMIF memory and configure hardware firewalls around that region to prevent public code from manipulating or interfering with that memory. Signed-off-by: Daniel Allred <d-allred@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
8 years ago
* Invoke a secure HAL API that allows configuration of the external memory
* firewall regions.
*/
int secure_emif_firewall_setup(uint8_t region_num, uint32_t start_addr,
uint32_t size, uint32_t access_perm,
uint32_t initiator_perm);
/*
* Invoke a secure HAL API on high-secure (HS) device variants that reserves a
* region of external memory for secure world use, and protects it using memory
* firewalls that prevent public world access. This API is intended to setaside
* memory that will be used for a secure world OS/TEE.
*/
int secure_emif_reserve(void);
/*
* Invoke a secure HAL API to lock the external memory firewall configurations.
* After this API is called, none of the HAL APIs for configuring the that
* firewall will be usable (calls to those APIs will return failure and have
* no effect).
*/
int secure_emif_firewall_lock(void);
arm: omap5: Add TEE loading support secure_tee_install is used to install and initialize a secure TEE OS such as Linaro OP-TEE into the secure world. This function takes in the address where the signed TEE image is loaded as an argument. The signed TEE image consists of a header (struct tee_header), TEE code+data followed by the signature generated using image signing tool from TI security development package (SECDEV). Refer to README.ti-secure for more information. This function uses 2 new secure APIs. 1. PPA_SERV_HAL_TEE_LOAD_MASTER - Must be called on CPU Core 0. Protected memory for TEE must be reserved before calling this function. This API needs arguments filled into struct ppa_tee_load_info. The TEE image is authenticated and if there are no errors, the control passes to the TEE entry point. 2. PPA_SERV_HAL_TEE_LOAD_SLAVE - Called on other CPU cores only after a TEE_LOAD_MASTER call. Takes no arguments. Checks if TEE was successfully loaded (on core 0) and transfers control to the same TEE entry point. The code at TEE entry point is expected perform OS initialization steps and return back to non-secure world (U-Boot). Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
8 years ago
/*
* Invoke a secure HAL API to authenticate and install a Trusted Execution
* Environment (TEE) image.
*/
int secure_tee_install(u32 tee_image);
arm: omap-common: add secure rom call API for secure devices Adds a generic C-callable API for making secure ROM calls on OMAP and OMAP-compatible devices. This API provides the important function of flushing the ROM call arguments to memory from the cache, so that the secure world will have a coherent view of those arguments. Then is simply calls the omap_smc_sec routine. Signed-off-by: Daniel Allred <d-allred@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
9 years ago
#endif /* _OMAP_SEC_COMMON_H_ */