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