| 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 ...
|
| 29e8c460 | 11-Mar-2020 |
Andre Przywara <andre.przywara@arm.com> |
rpi3: build: Include GPIO driver in all BL stages
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
rpi3: build: Include GPIO driver in all BL stages
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
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 ...
|
| 795aefe5 | 10-Mar-2020 |
Andre Przywara <andre.przywara@arm.com> |
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 ...
|
| 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 ...
|
| dcf6d4f8 | 15-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
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,
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>
show more ...
|
| 110fd1fe | 09-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
rpi3: Rename RPI3_IO_BASE to RPI_IO_BASE
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
rpi3: Rename RPI3_IO_BASE to RPI_IO_BASE
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>
show more ...
|
| 990ab78e | 09-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
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: Iae94d7cb22c6bce3af9bff
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>
show more ...
|
| c0031189 | 09-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
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: I463e49acf82
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>
show more ...
|
| 4666d046 | 09-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
rpi3: Move rpi3_hw.h header file to include/rpi_hw.h
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_h
rpi3: Move rpi3_hw.h header file to include/rpi_hw.h
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>
show more ...
|