| 1c800903 | 05-Nov-2024 |
Abhi Singh <abhi.singh@arm.com> |
refactor(rpi3): move mbedtls helper to common code
In order to support measured boot we need plat_get_mbedtls_heap,
this function currently resides in rpi3_trusted_boot.c, but we do
not need trusted
refactor(rpi3): move mbedtls helper to common code
In order to support measured boot we need plat_get_mbedtls_heap,
this function currently resides in rpi3_trusted_boot.c, but we do
not need trusted board boot to use measured boot, so moving this
to common code removes the need to compile rpi3_trusted_boot.c
Change-Id: I6ac6dfa8c540e456d7cb6932098c921907ad086a
Signed-off-by: Tushar Khandelwal <tushar.khandelwal@arm.com>
Signed-off-by: Abhi Singh <abhi.singh@arm.com>
show more ...
|
| 682607fb | 06-Mar-2024 |
Mario Bălănică <mariobalanica02@gmail.com> |
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 ...
|
| 6744d07d | 01-Dec-2023 |
Mario Bălănică <mariobalanica02@gmail.com> |
fix(rpi): consider MT when calculating core index from MPIDR
RPi 5 has newer Armv8.2 cores where the MT bit is set to indicate that
the lowest affinity level represents a thread, but there is only o
fix(rpi): consider MT when calculating core index from MPIDR
RPi 5 has newer Armv8.2 cores where the MT bit is set to indicate that
the lowest affinity level represents a thread, but there is only one
thread per core.
To deal with this, simply right shift MPIDR by one affinity level to get
the cluster and core IDs back into Aff1 and Aff0 as expected.
Change-Id: I2bafba38f82fd9a6ef6f2fdf2c089b754279a6de
Signed-off-by: Mario Bălănică <mariobalanica02@gmail.com>
show more ...
|
| 2e5f8443 | 12-Mar-2020 |
Andrei Warkentin <andrey.warkentin@gmail.com> |
rpi: Implement PSCI CPU_OFF
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
rpi: Implement PSCI CPU_OFF
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>
show more ...
|
| af2a4877 | 21-Mar-2020 |
Andre Przywara <andre.przywara@arm.com> |
rpi: rpi3_pwr_domain_on(): Use MMIO accessor
When writing to arbitrary locations in memory using a constructed
pointer, there is no guarantee that the compiler does not optimise away
the access, sin
rpi: rpi3_pwr_domain_on(): Use MMIO accessor
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>
show more ...
|
| 9cc3fa1b | 11-Mar-2020 |
Andre Przywara <andre.przywara@arm.com> |
rpi: console: Autodetect Mini-UART vs. PL011 configuration
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
rpi: console: Autodetect Mini-UART vs. PL011 configuration
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>
show more ...
|
| 5e6d821c | 10-Mar-2020 |
Andre Przywara <andre.przywara@arm.com> |
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 ...
|
| 448fb352 | 11-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
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 ...
|
| e6fd00ab | 15-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
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 w
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>
show more ...
|
| a95e6415 | 15-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
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
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>
show more ...
|