Merge changes from topic "ld/stm32-authentication" into integration

* changes:
stm32mp1: add authentication support for stm32image
bsec: move bsec_mode_is_closed_device() service to platform
c

Merge changes from topic "ld/stm32-authentication" into integration

* changes:
stm32mp1: add authentication support for stm32image
bsec: move bsec_mode_is_closed_device() service to platform
crypto: stm32_hash: Add HASH driver

show more ...

Merge changes from topic "amlogic-g12a" into integration

* changes:
amlogic: g12a: Add support for the S905X2 (G12A) platform
amlogic: makefile: Use PLAT variable when possible
amlogic: sha_dm

Merge changes from topic "amlogic-g12a" into integration

* changes:
amlogic: g12a: Add support for the S905X2 (G12A) platform
amlogic: makefile: Use PLAT variable when possible
amlogic: sha_dma: Move register mappings to platform header

show more ...

Merge changes from topic "a5ds-multicore" into integration

* changes:
a5ds: add multicore support
a5ds: Hold the secondary cpus in pen rather than panic

Merge changes from topic "raspberry-pi-4-support" into integration

* changes:
rpi4: Add initial documentation file
rpi4: Add stdout-path to device tree
rpi4: Add GIC maintenance interrupt to G

Merge changes from topic "raspberry-pi-4-support" into integration

* changes:
rpi4: Add initial documentation file
rpi4: Add stdout-path to device tree
rpi4: Add GIC maintenance interrupt to GIC DT node
rpi4: Cleanup memory regions, move pens to first page
rpi4: Reserve resident BL31 region from non-secure world
rpi4: Amend DTB to advertise PSCI
rpi4: Determine BL33 entry point at runtime
rpi4: Accommodate "armstub8.bin" header at the beginning of BL31 image
Add basic support for Raspberry Pi 4
rpi3: Allow runtime determination of UART base clock rate
FDT helper functions: Respect architecture in PSCI function IDs
FDT helper functions: Add function documentation

show more ...

Merge changes from topic "mp/giv3-discovery" into integration

* changes:
Migrate ARM platforms to use the new GICv3 API
Adding new optional PSCI hook pwr_domain_on_finish_late
GICv3: Enable mu

Merge changes from topic "mp/giv3-discovery" into integration

* changes:
Migrate ARM platforms to use the new GICv3 API
Adding new optional PSCI hook pwr_domain_on_finish_late
GICv3: Enable multi socket GIC redistributor frame discovery

show more ...

Merge changes I0283fc2e,Ib476d024,Iada05f7c into integration

* changes:
hikey: fix to load FIP by partition table.
hikey960: fix to load FIP by partition table
drivers: partition: support diff

Merge changes I0283fc2e,Ib476d024,Iada05f7c into integration

* changes:
hikey: fix to load FIP by partition table.
hikey960: fix to load FIP by partition table
drivers: partition: support different block size

show more ...

amlogic: g12a: Add support for the S905X2 (G12A) platform

Introduce the preliminary support for the Amlogic S905X2 (G12A) SoC.

This port is a minimal implementation of BL31 capable of booting
mainl

amlogic: g12a: Add support for the S905X2 (G12A) platform

Introduce the preliminary support for the Amlogic S905X2 (G12A) SoC.

This port is a minimal implementation of BL31 capable of booting
mainline U-Boot and Linux. Tested on a SEI510 board.

Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Change-Id: Ife958f10e815a4530292c45446adb71239f3367f

show more ...

Migrate ARM platforms to use the new GICv3 API

This patch invokes the new function gicv3_rdistif_probe() in the
ARM platform specific gicv3 driver. Since this API modifies the
shared GIC related dat

Migrate ARM platforms to use the new GICv3 API

This patch invokes the new function gicv3_rdistif_probe() in the
ARM platform specific gicv3 driver. Since this API modifies the
shared GIC related data structure, it must be invoked coherently
by using the platform specific pwr_domain_on_finish_late hook.

Change-Id: I6efb17d5da61545a1c5a6641b8f58472b31e62a8
Signed-off-by: Madhukar Pappireddy <madhukar.pappireddy@arm.com>

show more ...

Merge "FVP: Fix plat_set_nv_ctr() function" into integration

rpi4: Add stdout-path to device tree

Some device tree users like to find a pointer to the standard serial
console in the device tree, in the "stdout-path" property of the /chosen
node.

Add the loca

rpi4: Add stdout-path to device tree

Some device tree users like to find a pointer to the standard serial
console in the device tree, in the "stdout-path" property of the /chosen
node.

Add the location of the Mini UART in that property, so that DT users are
happy, for instance Linux' earlycon detection.

Change-Id: I178e55016e5640de5ab0bc6e061944bd3583ea96
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

rpi4: Add GIC maintenance interrupt to GIC DT node

For being able to use the virtualisation support the GIC offers, we need
to know the interrupt number of the maintenance interrupt. This
informatio

rpi4: Add GIC maintenance interrupt to GIC DT node

For being able to use the virtualisation support the GIC offers, we need
to know the interrupt number of the maintenance interrupt. This
information is missing from the official RPi4 device tree.

Use libfdt to add the "interrupts" property to the GIC node, which
allows hypervisors like KVM or Xen to be able to use the GIC's help on
virtualising interrupts.

Change-Id: Iab84f0885a5bf29fb84ca8f385e8a39d27700c75
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

rpi4: Cleanup memory regions, move pens to first page

Now that we have the SMP pens in the first page of DRAM, we can get rid
of all the fancy RPi3 memory regions that our RPi4 port does not really

rpi4: Cleanup memory regions, move pens to first page

Now that we have the SMP pens in the first page of DRAM, we can get rid
of all the fancy RPi3 memory regions that our RPi4 port does not really
need. This avoids using up memory all over the place, restricting ATF
to just run in the first 512KB of DRAM.

Remove the now unused regions. This also moves the SMP pens into our
first memory page (holding the firmware magic), where the original
firmware put them, but where there is also enough space for them.

Since the pens will require code execution privileges, we amend the
memory attributes used for that page to include write and execution
rights.

Change-Id: I131633abeb4a4d7b9057e737b9b0d163b73e47c6
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

rpi4: Reserve resident BL31 region from non-secure world

The GPU firmware loads the armstub8.bin (BL31) image at address 0, the
beginning of DRAM. As this holds the resident PSCI code and the SMP
pe

rpi4: Reserve resident BL31 region from non-secure world

The GPU firmware loads the armstub8.bin (BL31) image at address 0, the
beginning of DRAM. As this holds the resident PSCI code and the SMP
pens, the non-secure world should better know about this, to avoid
accessing memory owned by TF-A. This is particularly criticial as the
Raspberry Pi 4 does not feature a secure memory controller, so
overwriting code is a very real danger.

Use the newly introduced function to add a node into reserved-memory
node, where non-secure world can check for regions to be excluded from
its mappings.

Reserve the first 512KB of memory for now. We can refine this later if
need be.

Change-Id: I00e55e70c5c02615320d79ff35bc32b805d30770
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

rpi4: Amend DTB to advertise PSCI

The device tree provided by the official Raspberry Pi firmware uses
spin tables for SMP bringup.

One of the benefit of having TF-A is that it provides PSCI service

rpi4: Amend DTB to advertise PSCI

The device tree provided by the official Raspberry Pi firmware uses
spin tables for SMP bringup.

One of the benefit of having TF-A is that it provides PSCI services, so
let's rewrite the DTB to advertise PSCI instead of spin tables.
This uses the (newly exported) routine from the QEMU platform port.

Change-Id: Ifddcb14041ca253a333f8c2d5e97a42db152470c
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

rpi4: Determine BL33 entry point at runtime

Now that we have the armstub magic value in place, the GPU firmware will
write the kernel load address (and DTB address) into our special page,
so we can

rpi4: Determine BL33 entry point at runtime

Now that we have the armstub magic value in place, the GPU firmware will
write the kernel load address (and DTB address) into our special page,
so we can always easily access the actual location without hardcoding
any addresses into the BL31 image.

Make the compile-time defined PRELOADED_BL33_BASE macro optional, and
read the BL33 entry point from the magic location, if the macro was not
defined. We do the same for the DTB address.

This also splits the currently "common" definition of
plat_get_ns_image_entrypoint() to be separate between RPi3 and RPi4.

Change-Id: I6f26c0adc6fce2df47786b271c490928b4529abb
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

rpi4: Accommodate "armstub8.bin" header at the beginning of BL31 image

The Raspberry Pi GPU firmware checks for a magic value at offset 240
(0xf0) of the armstub8.bin image it loads. If that value m

rpi4: Accommodate "armstub8.bin" header at the beginning of BL31 image

The Raspberry Pi GPU firmware checks for a magic value at offset 240
(0xf0) of the armstub8.bin image it loads. If that value matches,
it writes the kernel load address and the DTB address into subsequent
memory locations.
We can use these addresses to avoid hardcoding these values into the BL31
image, to make it more flexible and a drop-in replacement for the
official armstub8.bin.

Reserving just 16 bytes at offset 240 of the final image file is not easily
possible, though, as this location is in the middle of the generic BL31
entry point code.
However we can prepend an extra section before the actual BL31 image, to
contain the magic and addresses. This needs to be 4KB, because the
actual BL31 entry point needs to be page aligned.

Use the platform linker script hook that the generic code provides, to
add an almost empty 4KB code block before the entry point code. The very
first word contains a branch instruction to jump over this page, into
the actual entry code.
This also gives us plenty of room for the SMP pens later.

Change-Id: I38caa5e7195fa39cbef8600933a03d86f09263d6
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

Add basic support for Raspberry Pi 4

The Raspberry Pi 4 is a single board computer with four Cortex-A72
cores. From a TF-A perspective it is quite similar to the Raspberry Pi
3, although it comes wi

Add basic support for Raspberry Pi 4

The Raspberry Pi 4 is a single board computer with four Cortex-A72
cores. From a TF-A perspective it is quite similar to the Raspberry Pi
3, although it comes with more memory (up to 4GB) and has a GIC.

This initial port though differs quite a lot from the existing rpi3
platform port, mainly due to taking a much simpler and more robust
approach to loading the non-secure payload:
The GPU firmware of the SoC, which is responsible for initial platform
setup (including DRAM initialisation), already loads the kernel, device
tree and the "armstub" into DRAM. We take advantage of this, by placing
just a BL31 component into the armstub8.bin component, which will be
executed first, in AArch64 EL3.
The non-secure payload can be a kernel or a boot loader (U-Boot or
EDK-2), disguised as the "kernel" image and loaded by the GPU firmware.

So this is just a BL31-only port, which directly drops into EL2
and executes whatever has been loaded as the "kernel" image, handing
over the DTB address in x0.

Change-Id: I636f4d1f661821566ad9e341d69ba36f6bbfb546
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

rpi3: Allow runtime determination of UART base clock rate

At the moment the UART input clock rate is hard coded at compile time.
This works as long as the GPU firmware always sets up the same rate,

rpi3: Allow runtime determination of UART base clock rate

At the moment the UART input clock rate is hard coded at compile time.
This works as long as the GPU firmware always sets up the same rate,
which does not seem to be true for the Raspberry Pi 4.

In preparation for being able to change this at runtime, add a base
clock parameter to the console setup function. This is still hardcoded
for the Raspberry Pi 3.

Change-Id: I398bc2f1e9b46f7af9a84cb0b33cbe8e78f2d900
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

FVP: Fix plat_set_nv_ctr() function

The Fast Models provide a non-volatile counter component, which is used
in the Trusted Board Boot implementation to protect against rollback
attacks.

This compon

FVP: Fix plat_set_nv_ctr() function

The Fast Models provide a non-volatile counter component, which is used
in the Trusted Board Boot implementation to protect against rollback
attacks.

This component comes in 2 versions (see [1]).

- Version 0 is the default and models a locked non-volatile counter,
whose value is fixed.

- Version 1 of the counter may be incremented in a monotonic fashion.

plat_set_nv_ctr() must cope with both versions. This is achieved by:
1) Attempting to write the new value in the counter.
2) Reading the value back.
3) If there is a mismatch, we know the counter upgrade failed.

When using version 0 of the counter, no upgrade is possible so the
function is expected to fail all the time. However, the code is
missing a compiler barrier between the write operation and the next
read. Thus, the compiler may optimize and remove the read operation on
the basis that the counter value has not changed. With the default
optimization level used in TF-A (-Os), this is what's happening.

The fix introduced in this patch marks the write and subsequent read
accesses to the counter as volatile, such that the compiler makes no
assumption about the value of the counter.

Note that the comment above plat_set_nv_ctr() was clearly stating
that when using the read-only version of the non-volatile counter,
"we expect the values in the certificates to always match the RO
values so that this function is never called". However, the fact that
the counter value was read back seems to contradict this comment, as
it is implementing a counter-measure against misuse of the
function. The comment has been reworded to avoid any confusion.

Without this patch, this bug may be demonstrated on the Base AEM FVP:
- Using version 0 of the non-volatile counter (default version).
- With certificates embedding a revision number value of 32
(compiling TF-A with TFW_NVCTR_VAL=32).

In this configuration, the non-volatile counter is tied to value 31 by
default. When BL1 loads the Trusted Boot Firmware certificate, it
notices that the two values do not match and tries to upgrade the
non-volatile counter. This write operation is expected to fail
(because the counter is locked) and the function is expected to return
an error but it succeeds instead.

As a result, the trusted boot does not abort as soon as it should and
incorrectly boots BL2. The boot is finally aborted when BL2 verifies
the BL31 image and figures out that the version of the SoC Firmware
Key Certificate does not match. On Arm platforms, only certificates
signed with the Root-of-Trust Key may trigger an upgrade of the
non-volatile Trusted counter.

[1] https://developer.arm.com/docs/100964/1160/fast-models-components/peripheral-components/nonvolatilecounter

Change-Id: I9979f29c23b47b338b9b484013d1fb86c59db92f
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

show more ...

a5ds: add multicore support

Enable cores 1-3 using psci. On receiving the smc call from kernel,
core 0 will bring the secondary cores out pen and signal an event for
the cores. Currently on switchin

a5ds: add multicore support

Enable cores 1-3 using psci. On receiving the smc call from kernel,
core 0 will bring the secondary cores out pen and signal an event for
the cores. Currently on switching the cores is enabled i.e. it is not
possible to suspend, switch cores off, etc.

Change-Id: I6087e1d2ec650e1d587fd543efc1b08cbb50ae5f
Signed-off-by: Usama Arif <usama.arif@arm.com>

show more ...

a5ds: Hold the secondary cpus in pen rather than panic

For the secondary CPUs, hold the cpu in wfe rather then panic.
This will be needed when multicore support is added to a5ds as
the smc call will

a5ds: Hold the secondary cpus in pen rather than panic

For the secondary CPUs, hold the cpu in wfe rather then panic.
This will be needed when multicore support is added to a5ds as
the smc call will write to the hold base and signal an event to
power on the secondary CPUs.

Change-Id: I0ffc2059e9ef894c21375ca5c94def859bfa6599
Signed-off-by: Usama Arif <usama.arif@arm.com>

show more ...

Merge changes I66dc6855,I2217a1ad into integration

* changes:
rockchip: Update BL31_BASE to 0x40000
rockchip: Fix typo for TF content text

stm32mp1: add authentication support for stm32image

This commit adds authentication binary support for STM32MP1.
It prints the bootrom authentication result if signed
image is used and authenticates

stm32mp1: add authentication support for stm32image

This commit adds authentication binary support for STM32MP1.
It prints the bootrom authentication result if signed
image is used and authenticates the next loaded STM32 images.
It also enables the dynamic translation table support
(PLAT_XLAT_TABLES_DYNAMIC) to use bootrom services.

Signed-off-by: Lionel Debieve <lionel.debieve@st.com>
Change-Id: Iba706519e0dc6b6fae1f3dd498383351f0f75f51

show more ...

bsec: move bsec_mode_is_closed_device() service to platform

This BSEC service is a platform specific service. Implementation
moved to the platform part.

Signed-off-by: Lionel Debieve <lionel.debiev

bsec: move bsec_mode_is_closed_device() service to platform

This BSEC service is a platform specific service. Implementation
moved to the platform part.

Signed-off-by: Lionel Debieve <lionel.debieve@st.com>
Change-Id: I1f70ed48a446860498ed111acce01187568538c9

show more ...

rockchip: Update BL31_BASE to 0x40000

Rockchip platform is using the first 1MB of DRAM as secure ram space,
and there is a vendor loader who loads and runs the BL31/BL32/BL33,
this loader is usually

rockchip: Update BL31_BASE to 0x40000

Rockchip platform is using the first 1MB of DRAM as secure ram space,
and there is a vendor loader who loads and runs the BL31/BL32/BL33,
this loader is usually load by SoC BootRom to the start addres of DRAM,
we need to reserve enough space for this loader so that it doesn't need
to do the relocate when loading the BL31. eg.
We use U-Boot SPL to load ATF BL31 and U-Boot proper as BL33, the SPL
TEXT BASE is offset 0 of DRAM which is decide by Bootrom; if we update
the BL31_BASE to offset 0x40000(256KB), then the 0~0x40000 should be
enough for SPL and no need to do the relocate while the space size
0x10000(64KB) may not enough for SPL.
After this update, the BL31 can use the rest 768KB of the first 1MB,
which is also enough, and the loader who is using BL31 elf file can
support this update without any change.

Change-Id: I66dc685594d77f10f9a49c3be015fd6729250ece
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>

show more ...