1Raspberry Pi 4 2============== 3 4The `Raspberry Pi 4`_ is an inexpensive single-board computer that contains four 5Arm Cortex-A72 cores. Also in contrast to previous Raspberry Pi versions this 6model has a GICv2 interrupt controller. 7 8This port is a minimal port to support loading non-secure EL2 payloads such 9as a 64-bit Linux kernel. Other payloads such as U-Boot or EDK-II should work 10as well, but have not been tested at this point. 11 12**IMPORTANT NOTE**: This port isn't secure. All of the memory used is DRAM, 13which is available from both the Non-secure and Secure worlds. The SoC does 14not seem to feature a secure memory controller of any kind, so portions of 15DRAM can't be protected properly from the Non-secure world. 16 17Build Instructions 18------------------ 19 20There are no real configuration options at this point, so there is only 21one universal binary (bl31.bin), which can be built with: 22 23.. code:: shell 24 25 CROSS_COMPILE=aarch64-linux-gnu- make PLAT=rpi4 DEBUG=1 26 27Copy the generated build/rpi4/debug/bl31.bin to the SD card, either 28renaming it to ``armstub8.bin`` or adding an entry starting with ``armstub=``, 29then followed by the respective file name to ``config.txt``. 30You should have AArch64 code in the file loaded as the "kernel", as BL31 31will drop into AArch64/EL2 to the respective load address. 32arm64 Linux kernels are known to work this way. 33 34Other options that should be set in ``config.txt`` to properly boot 64-bit 35kernels are: 36 37:: 38 39 enable_uart=1 40 arm_64bit=1 41 enable_gic=1 42 43The BL31 code will patch the provided device tree blob in memory to advertise 44PSCI support, also will add a reserved-memory node to the DT to tell the 45non-secure payload to not touch the resident TF-A code. 46 47If you connect a serial cable between the Mini UART and your computer, and 48connect to it (for example, with ``screen /dev/ttyUSB0 115200``) you should 49see some text from BL31, followed by the output of the EL2 payload. 50The command line provided is read from the ``cmdline.txt`` file on the SD card. 51 52TF-A port design 53---------------- 54 55In contrast to the existing Raspberry Pi 3 port this one here is a BL31-only 56port, also it deviates quite a lot from the RPi3 port in many other ways. 57There is not so much difference between the two models, so eventually those 58two could be (more) unified in the future. 59 60As with the previous models, the GPU and its firmware are the first entity to 61run after the SoC gets its power. The on-chip Boot ROM loads the next stage 62(bootcode.bin) from flash (EEPROM), which is again GPU code. 63This part knows how to access the MMC controller and how to parse a FAT 64filesystem, so it will load further compononents and configuration files 65from the first FAT partition on the SD card. 66 67To accommodate this existing way of configuring and setting up the board, 68we use as much of this workflow as possible. 69If bootcode.bin finds a file called ``armstub8.bin`` on the SD card or it gets 70pointed to such code by finding a ``armstub=`` key in ``config.txt``, it will 71load this file to the beginning of DRAM (address 0) and execute it in 72AArch64 EL3. 73But before doing that, it will also load a "kernel" and the device tree into 74memory. The load addresses have a default, but can also be changed by 75setting them in ``config.txt``. If the GPU firmware finds a magic value in the 76armstub image file, it will put those two load addresses in memory locations 77near the beginning of memory, where TF-A code picks them up. 78 79To keep things simple, we will just use the kernel load address as the BL33 80entry point, also put the DTB address in the x0 register, as requested by 81the arm64 Linux kernel boot protocol. This does not necessarily mean that 82the EL2 payload needs to be a Linux kernel, a bootloader or any other kernel 83would work as well, as long as it can cope with having the DT address in 84register x0. If the payload has other means of finding the device tree, it 85could ignore this address as well. 86