Merge "feat(rpi5): add PCI SMCCC support" into integration

Merge changes Id72a0370,I2bafba38,I2bd48441,I164c579c,Iddf8aea0, ... into integration

* changes:
feat(rpi): add Raspberry Pi 5 support
fix(rpi): consider MT when calculating core index from MPID

Merge changes Id72a0370,I2bafba38,I2bd48441,I164c579c,Iddf8aea0, ... into integration

* changes:
feat(rpi): add Raspberry Pi 5 support
fix(rpi): consider MT when calculating core index from MPIDR
refactor(rpi): move register definitions out of rpi_hw.h
refactor(rpi): add platform macro for the crash UART base address
refactor(rpi): split out console registration logic
refactor(rpi): move more platform-specific code into common

show more ...

feat(rpi5): add PCI SMCCC support

BCM2712 changes:
- support all 3 PCIe RCs / segments.
- don't check for link up: the RC can now be configured to fabricate
all-ones AXI OKAY responses, so no mo

feat(rpi5): add PCI SMCCC support

BCM2712 changes:
- support all 3 PCIe RCs / segments.
- don't check for link up: the RC can now be configured to fabricate
all-ones AXI OKAY responses, so no more Arm SErrors when the link is
down (or other conditions).

Also, limit bus 0 to devfn 0 as accesses beyond that may result in
lock-ups.

Change-Id: Ic64785cd68b22571c6638fc3f771703113bc76f6
Signed-off-by: Mario Bălănică <mariobalanica02@gmail.com>

show more ...

refactor(rpi): move register definitions out of rpi_hw.h

Change-Id: I2bd48441359468efb9e94fd2fffb079683f7a7fd
Signed-off-by: Mario Bălănică <mariobalanica02@gmail.com>

Merge "rpi4: update the iobase constant" into integration

rpi4: update the iobase constant

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 separat

rpi4: update the iobase constant

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

show more ...

Merge changes from topic "rpix-multi-console" into integration

* changes:
rpi: docs: Update maintainers file to new RPi directory scheme
rpi: console: Autodetect Mini-UART vs. PL011 configuratio

Merge changes from topic "rpix-multi-console" into integration

* changes:
rpi: docs: Update maintainers file to new RPi directory scheme
rpi: console: Autodetect Mini-UART vs. PL011 configuration
rpi3: build: Include GPIO driver in all BL stages
rpi: Allow using PL011 UART for RPi3/RPi4
rpi3: console: Use same "clock-less" setup scheme as RPi4
rpi3: gpio: Simplify GPIO setup

show more ...

rpi: Allow using PL011 UART for RPi3/RPi4

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 usuall

rpi: Allow using PL011 UART for RPi3/RPi4

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

show more ...

rpi3: console: Use same "clock-less" setup scheme as RPi4

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. T

rpi3: console: Use same "clock-less" setup scheme as RPi4

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

show more ...

Merge "plat: rpi4: Skip UART initialisation" into integration

plat: rpi4: Skip UART initialisation

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

plat: rpi4: Skip UART initialisation

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

show more ...

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 ...

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 ...