blob: 91af786bc7c82203f6308a6cf307987a3fd1786b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
|
EL3 Firmware Test framework Porting Guide
=========================================
Contents
--------
1. Introduction
2. Platform requirements
3. Mandatory modifications
4. Optional modifications
5. Storage abstraction layer
- - - - - - - - - - - - - - - - - -
1. Introduction
----------------
Porting the EL3 Firmware Test Framework to a new platform involves making some
mandatory and optional modifications for both the cold and warm boot paths.
Modifications consist of:
* Implementing a platform-specific function or variable,
* Setting up the execution context in a certain way, or
* Defining certain constants (for example #defines).
The platform-specific functions and variables are all declared in
[include/plat/common/platform.h]. The framework provides a default
implementation of variables and functions to fulfill the optional requirements.
These implementations are all weakly defined; they are provided to ease the
porting effort. Each platform port can override them with its own implementation
if the default implementation is inadequate.
2. Platform requirements
-------------------------
The Test Framework relies on the following features to be present on the
platform and accessible from Normal World.
* Watchdog
* Non-Volatile Memory
* System Timer
This also means that a platform port of the Test Framework must include software
drivers for those features.
3. Mandatory modifications
---------------------------
### File : platform_def.h [mandatory]
Each platform must ensure that a header file of this name is in the system
include path with the following constants defined. This may require updating the
list of `PLAT_INCLUDES` in the `platform.mk` file. In the ARM FVP port, this
file is found in [plat/fvp/include/platform_def.h].
* **#define : PLATFORM_LINKER_FORMAT**
Defines the linker format used by the platform, for example
`elf64-littleaarch64` used by the FVP.
* **#define : PLATFORM_LINKER_ARCH**
Defines the processor architecture for the linker by the platform, for
example `aarch64` used by the FVP.
* **#define : PLATFORM_STACK_SIZE**
Defines the stack memory available to each CPU. This constant is used by
[plat/common/aarch64/platform_mp_stack.S].
* **#define : PLATFORM_CACHE_LINE_SIZE**
Defines the size (in bytes) of the largest cache line across all the cache
levels in the platform.
* **#define : PLATFORM_CLUSTER_COUNT**
Defines the total number of clusters implemented by the platform in the
system.
* **#define : PLATFORM_CORE_COUNT**
Defines the total number of CPUs implemented by the platform across all
clusters in the system.
* **#define : PLATFORM_MAX_CPUS_PER_CLUSTER**
Defines the maximum number of CPUs that can be implemented within a cluster
on the platform.
* **#define : PLATFORM_NUM_AFFS**
Defines the total number of nodes in the affinity hierarchy at all affinity
levels used by the platform.
* **#define : TFTF_BASE**
Defines the base address of the TFTF binary in DRAM. Used by the linker
script to link the image at the right address. Must be aligned on a
page-size boundary.
If the platform port uses the IO storage framework, the following constants
must also be defined:
* **#define : MAX_IO_DEVICES**
Defines the maximum number of registered IO devices. Attempting to register
more devices than this value using `io_register_device()` will fail with
`IO_RESOURCES_EXHAUSTED`.
* **#define : MAX_IO_HANDLES**
Defines the maximum number of open IO handles. Attempting to open more IO
entities than this value using `io_open()` will fail with
`IO_RESOURCES_EXHAUSTED`.
### Function : tftf_plat_arch_setup() [mandatory]
Argument : void
Return : void
This function performs any platform-specific and architectural setup that the
platform requires.
In both the ARM FVP and Juno ports, this function configures and enables the
MMU.
### Function : tftf_early_platform_setup() [mandatory]
Argument : void
Return : void
This function executes with the MMU and data caches disabled. It is only called
by the primary CPU. It is used to perform platform-specific actions very early
in the boot.
In both the ARM FVP and Juno ports, this function configures the console.
### Function : tftf_platform_setup() [mandatory]
Argument : void
Return : void
This function executes with the MMU and data caches enabled. It is responsible
for performing any remaining platform-specific setup that can occur after the
MMU and data cache have been enabled.
This function is also responsible for initializing the storage abstraction layer
used to access non-volatile memory for permanent storage of test results. It
also initialises the GIC and detects the platform topology using
platform-specific means.
4. Optional modifications
--------------------------
The following are helper functions implemented by the Test Framework that
perform common platform-specific tasks. A platform may choose to override these
definitions.
### Function : platform_get_stack()
Argument : unsigned long
Return : unsigned long
This function returns the base address of the memory stack that has been
allocated for the CPU specified by MPIDR. The size of the stack allocated to
each CPU is specified by the platform defined constant `PLATFORM_STACK_SIZE`.
Common implementation of this function is provided in
[plat/common/aarch64/platform_mp_stack.S].
### Function : tftf_platform_end()
Argument : void
Return : void
This function performs any operation required by the platform to properly finish
the test session.
In the FVP port, this function terminates the model by sending an EOT
(End Of Transmission) character on the UART.
5. Storage abstraction layer
-----------------------------
In order to improve platform independence and portability a storage abstraction
layer is used to store test results to non-volatile platform storage.
Each platform should register devices and their drivers via the Storage layer.
These drivers then need to be initialized in `tftf_platform_setup()` function.
It is mandatory to implement at least one storage driver. For the FVP and Juno
platforms the NOR Flash driver is provided as the default means to store test
results to storage. The storage layer is described in the header file
`<FIXME>/io_storage.h`. The implementation of the common library is in
`<FIXME>/io_storage.c` and the driver files are located in `drivers/io/`.
------------------------------------------------------
Old documentation
*** (Optional) plat/<platform>/tests_platform/tests_to_skip.txt
List of tests to skip for this platform.
Should specify 1 test per line, using the following format:
testsuite_name/testcase_name
where `testsuite_name` and `testcase_name` are the names that appear in
tests/data/tests.xml file.
|
