- 25 Sep, 2019 6 commits
-
-
Andre Przywara authored
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>
-
Andre Przywara authored
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 authored
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 authored
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 authored
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 authored
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:
-
- 13 Sep, 2019 9 commits
-
-
Andre Przywara authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
