- 30 Dec, 2019 1 commit
-
-
Andre Przywara authored
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
-
- 25 Sep, 2019 8 commits
-
-
Andre Przywara authored
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 authored
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 authored
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 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 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:
-
