| 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 ...
|
| 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 ...
|
| 1a7422eb | 15-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
rpi4: Add stdout-path to device tree
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 loca
rpi4: Add stdout-path to device tree
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>
show more ...
|
| 3903a8cd | 21-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
rpi4: Add GIC maintenance interrupt to GIC DT node
For being able to use the virtualisation support the GIC offers, we need to know the interrupt number of the maintenance interrupt. This informatio
rpi4: Add GIC maintenance interrupt to GIC DT node
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>
show more ...
|
| 882c0ff6 | 15-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
rpi4: Cleanup memory regions, move pens to first page
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
rpi4: Cleanup memory regions, move pens to first page
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>
show more ...
|
| 2b19e2f3 | 21-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
rpi4: Reserve resident BL31 region from non-secure world
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 pe
rpi4: Reserve resident BL31 region from non-secure world
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>
show more ...
|
| f67fa69c | 11-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
rpi4: Amend DTB to advertise PSCI
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 service
rpi4: Amend DTB to advertise PSCI
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>
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 ...
|
| c4597e13 | 10-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
rpi4: Accommodate "armstub8.bin" header at the beginning of BL31 image
The Raspberry Pi GPU firmware checks for a magic value at offset 240 (0xf0) of the armstub8.bin image it loads. If that value m
rpi4: Accommodate "armstub8.bin" header at the beginning of BL31 image
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>
show more ...
|
| f5cb15b0 | 09-Jul-2019 |
Andre Przywara <andre.przywara@arm.com> |
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 ...
|
| 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 ...
|
| 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 ...
|
| 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 ...
|