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
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
|
/* SPDX-License-Identifier: MIT */
/*
* Copyright © 2022 Intel Corporation
*/
#ifndef _XE_UC_FW_ABI_H
#define _XE_UC_FW_ABI_H
#include <linux/build_bug.h>
#include <linux/types.h>
/**
* DOC: CSS-based Firmware Layout
*
* The CSS-based firmware structure is used for GuC releases on all platforms
* and for HuC releases up to DG1. Starting from DG2/MTL the HuC uses the GSC
* layout instead.
* The CSS firmware layout looks like this::
*
* +======================================================================+
* | Firmware blob |
* +===============+===============+============+============+============+
* | CSS header | uCode | RSA key | modulus | exponent |
* +===============+===============+============+============+============+
* <-header size-> <---header size continued ----------->
* <--- size ----------------------------------------------------------->
* <-key size->
* <-mod size->
* <-exp size->
*
* The firmware may or may not have modulus key and exponent data. The header,
* uCode and RSA signature are must-have components that will be used by driver.
* Length of each components, which is all in dwords, can be found in header.
* In the case that modulus and exponent are not present in fw, a.k.a truncated
* image, the length value still appears in header.
*
* Driver will do some basic fw size validation based on the following rules:
*
* 1. Header, uCode and RSA are must-have components.
* 2. All firmware components, if they present, are in the sequence illustrated
* in the layout table above.
* 3. Length info of each component can be found in header, in dwords.
* 4. Modulus and exponent key are not required by driver. They may not appear
* in fw. So driver will load a truncated firmware in this case.
*/
struct uc_css_header {
u32 module_type;
/*
* header_size includes all non-uCode bits, including css_header, rsa
* key, modulus key and exponent data.
*/
u32 header_size_dw;
u32 header_version;
u32 module_id;
u32 module_vendor;
u32 date;
#define CSS_DATE_DAY (0xFF << 0)
#define CSS_DATE_MONTH (0xFF << 8)
#define CSS_DATE_YEAR (0xFFFF << 16)
u32 size_dw; /* uCode plus header_size_dw */
u32 key_size_dw;
u32 modulus_size_dw;
u32 exponent_size_dw;
u32 time;
#define CSS_TIME_HOUR (0xFF << 0)
#define CSS_DATE_MIN (0xFF << 8)
#define CSS_DATE_SEC (0xFFFF << 16)
char username[8];
char buildnumber[12];
u32 sw_version;
#define CSS_SW_VERSION_UC_MAJOR (0xFF << 16)
#define CSS_SW_VERSION_UC_MINOR (0xFF << 8)
#define CSS_SW_VERSION_UC_PATCH (0xFF << 0)
union {
u32 submission_version; /* only applies to GuC */
u32 reserved2;
};
u32 reserved0[12];
union {
u32 private_data_size; /* only applies to GuC */
u32 reserved1;
};
u32 header_info;
} __packed;
static_assert(sizeof(struct uc_css_header) == 128);
/**
* DOC: GSC-based Firmware Layout
*
* The GSC-based firmware structure is used for GSC releases on all platforms
* and for HuC releases starting from DG2/MTL. Older HuC releases use the
* CSS-based layout instead. Differently from the CSS headers, the GSC headers
* uses a directory + entries structure (i.e., there is array of addresses
* pointing to specific header extensions identified by a name). Although the
* header structures are the same, some of the entries are specific to GSC while
* others are specific to HuC. The manifest header entry, which includes basic
* information about the binary (like the version) is always present, but it is
* named differently based on the binary type.
*
* The HuC binary starts with a Code Partition Directory (CPD) header. The
* entries we're interested in for use in the driver are:
*
* 1. "HUCP.man": points to the manifest header for the HuC.
* 2. "huc_fw": points to the FW code. On platforms that support load via DMA
* and 2-step HuC authentication (i.e. MTL+) this is a full CSS-based binary,
* while if the GSC is the one doing the load (which only happens on DG2)
* this section only contains the uCode.
*
* The GSC-based HuC firmware layout looks like this::
*
* +================================================+
* | CPD Header |
* +================================================+
* | CPD entries[] |
* | entry1 |
* | ... |
* | entryX |
* | "HUCP.man" |
* | ... |
* | offset >----------------------------|------o
* | ... | |
* | entryY | |
* | "huc_fw" | |
* | ... | |
* | offset >----------------------------|----------o
* +================================================+ | |
* | |
* +================================================+ | |
* | Manifest Header |<-----o |
* | ... | |
* | FW version | |
* | ... | |
* +================================================+ |
* |
* +================================================+ |
* | FW binary |<---------o
* | CSS (MTL+ only) |
* | uCode |
* | RSA Key (MTL+ only) |
* | ... |
* +================================================+
*
* The GSC binary starts instead with a layout header, which contains the
* locations of the various partitions of the binary. The one we're interested
* in is the boot1 partition, where we can find a BPDT header followed by
* entries, one of which points to the RBE sub-section of the partition, which
* contains the CPD. The GSC blob does not contain a CSS-based binary, so we
* only need to look for the manifest, which is under the "RBEP.man" CPD entry.
* Note that we have no need to find where the actual FW code is inside the
* image because the GSC ROM will itself parse the headers to find it and load
* it.
* The GSC firmware header layout looks like this::
*
* +================================================+
* | Layout Pointers |
* | ... |
* | Boot1 offset >---------------------------|------o
* | ... | |
* +================================================+ |
* |
* +================================================+ |
* | BPDT header |<-----o
* +================================================+
* | BPDT entries[] |
* | entry1 |
* | ... |
* | entryX |
* | type == GSC_RBE |
* | offset >-----------------------------|------o
* | ... | |
* +================================================+ |
* |
* +================================================+ |
* | CPD Header |<-----o
* +================================================+
* | CPD entries[] |
* | entry1 |
* | ... |
* | entryX |
* | "RBEP.man" |
* | ... |
* | offset >----------------------------|------o
* | ... | |
* +================================================+ |
* |
* +================================================+ |
* | Manifest Header |<-----o
* | ... |
* | FW version |
* | ... |
* | Security version |
* | ... |
* +================================================+
*/
struct gsc_version {
u16 major;
u16 minor;
u16 hotfix;
u16 build;
} __packed;
struct gsc_partition {
u32 offset;
u32 size;
} __packed;
struct gsc_layout_pointers {
u8 rom_bypass_vector[16];
/* size of this header section, not including ROM bypass vector */
u16 size;
/*
* bit0: Backup copy of layout pointers exists
* bits1-15: reserved
*/
u8 flags;
u8 reserved;
u32 crc32;
struct gsc_partition datap;
struct gsc_partition boot1;
struct gsc_partition boot2;
struct gsc_partition boot3;
struct gsc_partition boot4;
struct gsc_partition boot5;
struct gsc_partition temp_pages;
} __packed;
/* Boot partition structures */
struct gsc_bpdt_header {
u32 signature;
#define GSC_BPDT_HEADER_SIGNATURE 0x000055AA
u16 descriptor_count; /* num of entries after the header */
u8 version;
u8 configuration;
u32 crc32;
u32 build_version;
struct gsc_version tool_version;
} __packed;
struct gsc_bpdt_entry {
/*
* Bits 0-15: BPDT entry type
* Bits 16-17: reserved
* Bit 18: code sub-partition
* Bits 19-31: reserved
*/
u32 type;
#define GSC_BPDT_ENTRY_TYPE_MASK GENMASK(15, 0)
#define GSC_BPDT_ENTRY_TYPE_GSC_RBE 0x1
u32 sub_partition_offset; /* from the base of the BPDT header */
u32 sub_partition_size;
} __packed;
/* Code partition directory (CPD) structures */
struct gsc_cpd_header_v2 {
u32 header_marker;
#define GSC_CPD_HEADER_MARKER 0x44504324
u32 num_of_entries;
u8 header_version;
u8 entry_version;
u8 header_length; /* in bytes */
u8 flags;
u32 partition_name;
u32 crc32;
} __packed;
struct gsc_cpd_entry {
u8 name[12];
/*
* Bits 0-24: offset from the beginning of the code partition
* Bit 25: huffman compressed
* Bits 26-31: reserved
*/
u32 offset;
#define GSC_CPD_ENTRY_OFFSET_MASK GENMASK(24, 0)
#define GSC_CPD_ENTRY_HUFFMAN_COMP BIT(25)
/*
* Module/Item length, in bytes. For Huffman-compressed modules, this
* refers to the uncompressed size. For software-compressed modules,
* this refers to the compressed size.
*/
u32 length;
u8 reserved[4];
} __packed;
struct gsc_manifest_header {
u32 header_type; /* 0x4 for manifest type */
u32 header_length; /* in dwords */
u32 header_version;
u32 flags;
u32 vendor;
u32 date;
u32 size; /* In dwords, size of entire manifest (header + extensions) */
u32 header_id;
u32 internal_data;
struct gsc_version fw_version;
u32 security_version;
struct gsc_version meu_kit_version;
u32 meu_manifest_version;
u8 general_data[4];
u8 reserved3[56];
u32 modulus_size; /* in dwords */
u32 exponent_size; /* in dwords */
} __packed;
#endif
|
