| #
c89e397c |
| 10-Nov-2022 |
Nasreddine Ouldei Tebina <tebina1@live.fr> |
plat-zynqmp: add ZCU104 and ZCU106 flavour support
Adding support for the ZCU104 and ZCU106 boards since they possess the same core as the ZCU102. This is to avoid having the "flavour not supported
plat-zynqmp: add ZCU104 and ZCU106 flavour support
Adding support for the ZCU104 and ZCU106 boards since they possess the same core as the ZCU102. This is to avoid having the "flavour not supported error" when compiling for the ZCU104 and ZCU106.
Tested successfully on the ZCU106
Tested-by: Nasreddine Ouldei Tebina <tebina1@live.fr> Signed-off-by: Nasreddine Ouldei Tebina <tebina1@live.fr> Acked-by: Jerome Forissier <jerome.forissier@linaro.org> Acked-by: Ricardo Salveti <ricardo@foundries.io>
show more ...
|
| #
dfeed924 |
| 07-May-2022 |
Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> |
drivers: zynqmp_huk: Add AES eFuse and HUK seed support
When AES eFuse is used to encrypt boot loaders and bitstreams then PUF functionality is not available for use. When AES eFuse based encryption
drivers: zynqmp_huk: Add AES eFuse and HUK seed support
When AES eFuse is used to encrypt boot loaders and bitstreams then PUF functionality is not available for use. When AES eFuse based encryption is in use AES eFuse key becomes device key instead of PUF generated key.
In order to re-plenish additional device specific entropy that PUF would provide utilize selected set of User programmable eFuses.
Selected user eFuses should be programmed during device manufacturing with cryptographically good random numbers.
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| #
b917d42e |
| 10-May-2022 |
Igor Opaniuk <igor.opaniuk@foundries.io> |
zynqmp: platform: provide uart configuration during compilation
Add possibility to provide UART configuration as a compile flag (CFG_UART_BASE, CFG_UART_IT, CFG_UART_CLK_HZ).
Acked-by: Jerome Foris
zynqmp: platform: provide uart configuration during compilation
Add possibility to provide UART configuration as a compile flag (CFG_UART_BASE, CFG_UART_IT, CFG_UART_CLK_HZ).
Acked-by: Jerome Forissier <jerome.forissier@linaro.org> Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
show more ...
|
| #
aeb2ac09 |
| 16-May-2022 |
Jerome Forissier <jerome.forissier@linaro.org> |
core: arm.mk: set CFG_WITH_LPAE=y when CFG_ARCH64_core=y
Since CFG_WITH_LPAE=y is mandatory when CFG_ARCH64_core=y, set it in the common file core/arch/arm/arm.mk instead of leaving it to the platfo
core: arm.mk: set CFG_WITH_LPAE=y when CFG_ARCH64_core=y
Since CFG_WITH_LPAE=y is mandatory when CFG_ARCH64_core=y, set it in the common file core/arch/arm/arm.mk instead of leaving it to the platforms.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| #
1e846e20 |
| 27-Jan-2022 |
Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> |
zynqmp: zcu102: Fix DDR memory size to 4 GiB
Xilinx ZCU102 board has 4 GiB of DDR memory and size must be configured properly in order for dynamic shared memory feature to work.
Without it followin
zynqmp: zcu102: Fix DDR memory size to 4 GiB
Xilinx ZCU102 board has 4 GiB of DDR memory and size must be configured properly in order for dynamic shared memory feature to work.
Without it following error might be present during kernel startup:
E/TC:0 0 std_smc_entry:183 Bad arg address 0x803989000
When compiling for 32 bits only first 2 GiB is available.
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> Acked-by: Etienne Carriere <etienne.carriere@linaro.org> Acked-by: Ricardo Salveti <ricardo@foundries.io> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
df8976a1 |
| 26-Jan-2022 |
Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> |
zynqmp: platform: make it possible to configure DDR size more flexible
Default DDR size comes from platform selection.
If only DDR size is different it is possible to override it with setting CFG_D
zynqmp: platform: make it possible to configure DDR size more flexible
Default DDR size comes from platform selection.
If only DDR size is different it is possible to override it with setting CFG_DDR_SIZE.
Automatic configuration of DDR memory mappings can also be done by device tree (CFG_DT=y) and by overriding if necessary memory address for device tree (CFG_DT_ADDR).
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> Acked-by: Etienne Carriere <etienne.carriere@linaro.org> Acked-by: Ricardo Salveti <ricardo@foundries.io> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
08363023 |
| 26-Jan-2022 |
Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> |
zynqmp: platform: configure default device tree address
Xilinx has selected 0x100000 as default memory address for device tree.
Configure it by default and make it possible to override it (CFG_DT_A
zynqmp: platform: configure default device tree address
Xilinx has selected 0x100000 as default memory address for device tree.
Configure it by default and make it possible to override it (CFG_DT_ADDR).
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> Acked-by: Etienne Carriere <etienne.carriere@linaro.org> Acked-by: Ricardo Salveti <ricardo@foundries.io> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
10a72028 |
| 26-Jan-2022 |
Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> |
zynqmp: platform: configure physical address space size
ZynqMP has several operation modes for physical address mapping: 32 bit mode, 36 bits and 40 bits
When compiling for 64 bits use full 40 bits
zynqmp: platform: configure physical address space size
ZynqMP has several operation modes for physical address mapping: 32 bit mode, 36 bits and 40 bits
When compiling for 64 bits use full 40 bits mode as default to support all features of the chip.
Signed-off-by: Vesa Jääskeläinen <vesa.jaaskelainen@vaisala.com> Acked-by: Etienne Carriere <etienne.carriere@linaro.org> Acked-by: Ricardo Salveti <ricardo@foundries.io> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
f57e4036 |
| 10-Oct-2021 |
Jorge Ramirez-Ortiz <jorge@foundries.io> |
zynqmp: platform: use HUK derived from PUF KEK for RPMB
Enable the RPMB key when the HUK is generated from the PUF KEK.
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Tested-by: Ricardo Sa
zynqmp: platform: use HUK derived from PUF KEK for RPMB
Enable the RPMB key when the HUK is generated from the PUF KEK.
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Tested-by: Ricardo Salveti <ricardo@foundries.io> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| #
1d23b02e |
| 08-Oct-2021 |
Jorge Ramirez-Ortiz <jorge@foundries.io> |
zynqmp: drivers: generate HUK from PUF KEK
If authenticated boot was disabled we allow generating the HUK using the SHA-256 of the DNA unique identifier.
If authenticated boot was enabled, use the
zynqmp: drivers: generate HUK from PUF KEK
If authenticated boot was disabled we allow generating the HUK using the SHA-256 of the DNA unique identifier.
If authenticated boot was enabled, use the PUK KEK to generate the HUK instead. The PUF KEK must be registered while securing the board using the Xilinx tools. In this case, the HUK is generated by reading the DNA eFuses. This 96 bits value is used to generate a 16 byte digest which is then AES-GCM encrypted using the PUF KEK. The resulting 16 byte value is the HUK. To prevent the HUK from being leaked, the AES-GCM module must be reserved.
The HUK generation was validated on Zynqmp zu3cg using the Xilinx Lightweight Provisioning Tool to enable authenticated boot and to provision the PUF (burning a number of eFuses in the process).
Tested-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Tested-by: Ricardo Salveti <ricardo@foundries.io> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| #
9b61a2bc |
| 07-Oct-2021 |
Jorge Ramirez-Ortiz <jorge@foundries.io> |
zynqmp: drivers: PM firmware
These routines call TF-A exported SiP services that implement IPI protocol for communication with PMUFW (Platform Management Unit).
To access eFuses, PMUFW should be bu
zynqmp: drivers: PM firmware
These routines call TF-A exported SiP services that implement IPI protocol for communication with PMUFW (Platform Management Unit).
To access eFuses, PMUFW should be built with -DENABLE_EFUSE_ACCESS=1.
Notice however that certain eFuses will not be available unless the Xilskey library linked to the PMUFW is compiled removing some of those security restrictions.
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io> Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| #
f072eea4 |
| 04-Oct-2021 |
Jorge Ramirez-Ortiz <jorge@foundries.io> |
zynqmp: drivers: AES-GCM with PUF KEK
Provide a mechanism to encrypt a red key using the KEK; the KEK is only available on secured boards after the RSA_EN and PPK eFUSES have been burnt (the system
zynqmp: drivers: AES-GCM with PUF KEK
Provide a mechanism to encrypt a red key using the KEK; the KEK is only available on secured boards after the RSA_EN and PPK eFUSES have been burnt (the system will only boot ROM authenticated bootloaders from here on).
The main use case for OP-TEE would be to encode the zynqmp per device unique identifier (DNA0, DNA1, DNA2 eFUSEs - ie, a red key) using the KEK. The encryption key generated this way is cryptographically strong and will be used as the device HUK (ie, black key).
Test code:
csu_aes_encrypt_data(src, dst, BLOB_DATA_SIZE, tag, GCM_TAG_SIZE, iv, GCM_IV_SIZE, CSU_AES_KEY_SRC_DEV); csu_aes_decrypt_data(dst, src, BLOB_DATA_SIZE, tag, GCM_TAG_SIZE, iv, GCM_IV_SIZE, CSU_AES_KEY_SRC_DEV); if (memcmp(src, buffer, BLOB_DATA_SIZE)) { EMSG(" - encrypt/decrypt test failed");
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| #
777da538 |
| 04-Oct-2021 |
Jorge Ramirez-Ortiz <jorge@foundries.io> |
zynqmp: drivers: CSUDMA module
This module provides a mechanism to transfer data between memory and peripherals. The data path is selected in the Secure Stream Switch register in the CSU.
Signed-of
zynqmp: drivers: CSUDMA module
This module provides a mechanism to transfer data between memory and peripherals. The data path is selected in the Secure Stream Switch register in the CSU.
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| #
e4a0a852 |
| 04-Oct-2021 |
Jorge Ramirez-Ortiz <jorge@foundries.io> |
zynqmp: drivers: Physically Unclonable Function (PUF)
This block is used to generate black keys via the AES-GCM module. The PUF KEK - feeding the AES-GCM block - is also unique for each device.
The
zynqmp: drivers: Physically Unclonable Function (PUF)
This block is used to generate black keys via the AES-GCM module. The PUF KEK - feeding the AES-GCM block - is also unique for each device.
The KEK is only available once the board has been secured via programmable eFUSES (RSA_EN authentication via the PPK fuses).
Registering the PUF should be done using the Xilinx tools so the adequate eFUSES are written.
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io> Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| #
c43d7569 |
| 13-Oct-2020 |
Ricardo Salveti <ricardo@foundries.io> |
plat: zynqmp: use generic_ram_layout for defining dram layout
Switch to the generic generic_ram_layout header file for defining the default dram layout. This allow allows the user to easily customiz
plat: zynqmp: use generic_ram_layout for defining dram layout
Switch to the generic generic_ram_layout header file for defining the default dram layout. This allow allows the user to easily customize the default dram base and size via CFG_TZDRAM_START/CFG_TZDRAM_SIZE.
Default values are still the same as previously set by platform_config.
Signed-off-by: Ricardo Salveti <ricardo@foundries.io> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
ae2b65fc |
| 08-Oct-2020 |
Ricardo Salveti <ricardo@foundries.io> |
plat: zynqmp: force disable core ALSR
Disable core ASLR for two reasons: 1. There is no source for ALSR seed, as ATF does not provide a DTB to OP-TEE. Hardware RNG is also not currently supported
plat: zynqmp: force disable core ALSR
Disable core ASLR for two reasons: 1. There is no source for ALSR seed, as ATF does not provide a DTB to OP-TEE. Hardware RNG is also not currently supported. 2. OP-TEE does not boot with enabled CFG_CORE_ASLR.
Further investigation is needed to see why enabled ASLR causes OP-TEE to not boot properly.
Signed-off-by: Ricardo Salveti <ricardo@foundries.io> Acked-by: Jerome Forissier <jerome@forissier.org>
show more ...
|
| #
f3721740 |
| 23-Jul-2020 |
Jens Wiklander <jens.wiklander@linaro.org> |
core: remove the unused PM stubs
Removes the PM stubs and all references to CFG_PM_STUBS.
Reviewed-by: Jerome Forissier <jerome@forissier.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.o
core: remove the unused PM stubs
Removes the PM stubs and all references to CFG_PM_STUBS.
Reviewed-by: Jerome Forissier <jerome@forissier.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
35e770df |
| 04-Jun-2020 |
Jerome Forissier <jerome@forissier.org> |
Move CFG_WITH_STACK_CANARIES to global config file
All platforms but one (bcm-ns3) set CFG_WITH_STACK_CANARIES ?= y in their configuration files. Move this flag to the global mk/config.mk instead. N
Move CFG_WITH_STACK_CANARIES to global config file
All platforms but one (bcm-ns3) set CFG_WITH_STACK_CANARIES ?= y in their configuration files. Move this flag to the global mk/config.mk instead. Not sure it matters much, but in order to avoid any functional change, CFG_WITH_STACK_CANARIES ?= n is added to plat-bcm/conf.mk.
Signed-off-by: Jerome Forissier <jerome@forissier.org> Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org> Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
0146c7ad |
| 07-Jun-2020 |
Jens Wiklander <jens.wiklander@linaro.org> |
core: make generic boot mandatory
The OP-TEE booting has since quite some time been unified in the sense that all platforms use CFG_GENERIC_BOOT=y. Make this configuration option mandatory and remov
core: make generic boot mandatory
The OP-TEE booting has since quite some time been unified in the sense that all platforms use CFG_GENERIC_BOOT=y. Make this configuration option mandatory and remove the CFG_GENERIC_BOOT flag.
Acked-by: Etienne Carriere <etienne.carriere@linaro.org> Acked-by: Jerome Forissier <jerome@forissier.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
9f1eec75 |
| 17-Dec-2018 |
Jerome Forissier <jerome.forissier@linaro.org> |
Factor out ta-targets from platform config
Platforms use the same basic pattern again and again:
ta-targets = ta_arm32 ifeq ($(CFG_ARM64_core),y) ta-targets += ta_arm64 endif
Let's move this p
Factor out ta-targets from platform config
Platforms use the same basic pattern again and again:
ta-targets = ta_arm32 ifeq ($(CFG_ARM64_core),y) ta-targets += ta_arm64 endif
Let's move this pattern to core/arch/arm/arm.mk, make it the default, and cleanup the platform configuration files.
Suggested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| #
9460285e |
| 04-Jun-2018 |
Jerome Forissier <jerome.forissier@linaro.org> |
plat-*/conf.mk: use $(call force, ...) to set CFG_TEE_CORE_NB_CORE
Except for very special cases (such as virtualization), the number of CPU cores that can enter OP-TEE is a fixed number that depend
plat-*/conf.mk: use $(call force, ...) to set CFG_TEE_CORE_NB_CORE
Except for very special cases (such as virtualization), the number of CPU cores that can enter OP-TEE is a fixed number that depends on the hardware configuration and should not be configurable at build time. Therefore, use $(call force,CFG_TEE_CORE_NB_CORE,<value>) to set the value.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
29e7629e |
| 03-May-2018 |
Etienne Carriere <etienne.carriere@linaro.org> |
core: move CFG_TEE_CORE_NB_CORE to conf.mk for various platforms
Update platforms d02, rcar, sam, hikey, mediatek, poplar, rpi3, sprd, zynqmp and marvell.
These platforms no more defines CFG_ confi
core: move CFG_TEE_CORE_NB_CORE to conf.mk for various platforms
Update platforms d02, rcar, sam, hikey, mediatek, poplar, rpi3, sprd, zynqmp and marvell.
These platforms no more defines CFG_ configuration directives as NB_CORE was the last remaining one.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Acked-by: Joakim Bech <joakim.bech@linaro.org>
show more ...
|
| #
c9add4ac |
| 23-Nov-2017 |
Jerome Forissier <jerome.forissier@linaro.org> |
core: arm32: enable NEON with .fpu directive rather than compile flag
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (QEMU CF
core: arm32: enable NEON with .fpu directive rather than compile flag
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (QEMU CFG_WITH_VFP=y) Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey960 AArch32 {,pager}) Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
cd11e1cb |
| 23-Nov-2017 |
Jerome Forissier <jerome.forissier@linaro.org> |
Use -mfpu-neon for assembly files in TEE core only
Some platforms set arm32-platform-aflags += -mfpu-neon, which causes NEON to be selected when building any assembly files. TEE core, user-mode libr
Use -mfpu-neon for assembly files in TEE core only
Some platforms set arm32-platform-aflags += -mfpu-neon, which causes NEON to be selected when building any assembly files. TEE core, user-mode libraries and TAs are all affected by this setting.
This is most likely incorrect because user-mode libraries do not use NEON instructions (only some core files do). And, it does not make much sense to set it by default for TAs either.
So, core_arm32-platform-aflags should be set instead.
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| #
43896851 |
| 23-May-2017 |
Etienne Carriere <etienne.carriere@linaro.org> |
core: factorize cpu support
Create core/arch/arm/cpu/<cpu-name>.mk to store CPU generic configurations settings. Update supported platforms to rely on the generic CPU support.
Platform shall still
core: factorize cpu support
Create core/arch/arm/cpu/<cpu-name>.mk to store CPU generic configurations settings. Update supported platforms to rely on the generic CPU support.
Platform shall still specify whether they support or not the NEON extension.
Cortex-A53 and Cortex-A57 are all ARMv8.0 compliant. For ARMv8 core, we will use ARMv8-A architecture minor version configuration files.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
show more ...
|