History log of /optee_os/core/arch/arm/plat-zynqmp/conf.mk (Results 1 – 25 of 30)
Revision Date Author Comments
# 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 ...


12