GitLab

The rpi4 has a single nonstandard ECAM. It is broken
into two pieces, the root port registers, and a window
to a single device's config space which can be moved
between devices. Now that we have widened the page
tables/MMIO window, we can create a read/write acces
functions that are called by the SMCCC/PCI API.

As an example platform, the rpi4 single device ECAM
region quirk is pretty straightforward. The assumption
here is that a lower level (uefi) has configured and
initialized the PCI root to match the values we are
using here.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Change-Id: Ie1ffa8fe9aa1d3c62e6aa84746a949c1009162e0

The PCIe root port is outside of the current RPi
MMIO regions, so we need to adjust the address map.
Given much of the code depends on the legacy IOBASE
lets separate that from the actual MMIO begin/end.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Change-Id: Id65460ae58556bd8826dba08bbad79953e2a7c0b

Addresses the deprecation warning produced by
drivers/arm/gic/common/gic_common.c.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Change-Id: I1a3ff4835d0f94c74b405db10622e99875ded82b

And from crash_console_flush.

We ignore the error information return by console_flush in _every_
place where we call it, and casting the return type to void does not
work around the MISRA violation that this causes. Instead, we collect
the error information from the driver (to avoid changing that API), and
don't return it to the caller.

Change-Id: I1e35afe01764d5c8f0efd04f8949d333ffb688c1
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>

Coverity build periodically throws below errors(non-consistently)
for 'QEMU' and 'RPI3' platforms.

/bin/sh: 1: cannot create build/qemu/debug/rot_key.pem: Directory
nonexistent
plat/qemu/qemu/platform.mk:86: recipe for target 'build/qemu/debug/
rot_key.pem' failed
make: *** [build/qemu/debug/rot_key.pem] Error 2

/bin/sh: 1: cannot create /work/workspace/workspace/tf-coverity/build
/rpi3/debug/rot_key.pem: Directory nonexistent
plat/rpi/rpi3/platform.mk:214: recipe for target '/work/workspace/
workspace/tf-coverity/build/rpi3/debug/rot_key.pem' failed
make: *** [/work/workspace/workspace/tf-coverity/build/rpi3/debug/
rot_key.pem] Error 2

Issue seems to be occurred when 'ROT key' is generated before creating
the platform build folder(for e.g.build/qemu/debug).

Changes are made to fix this issue by adding orderly dependancy of
the platform folder for the 'ROT key' creation which ensures that
platform folder is created before generating 'ROT key'.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I20c82172dde84e4c7f2373c0bd095d353f845d38

Getting the actual size of a DTB blob is useful beyond the Raspberry Pi
port, so let's move this helper to a common header.

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

CoT used for BL1 and BL2 are moved to tbbr_cot_bl1.c
and tbbr_cot_bl2.c respectively.
Common CoT used across BL1 and BL2 are moved to
tbbr_cot_common.c.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I2252ac8a6960b3431bcaafdb3ea4fb2d01b79cf5

We simulate the PSCI CPU_OFF operation by reseting the core via RMR.
For secondaries, that already puts them in the holding pen waiting for a
"warm boot" request as part of PSCI CPU_ON. For the BSP, we have to add
logic to distinguish a regular boot from a CPU_OFF state, where, like the
secondaries, the BSP needs to wait foor a "warm boot" request as part
of CPU_ON.

Testing done:

- ACS suite now passes more tests (since it repeatedly
calls code on secondaries via CPU_ON).

- Linux testing including offlining/onlineing CPU0, e.g.
"echo 0 > /sys/devices/system/cpu/cpu0/online".

Change-Id: Id0ae11a0ee0721b20fa2578b54dadc72dcbd69e0
Link: https://developer.trustedfirmware.org/T686

Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
[Andre: adapt to unified plat_helpers.S, smaller fixes]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

When writing to arbitrary locations in memory using a constructed
pointer, there is no guarantee that the compiler does not optimise away
the access, since it cannot detect any dependency.

One typical solution is to use the "volatile" keyword, but using MMIO
accessors in usually the better answer, to avoid torn writes.

Replace the usage of an array with such an MMIO accessor function in
rpi3_pwr_domain_on(), to make sure the write is really happening.

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

The plat_helpers.S file was almost identical between its RPi3 and RPi4
versions. Unify the two files, moving it into the common/ directory.

This adds a plat_rpi_get_model() function, which can be used to trigger
RPi4 specific action, detected at runtime. We use that to do the RPi4
specific L2 cache initialisation.

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

The Raspberry Pi has two different UART devices pin-muxed to GPIO 14&15:
One ARM PL011 one and the 8250 compatible "Mini-UART".
A dtoverlay parameter in config.txt will tell the firmware to switch
between the two: it will setup the right clocks and will configure the
pinmuxes accordingly.

To autodetect the user's choice, we read the pinmux register and check
its setting: ALT5 (0x2) means the Mini-UART is used, ALT0 (0x4) points
to the PL011.
Based on that we select the UART driver to initialise.

This will allow console output in any case.

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

So far the Raspberry Pi 3 build needs the GPIO driver just for BL2.
Upcoming changes will require some GPIO code in BL1 and BL31 also, so
move those driver files into the common source section.

This does not affect BL31 code size at all, and bl1.bin just increases
by 144 bytes, but doesn't affect the padded binary size at all.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Change-Id: I7639746dc241c1e69099d85d2671c65fa0108555

The Broadcom 283x SoCs feature multiple UARTs: the mostly used
"Mini-UART", which is an 8250 compatible IP, and at least one PL011.
While the 8250 is usually used for serial console purposes, it suffers
from a design flaw, where its clock depends on the VPU clock, which can
change at runtime. This will reliably mess up the baud rate.
To avoid this problem, people might choose to use the PL011 UART for
the serial console, which is pin-mux'ed to the very same GPIO pins.
This can be done by adding "miniuart-bt" to the "dtoverlay=" line in
config.txt.

To prepare for this situation, use the newly gained freedom of sharing
one console_t pointer across different UART drivers, to introduce the
option of choosing the PL011 for the console.

This is for now hard-coded to choose the Mini-UART by default.
A follow-up patch will introduce automatic detection.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Change-Id: I8cf2522151e09ff4ff94a6d396aec6fc4b091a05

In the wake of the upcoming unification of the console setup code
between RPi3 and RPi4, extend the "clock-less" setup scheme to the
RPi3. This avoid programming any clocks or baud rate registers,
which makes the port more robust against GPU firmware changes.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Change-Id: Ida83a963bb18a878997e9cbd55f8ceac6a2e1c1f

There is really no reason to use and pass around a struct when its only
member is the (fixed) base address.

Remove the struct and just use the base address on its own inside the
GPIO driver. Then set the base address automatically.

This simplifies GPIO setup for users, which now don't need to deal with
zeroing a struct and setting the base address anymore.

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

Since now the generic console_t structure holds the UART base address as
well, let's use that generic location and drop the UART driver specific
data structure at all.

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

So far we have seen two different clock setups for the Raspberry Pi 4
board, with the VPU clock divider being different. This was handled by
reading the divider register and adjusting the base clock rate
accordingly.
Recently a new GPU firmware version appeared that changed the clock rate
*again*, though this time at a higher level, so the VPU rate (and the
apparent PLLC parent clock) did not seem to change, judging by reading
the clock registers.
So rather than playing cat and mouse with the GPU firmware or going
further down the rabbit hole of exploring the whole clock tree, let's
just skip the baud rate programming altogether. This works because the
GPU firmware actually sets up and programs the debug UART already, so
we can just use it.

Pass 0 as the base clock rate to let the console driver skip the setup,
also remove the no longer needed clock code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Change-Id: Ica88a3f3c9c11059357c1e6dd8f7a4d9b1f98fd7

The hooks were populated but the power down left the CPU in limbo-land.
What we need to do - until there is a way to actually power off - is to
turn off the MMU and enter the spinning loop as if we were cold-booted.
This allows the on-call to pick up the CPU again.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Change-Id: Iefc7a58424e3578ad3dd355a7bd6eaba4b412699

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

With the advent of Raspberry Pi 4 support, we need to separate some
board specific headers between the RPi3 and RPi4.
Rename and move the "rpi3_hw.h" header, so that .c files just include
rpi_hw.h, and automatically get the correct version.

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

The location of the MMIO window is different between a Raspberry Pi 3
and 4: the former has it just below 1GB, the latter below 4GB.
The relative location of the peripherals is mostly compatible though.

To allow sharing code between the two models, let's rename the symbol
used for the MMIO base to the more generic RPI_IO_BASE name.

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

To be able to share code more easily between the existing Raspberry Pi 3
and the upcoming Raspberry Pi 4 platform, move some code which is not
board specific into a "common" directory.

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