2019-09-26 |
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
Paul Beesley
authored
on 26 Sep 2019
TrustedFirmware Code Review
committed
on 26 Sep 2019
|
2019-09-25 |
Merge "FVP: Fix plat_set_nv_ctr() function" into integration
Paul Beesley
authored
on 25 Sep 2019
TrustedFirmware Code Review
committed
on 25 Sep 2019
|
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>
Sandrine Bailleux
committed
on 25 Sep 2019
|
2019-09-23 |
Merge changes I66dc6855,I2217a1ad into integration
...
* changes:
rockchip: Update BL31_BASE to 0x40000
rockchip: Fix typo for TF content text
Sandrine Bailleux
authored
on 23 Sep 2019
TrustedFirmware Code Review
committed
on 23 Sep 2019
|
2019-09-19 |
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>
Kever Yang
committed
on 19 Sep 2019
|
rockchip: Fix typo for TF content text
...
The 'txet' should be 'text'.
Change-Id: I2217a1adf50c3b86f3087b83c77d9291b280627c
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Kever Yang
committed
on 19 Sep 2019
|
2019-09-18 |
Merge "amlogic: scpi: Add support to retrieve chip ID" into integration
Sandrine Bailleux
authored
on 18 Sep 2019
TrustedFirmware Code Review
committed
on 18 Sep 2019
|
Merge changes I93ecff4d,I30dd9a95,I8207eea9,Id4197b07,Ib810125b, ... into integration
...
* changes:
mediatek: mt8183: add MTK MCDI driver
mediatek: mt8183: add MTK SSPM driver
mediatek: mt8183: add MTK SPM driver
mediatek: mt8183: add MTK uart driver for controlling clock gate
mediatek: mt8183: configure MCUSYS DCM
mediatek: mt8173: refactor RTC and PMIC drivers
Sandrine Bailleux
authored
on 18 Sep 2019
TrustedFirmware Code Review
committed
on 18 Sep 2019
|
qemu: Simplify the image size calculation
...
Patch introduce the macro NS_IMAGE_MAX_SIZE to simplify the image size
calculation. Use of additional parenthesis removes the possibility of
improper calculations due nested macro expansion for subtraction.
In case of platforms with DRAM window over 32bits, patch also removes
potential problems with type casting, as meminfo.image_size is uint32_t
but macro calculations were done in 64bit space.
Signed-off-by: Radoslaw Biernacki <radoslaw.biernacki@linaro.org>
Change-Id: I2d05a2d9dd6000dba6114df53262995cf85af018
Radoslaw Biernacki
authored
on 17 May 2018
Sandrine Bailleux
committed
on 18 Sep 2019
|
qemu: introducing sub-platforms to qemu platform
...
This commit change the plat/qemu directory structure into:
`-- plat
`-- qemu
|-- common (files shared with all qemu subplatforms)
|-- qemu (original qemu platform)
|-- qemu_sbsa (new sqemu_sbsa platform)
|-- subplat1
`-- subplat2
This opens the possibility of adding new qemu sub-platforms which reuse
existing common platform code. The first platform which will leverage new
structure will be SBSA platform.
Signed-off-by: Radoslaw Biernacki <radoslaw.biernacki@linaro.org>
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: Id0d8133e1fffc1b574b69aa2770ebc02bb837a9b
Radoslaw Biernacki
authored
on 17 May 2018
Sandrine Bailleux
committed
on 18 Sep 2019
|
hikey: fix to load FIP by partition table.
...
Avoid to load FIP by hacking address. Load it by partition table instead.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Change-Id: I0283fc2e6e459bff14de19d92db4158e05106ee4
Haojian Zhuang
committed
on 18 Sep 2019
|
hikey960: fix to load FIP by partition table
...
Avoid to load FIP by hacking address. Load it by partition table instead.
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Change-Id: Ib476d024a51e4b9705441a0007d78f9fdf0ca078
Haojian Zhuang
committed
on 18 Sep 2019
|
2019-09-17 |
amlogic: scpi: Add support to retrieve chip ID
...
Both kernel and U-Boot use a SMC call to the secure monitor to get the
chip ID. This call is translated by BL31 to a call to the SCP to
retrieve the ID. Add a new SiP call and the backing SCPI command.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Change-Id: Ib128f5645ee92866e7ebbcd550dacd33f573524b
Carlo Caione
committed
on 17 Sep 2019
|
2019-09-16 |
Merge changes from topic "raspberry-pi-4-support" into integration
...
* changes:
rpi3: Do prescaler and control setup in C
rpi3: Prepare for supporting a GIC (in RPi4)
rpi3: Make SHARED_RAM optional
rpi3: Rename RPI3_IO_BASE to RPI_IO_BASE
rpi3: Move shared rpi3 files into common directory
Sandrine Bailleux
authored
on 16 Sep 2019
TrustedFirmware Code Review
committed
on 16 Sep 2019
|
Merge changes from topic "raspberry-pi-4-support" into integration
...
* changes:
Add fdt_add_reserved_memory() helper function
qemu: Move and generalise FDT PSCI fixup
Sandrine Bailleux
authored
on 16 Sep 2019
TrustedFirmware Code Review
committed
on 16 Sep 2019
|
Merge changes from topic "raspberry-pi-4-support" into integration
...
* changes:
rpi3: Move rng driver to drivers
rpi3: Move VC mailbox driver into generic drivers directory
rpi3: Move rpi3_hw.h header file to include/rpi_hw.h
Sandrine Bailleux
authored
on 16 Sep 2019
TrustedFirmware Code Review
committed
on 16 Sep 2019
|
Merge "rpi3: Add "rpi" platform directory" into integration
Sandrine Bailleux
authored
on 16 Sep 2019
TrustedFirmware Code Review
committed
on 16 Sep 2019
|
2019-09-15 |
mediatek: mt8183: add MTK MCDI driver
...
Add MCDI driver for power saving.
Signed-off-by: kenny liang <kenny.liang@mediatek.com>
Change-Id: I93ecff4d7581f678be09dd8fb5dfaaccd5f2c22c
kenny liang
committed
on 15 Sep 2019
|
mediatek: mt8183: add MTK SSPM driver
...
Add MTK SSPM driver.
Signed-off-by: kenny liang <kenny.liang@mediatek.com>
Change-Id: I30dd9a95456b8c3c8d18fd22120824eec97634ee
kenny liang
committed
on 15 Sep 2019
|
mediatek: mt8183: add MTK SPM driver
...
Add MTK SPM driver for suspend/resume scenario.
Signed-off-by: kenny liang <kenny.liang@mediatek.com>
Change-Id: I8207eea95914da9e63c62f3afc8329f3ccd9a22c
kenny liang
committed
on 15 Sep 2019
|
mediatek: mt8183: add MTK uart driver for controlling clock gate
...
Add uart clock gate contol for suspend/resume scenario.
Signed-off-by: kenny liang <kenny.liang@mediatek.com>
Change-Id: Id4197b0720630ec6c74aec206a9b206511bf515a
kenny liang
committed
on 15 Sep 2019
|
mediatek: mt8183: configure MCUSYS DCM
...
Configure MCUSYS DCM.
Signed-off-by: kenny liang <kenny.liang@mediatek.com>
Change-Id: Ib810125b514cbcc43c770377bc71a29a05a19320
kenny liang
committed
on 15 Sep 2019
|
mediatek: mt8173: refactor RTC and PMIC drivers
...
Refactor RTC and PMIC drivers.
Signed-off-by: kenny liang <kenny.liang@mediatek.com>
Change-Id: I74fca536cd61e00c962f080f1ba3759287682ecf
kenny liang
committed
on 15 Sep 2019
|
2019-09-13 |
rpi3: Do prescaler and control setup in C
...
To initialise the arch timer configuration and some clock prescaler, we
need to do two MMIO access *once*, early during boot.
As tempting as it may sound, plat_reset_handler() is not the right place
to do this, as it will be called on every CPU coming up, both for
secondary cores as well as during warmboots. So this access will be done
multiple times, and even during a rich OS' runtime. Whether doing so anyway
is actually harmful is hard to say, but we should definitely avoid this if
possible.
Move the initialisation of these registers to C code in
bl1_early_platform_setup(), where it will still be executed early enough
(before enabling the console), but only once during the whole boot
process.
Change-Id: I081c41a5476d424411411488ff8f633e87d3bcc5
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara
committed
on 13 Sep 2019
|
rpi3: Move rng driver to drivers
...
To allow sharing the driver between the RPi3 and RPi4, move the random
number generator driver into the generic driver directory.
Change-Id: Iae94d7cb22c6bce3af9bff709d76d4caf87b14d1
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara
committed
on 13 Sep 2019
|
rpi3: Add "rpi" platform directory
...
With the incoming support for the Raspberry Pi 4 boards, one directory
to serve both versions will not end up well.
Create an additional layer by inserting a "rpi" directory betweeen /plat
and rpi3, so that we can more easily share or separate files between the
two later.
Change-Id: I75adbb054fe7902f34db0fd5e579a55612dd8a5f
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara
committed
on 13 Sep 2019
|
rpi3: Prepare for supporting a GIC (in RPi4)
...
As the PSCI "power" management functions for the Raspberry Pi 3 port
will be shared with the upcoming RPi4 support, we need to prepare them
for dealing with the GIC interrupt controller.
Splitting this code just for those simple calls to the generic GIC
routines does not seem worthwhile, so just use a #define the protect the
GIC code from being included by the existing RPi3 code.
Change-Id: Iaca6b0214563852b28ad4a088ec45348ae8be40d
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara
committed
on 13 Sep 2019
|
qemu: Move and generalise FDT PSCI fixup
...
The QEMU platform port scans its device tree to advertise PSCI as the
CPU enable method. It does this by scanning *every* node in the DT and
check whether its compatible string starts with "arm,cortex-a". Then it
sets the enable-method to PSCI, if it doesn't already have one.
Other platforms might want to use this functionality as well, so let's
move it out of the QEMU platform directory and make it more robust by
fixing some shortcomings:
- A compatible string starting with a certain prefix is not a good way
to find the CPU nodes. For instance a "arm,cortex-a72-pmu" node will
match as well and is in turn favoured with an enable-method.
- If the DT already has an enable-method, we won't change this to PSCI.
Those two issues will for instance fail on the Raspberry Pi 4 DT.
To fix those problems, we adjust the scanning method:
The DT spec says that all CPU nodes are subnodes of the mandatory
/cpus node, which is a subnode of the root node. Also each CPU node has
to have a device_type = "cpu" property. So we find the /cpus node, then
scan for a subnode with the proper device_type, forcing the
enable-method to "psci".
We have to restart this search after a property has been patched, as the
node offsets might have changed meanwhile.
This allows this routine to be reused for the Raspberry Pi 4 later.
Change-Id: I00cae16cc923d9f8bb96a9b2a2933b9a79b06139
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara
committed
on 13 Sep 2019
|
rpi3: Move VC mailbox driver into generic drivers directory
...
To allow sharing the driver between the RPi3 and RPi4, move the mailbox
driver into the generic driver directory.
Change-Id: I463e49acf82b02bf004f3d56482b7791f3020bc0
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara
committed
on 13 Sep 2019
|
rpi3: Make SHARED_RAM optional
...
The existing Raspberry Pi 3 port sports a number of memory regions,
which are used for several purposes. The upcoming RPi4 port will not use
all of those, so make the SHARED_RAM region optional, by only mapping it
if it has actually been defined. This helps to get a cleaner RPi4 port.
Change-Id: Id69677b7fb6ed48d9f238854b610896785db8cab
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Andre Przywara
committed
on 13 Sep 2019
|