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>
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>
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>
Andre Przywara