7.36.Raspberry Pi 4

TheRaspberry Pi 4 is an inexpensive single-board computer that contains fourArm Cortex-A72 cores. Also in contrast to previous Raspberry Pi versions thismodel has a GICv2 interrupt controller.

This port is a minimal port to support loading non-secure EL2 payloads suchas a 64-bit Linux kernel. Other payloads such as U-Boot or EDK-II should workas well, but have not been tested at this point.

IMPORTANT NOTE: This port isn’t secure. All of the memory used is DRAM,which is available from both the Non-secure and Secure worlds. The SoC doesnot seem to feature a secure memory controller of any kind, so portions ofDRAM can’t be protected properly from the Non-secure world.

7.36.1.Build Instructions

There are no real configuration options at this point, so there is onlyone universal binary (bl31.bin), which can be built with:

CROSS_COMPILE=aarch64-linux-gnu-makePLAT=rpi4DEBUG=1

Copy the generated build/rpi4/debug/bl31.bin to the SD card, adding an entrystarting witharmstub=, then followed by the respective file name toconfig.txt. You should have AArch64 code in the file loaded as the“kernel”, as BL31 will drop into AArch64/EL2 to the respective load address.arm64 Linux kernels are known to work this way.

Other options that should be set inconfig.txt to properly boot 64-bitkernels are:

enable_uart=1arm_64bit=1enable_gic=1

The BL31 code will patch the provided device tree blob in memory to advertisePSCI support, also will add a reserved-memory node to the DT to tell thenon-secure payload to not touch the resident TF-A code.

If you connect a serial cable between the Mini UART and your computer, andconnect to it (for example, withscreen/dev/ttyUSB0115200) you shouldsee some text from BL31, followed by the output of the EL2 payload.The command line provided is read from thecmdline.txt file on the SD card.

7.36.2.TF-A port design

In contrast to the existing Raspberry Pi 3 port this one here is a BL31-onlyport, also it deviates quite a lot from the RPi3 port in many other ways.There is not so much difference between the two models, so eventually thosetwo could be (more) unified in the future.

As with the previous models, the GPU and its firmware are the first entity torun after the SoC gets its power. The on-chip Boot ROM loads the next stage(bootcode.bin) from flash (EEPROM), which is again GPU code.This part knows how to access the MMC controller and how to parse a FATfilesystem, so it will load further components and configuration filesfrom the first FAT partition on the SD card.

To accommodate this existing way of configuring and setting up the board,we use as much of this workflow as possible.If bootcode.bin finds a file calledarmstub8.bin on the SD card or it getspointed to such code by finding aarmstub= key inconfig.txt, it willload this file to the beginning of DRAM (address 0) and execute it inAArch64 EL3.But before doing that, it will also load a “kernel” and the device tree intomemory. The load addresses have a default, but can also be changed bysetting them inconfig.txt. If the GPU firmware finds a magic value in thearmstub image file, it will put those two load addresses in memory locationsnear the beginning of memory, where TF-A code picks them up.

To keep things simple, we will just use the kernel load address as the BL33entry point, also put the DTB address in the x0 register, as requested bythe arm64 Linux kernel boot protocol. This does not necessarily mean thatthe EL2 payload needs to be a Linux kernel, a bootloader or any other kernelwould work as well, as long as it can cope with having the DT address inregister x0. If the payload has other means of finding the device tree, itcould ignore this address as well.