xref: /rk3399_ARM-atf/docs/plat/arm/fvp/fvp-specific-configs.rst (revision 10ecd58093a34e95e2dfad65b1180610f29397cc)
1Booting Firmware Update images
2------------------------------
3
4When Firmware Update (FWU) is enabled there are at least 2 new images
5that have to be loaded, the Non-Secure FWU ROM (NS-BL1U), and the
6FWU FIP.
7
8The additional fip images must be loaded with:
9
10::
11
12    --data cluster0.cpu0="<path_to>/ns_bl1u.bin"@0x0beb8000	[ns_bl1u_base_address]
13    --data cluster0.cpu0="<path_to>/fwu_fip.bin"@0x08400000	[ns_bl2u_base_address]
14
15The address ns_bl1u_base_address is the value of NS_BL1U_BASE.
16In the same way, the address ns_bl2u_base_address is the value of
17NS_BL2U_BASE.
18
19Booting an EL3 payload
20----------------------
21
22The EL3 payloads boot flow requires the CPU's mailbox to be cleared at reset for
23the secondary CPUs holding pen to work properly. Unfortunately, its reset value
24is undefined on the FVP platform and the FVP platform code doesn't clear it.
25Therefore, one must modify the way the model is normally invoked in order to
26clear the mailbox at start-up.
27
28One way to do that is to create an 8-byte file containing all zero bytes using
29the following command:
30
31.. code:: shell
32
33    dd if=/dev/zero of=mailbox.dat bs=1 count=8
34
35and pre-load it into the FVP memory at the mailbox address (i.e. ``0x04000000``)
36using the following model parameters:
37
38::
39
40    --data cluster0.cpu0=mailbox.dat@0x04000000   [Base FVPs]
41    --data=mailbox.dat@0x04000000                 [Foundation FVP]
42
43To provide the model with the EL3 payload image, the following methods may be
44used:
45
46#. If the EL3 payload is able to execute in place, it may be programmed into
47   flash memory. On Base Cortex and AEM FVPs, the following model parameter
48   loads it at the base address of the NOR FLASH1 (the NOR FLASH0 is already
49   used for the FIP):
50
51   ::
52
53       -C bp.flashloader1.fname="<path-to>/<el3-payload>"
54
55   On Foundation FVP, there is no flash loader component and the EL3 payload
56   may be programmed anywhere in flash using method 3 below.
57
58#. When using the ``SPIN_ON_BL1_EXIT=1`` loading method, the following DS-5
59   command may be used to load the EL3 payload ELF image over JTAG:
60
61   ::
62
63       load <path-to>/el3-payload.elf
64
65#. The EL3 payload may be pre-loaded in volatile memory using the following
66   model parameters:
67
68   ::
69
70       --data cluster0.cpu0="<path-to>/el3-payload>"@address   [Base FVPs]
71       --data="<path-to>/<el3-payload>"@address                [Foundation FVP]
72
73   The address provided to the FVP must match the ``EL3_PAYLOAD_BASE`` address
74   used when building TF-A.
75
76Booting a kernel image in BL33
77------------------------------
78
79TF-A can boot a Linux kernel, which uses a ramdisk as a filesystem. The
80required initrd properties are injected in to the device tree blob (DTB) at
81build time.
82
83Kernel image packaged in fip as a BL33 image
84^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
85
86A Linux kernel image can be packaged in the fip as a BL33 image and then
87booted in TF-A.
88
89For example, the firmware can be built as:
90
91.. code:: shell
92
93    make PLAT=fvp DEBUG=1             \
94    ARM_LINUX_KERNEL_AS_BL33          \
95    BL33=<path-to-kernel-binary>      \
96    INITRD_SIZE=0x8000000             \
97    all fip
98
99The options ``INITRD_SIZE`` or ``INITRD_PATH`` triggers the insertion of initrd
100properties in to the DTB. ``INITRD_BASE`` is also required but a default value
101is set by the FVP platform.
102
103The options available here are:
104
105::
106
107    INITRD_BASE: Set the initrd base address in memory. Defaults to 0x90000000 in FVP.
108    INITRD_SIZE: Set the initrd size in dec or hex format. Hex format must precede with '0x'.
109    INITRD_PATH: Provide an initrd path for the build time to determine its exact size.
110
111Users can provide either ``INITRD_SIZE`` or ``INITRD_PATH`` to set the initrd
112size value. ``INITRD_SIZE`` takes prioty over ``INITRD_PATH``.
113
114Now the fvp binary can be run as:
115
116.. code:: shell
117
118    <path-to>/FVP_Base_AEMv8A-AEMv8A                            \
119    -C bp.secureflashloader.fname=<path-to>/bl1.bin             \
120    -C bp.flashloader0.fname=<path-to>/fip.bin                  \
121    --data cluster0.cpu0="<path-to>/<initrd.bin>"@0x90000000
122
123.. note::
124    Providing a higher value for an initrd size than the actual size of the file
125    is supported but it will trigger a non-breaking "Initramfs unpacking failed"
126    error by the kernel at runtime. This error can be ignored because initrd's
127    can be stacked one after another, when the kernel unpacks the first initrd it
128    looks for another in the extra space which it won't find, hence the error.
129
130Preloaded kernel image - Normal flow
131^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
132
133The following example uses a simplified boot flow to boot a Linux kernel
134using TF-A. This can be useful if the kernel is already present in memory
135(like in FVP).
136
137For example, if the kernel is loaded at ``0x80080000`` the firmware can be
138built like this:
139
140.. code:: shell
141
142    make PLAT=fvp DEBUG=1             \
143    ARM_LINUX_KERNEL_AS_BL33=1        \
144    PRELOADED_BL33_BASE=0x80080000    \
145    INITRD_SIZE=0x8000000             \
146    all fip
147
148Now the FVP binary can be run with the following command:
149
150.. code:: shell
151
152    <path-to>/FVP_Base_AEMv8A-AEMv8A                            \
153    -C bp.secureflashloader.fname=<path-to>/bl1.bin             \
154    -C bp.flashloader0.fname=<path-to>/fip.bin                  \
155    --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \
156    --data cluster0.cpu0="<path-to>/<initrd.bin>"@0x90000000
157
158Preloaded kernel image - Reset to BL31
159^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
160
161We can also boot a Linux kernel by jumping directly to BL31 ``RESET_TO_BL31=1``.
162This requires preloading a DTB into memory. We can inject the initrd start and
163end properties into the DTB (HW_CONFIG) at build time which is then stored by
164TF-A in ``build/fvp/<build-type>/fdts/`` directory.
165
166For example, we can build the firmware as:
167
168.. code:: shell
169
170    make PLAT=fvp DEBUG=1                   \
171    RESET_TO_BL31=1                         \
172    ARM_LINUX_KERNEL_AS_BL33=1              \
173    PRELOADED_BL33_BASE=0x80080000          \
174    ARM_PRELOADED_DTB_BASE=0x87F00000       \
175    INITRD_BASE=0x88000000                  \
176    INITRD_PATH=<path-to>/initrd.bin
177
178Now we can run the binary as:
179
180.. code:: shell
181
182    <path-to>/FVP_Base_AEMv8A-AEMv8A                               \
183    -C cluster0.NUM_CORES=4                                        \
184    -C cluster0.cpu0.RVBAR=0x04001000                              \
185    -C cluster0.cpu1.RVBAR=0x04001000                              \
186    -C cluster0.cpu2.RVBAR=0x04001000                              \
187    -C cluster0.cpu3.RVBAR=0x04001000                              \
188    --data cluster0.cpu0="<path-to>/bl31.bin"@0x04001000           \
189    --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000    \
190    --data cluster0.cpu0="<path-to>/<initrd.bin>"@0x88000000       \
191    --data cluster0.cpu0="<path-to>/fdts/fvp-base-gicv3-psci.dtb"@87F00000
192
193Obtaining the Flattened Device Trees
194^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
195
196Depending on the FVP configuration and Linux configuration used, different
197FDT files are required. FDT source files for the Foundation and Base FVPs can
198be found in the TF-A source directory under ``fdts/``. The Foundation FVP has
199a subset of the Base FVP components. For example, the Foundation FVP lacks
200CLCD and MMC support, and has only one CPU cluster.
201
202.. note::
203   It is not recommended to use the FDTs built along the kernel because not
204   all FDTs are available from there.
205
206The dynamic configuration capability is enabled in the firmware for FVPs.
207This means that the firmware can authenticate and load the FDT if present in
208FIP. A default FDT is packaged into FIP during the build based on
209the build configuration. This can be overridden by using the ``FVP_HW_CONFIG``
210or ``FVP_HW_CONFIG_DTS`` build options (refer to
211:ref:`build_options_arm_fvp_platform` for details on the options).
212
213-  ``fvp-base-gicv2-psci.dts``
214
215   For use with models such as the Cortex-A57-A53 or Cortex-A32 Base FVPs
216   without shifted affinities and with Base memory map configuration.
217
218-  ``fvp-base-gicv3-psci.dts``
219
220   For use with models such as the Cortex-A57-A53 or Cortex-A32 Base FVPs
221   without shifted affinities and with Base memory map configuration and
222   Linux GICv3 support.
223
224-  ``fvp-base-gicv3-psci-1t.dts``
225
226   For use with models such as the AEMv8-RevC Base FVP with shifted affinities,
227   single threaded CPUs, Base memory map configuration and Linux GICv3 support.
228
229-  ``fvp-base-gicv3-psci-dynamiq.dts``
230
231   For use with models as the Cortex-A55-A75 Base FVPs with shifted affinities,
232   single cluster, single threaded CPUs, Base memory map configuration and Linux
233   GICv3 support.
234
235-  ``fvp-foundation-gicv2-psci.dts``
236
237   For use with Foundation FVP with Base memory map configuration.
238
239-  ``fvp-foundation-gicv3-psci.dts``
240
241   (Default) For use with Foundation FVP with Base memory map configuration
242   and Linux GICv3 support.
243
244--------------
245
246*Copyright (c) 2019-2024, Arm Limited. All rights reserved.*
247