- 25 Sep, 2019 2 commits
-
-
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 <andre.przywara@arm.com>
-
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 <andre.przywara@arm.com>
-