]>
Commit | Line | Data |
---|---|---|
5a5da7ce SG |
1 | Binman Entry Documentation |
2 | =========================== | |
3 | ||
4 | This file describes the entry types supported by binman. These entry types can | |
5 | be placed in an image one by one to build up a final firmware image. It is | |
6 | fairly easy to create new entry types. Just add a new file to the 'etype' | |
7 | directory. You can use the existing entries as examples. | |
8 | ||
9 | Note that some entries are subclasses of others, using and extending their | |
10 | features to produce new behaviours. | |
11 | ||
12 | ||
13 | ||
14 | Entry: blob: Entry containing an arbitrary binary blob | |
15 | ------------------------------------------------------ | |
16 | ||
17 | Note: This should not be used by itself. It is normally used as a parent | |
18 | class by other entry types. | |
19 | ||
20 | Properties / Entry arguments: | |
21 | - filename: Filename of file to read into entry | |
83d73c2f SG |
22 | - compress: Compression algorithm to use: |
23 | none: No compression | |
24 | lz4: Use lz4 compression (via 'lz4' command-line utility) | |
5a5da7ce SG |
25 | |
26 | This entry reads data from a file and places it in the entry. The | |
27 | default filename is often specified specified by the subclass. See for | |
28 | example the 'u_boot' entry which provides the filename 'u-boot.bin'. | |
29 | ||
83d73c2f SG |
30 | If compression is enabled, an extra 'uncomp-size' property is written to |
31 | the node (if enabled with -u) which provides the uncompressed size of the | |
32 | data. | |
33 | ||
5a5da7ce SG |
34 | |
35 | ||
6ed45ba0 SG |
36 | Entry: blob-dtb: A blob that holds a device tree |
37 | ------------------------------------------------ | |
38 | ||
39 | This is a blob containing a device tree. The contents of the blob are | |
40 | obtained from the list of available device-tree files, managed by the | |
41 | 'state' module. | |
42 | ||
43 | ||
44 | ||
ec127af0 SG |
45 | Entry: blob-named-by-arg: A blob entry which gets its filename property from its subclass |
46 | ----------------------------------------------------------------------------------------- | |
47 | ||
48 | Properties / Entry arguments: | |
49 | - <xxx>-path: Filename containing the contents of this entry (optional, | |
50 | defaults to 0) | |
51 | ||
52 | where <xxx> is the blob_fname argument to the constructor. | |
53 | ||
54 | This entry cannot be used directly. Instead, it is used as a parent class | |
55 | for another entry, which defined blob_fname. This parameter is used to | |
56 | set the entry-arg or property containing the filename. The entry-arg or | |
57 | property is in turn used to set the actual filename. | |
58 | ||
59 | See cros_ec_rw for an example of this. | |
60 | ||
61 | ||
62 | ||
63 | Entry: cros-ec-rw: A blob entry which contains a Chromium OS read-write EC image | |
64 | -------------------------------------------------------------------------------- | |
65 | ||
66 | Properties / Entry arguments: | |
67 | - cros-ec-rw-path: Filename containing the EC image | |
68 | ||
69 | This entry holds a Chromium OS EC (embedded controller) image, for use in | |
70 | updating the EC on startup via software sync. | |
71 | ||
72 | ||
73 | ||
0a98b28b SG |
74 | Entry: files: Entry containing a set of files |
75 | --------------------------------------------- | |
76 | ||
77 | Properties / Entry arguments: | |
78 | - pattern: Filename pattern to match the files to include | |
79 | - compress: Compression algorithm to use: | |
80 | none: No compression | |
81 | lz4: Use lz4 compression (via 'lz4' command-line utility) | |
82 | ||
83 | This entry reads a number of files and places each in a separate sub-entry | |
84 | within this entry. To access these you need to enable device-tree updates | |
85 | at run-time so you can obtain the file positions. | |
86 | ||
87 | ||
88 | ||
3af8e49c SG |
89 | Entry: fill: An entry which is filled to a particular byte value |
90 | ---------------------------------------------------------------- | |
91 | ||
92 | Properties / Entry arguments: | |
93 | - fill-byte: Byte to use to fill the entry | |
94 | ||
95 | Note that the size property must be set since otherwise this entry does not | |
96 | know how large it should be. | |
97 | ||
98 | You can often achieve the same effect using the pad-byte property of the | |
99 | overall image, in that the space between entries will then be padded with | |
100 | that byte. But this entry is sometimes useful for explicitly setting the | |
101 | byte value of a region. | |
102 | ||
103 | ||
104 | ||
11e36cce SG |
105 | Entry: fmap: An entry which contains an Fmap section |
106 | ---------------------------------------------------- | |
107 | ||
108 | Properties / Entry arguments: | |
109 | None | |
110 | ||
111 | FMAP is a simple format used by flashrom, an open-source utility for | |
112 | reading and writing the SPI flash, typically on x86 CPUs. The format | |
113 | provides flashrom with a list of areas, so it knows what it in the flash. | |
114 | It can then read or write just a single area, instead of the whole flash. | |
115 | ||
116 | The format is defined by the flashrom project, in the file lib/fmap.h - | |
117 | see www.flashrom.org/Flashrom for more information. | |
118 | ||
119 | When used, this entry will be populated with an FMAP which reflects the | |
120 | entries in the current image. Note that any hierarchy is squashed, since | |
121 | FMAP does not support this. | |
122 | ||
123 | ||
124 | ||
0ef87aa3 SG |
125 | Entry: gbb: An entry which contains a Chromium OS Google Binary Block |
126 | --------------------------------------------------------------------- | |
127 | ||
128 | Properties / Entry arguments: | |
129 | - hardware-id: Hardware ID to use for this build (a string) | |
130 | - keydir: Directory containing the public keys to use | |
131 | - bmpblk: Filename containing images used by recovery | |
132 | ||
133 | Chromium OS uses a GBB to store various pieces of information, in particular | |
134 | the root and recovery keys that are used to verify the boot process. Some | |
135 | more details are here: | |
136 | ||
137 | https://www.chromium.org/chromium-os/firmware-porting-guide/2-concepts | |
138 | ||
139 | but note that the page dates from 2013 so is quite out of date. See | |
140 | README.chromium for how to obtain the required keys and tools. | |
141 | ||
142 | ||
143 | ||
5a5da7ce SG |
144 | Entry: intel-cmc: Entry containing an Intel Chipset Micro Code (CMC) file |
145 | ------------------------------------------------------------------------- | |
146 | ||
147 | Properties / Entry arguments: | |
148 | - filename: Filename of file to read into entry | |
149 | ||
150 | This file contains microcode for some devices in a special format. An | |
151 | example filename is 'Microcode/C0_22211.BIN'. | |
152 | ||
153 | See README.x86 for information about x86 binary blobs. | |
154 | ||
155 | ||
156 | ||
157 | Entry: intel-descriptor: Intel flash descriptor block (4KB) | |
158 | ----------------------------------------------------------- | |
159 | ||
160 | Properties / Entry arguments: | |
161 | filename: Filename of file containing the descriptor. This is typically | |
162 | a 4KB binary file, sometimes called 'descriptor.bin' | |
163 | ||
164 | This entry is placed at the start of flash and provides information about | |
165 | the SPI flash regions. In particular it provides the base address and | |
166 | size of the ME (Management Engine) region, allowing us to place the ME | |
167 | binary in the right place. | |
168 | ||
169 | With this entry in your image, the position of the 'intel-me' entry will be | |
170 | fixed in the image, which avoids you needed to specify an offset for that | |
171 | region. This is useful, because it is not possible to change the position | |
172 | of the ME region without updating the descriptor. | |
173 | ||
174 | See README.x86 for information about x86 binary blobs. | |
175 | ||
176 | ||
177 | ||
178 | Entry: intel-fsp: Entry containing an Intel Firmware Support Package (FSP) file | |
179 | ------------------------------------------------------------------------------- | |
180 | ||
181 | Properties / Entry arguments: | |
182 | - filename: Filename of file to read into entry | |
183 | ||
184 | This file contains binary blobs which are used on some devices to make the | |
185 | platform work. U-Boot executes this code since it is not possible to set up | |
186 | the hardware using U-Boot open-source code. Documentation is typically not | |
187 | available in sufficient detail to allow this. | |
188 | ||
189 | An example filename is 'FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd' | |
190 | ||
191 | See README.x86 for information about x86 binary blobs. | |
192 | ||
193 | ||
194 | ||
195 | Entry: intel-me: Entry containing an Intel Management Engine (ME) file | |
196 | ---------------------------------------------------------------------- | |
197 | ||
198 | Properties / Entry arguments: | |
199 | - filename: Filename of file to read into entry | |
200 | ||
201 | This file contains code used by the SoC that is required to make it work. | |
202 | The Management Engine is like a background task that runs things that are | |
203 | not clearly documented, but may include keyboard, deplay and network | |
204 | access. For platform that use ME it is not possible to disable it. U-Boot | |
205 | does not directly execute code in the ME binary. | |
206 | ||
207 | A typical filename is 'me.bin'. | |
208 | ||
209 | See README.x86 for information about x86 binary blobs. | |
210 | ||
211 | ||
212 | ||
213 | Entry: intel-mrc: Entry containing an Intel Memory Reference Code (MRC) file | |
214 | ---------------------------------------------------------------------------- | |
215 | ||
216 | Properties / Entry arguments: | |
217 | - filename: Filename of file to read into entry | |
218 | ||
219 | This file contains code for setting up the SDRAM on some Intel systems. This | |
220 | is executed by U-Boot when needed early during startup. A typical filename | |
221 | is 'mrc.bin'. | |
222 | ||
223 | See README.x86 for information about x86 binary blobs. | |
224 | ||
225 | ||
226 | ||
227 | Entry: intel-vbt: Entry containing an Intel Video BIOS Table (VBT) file | |
228 | ----------------------------------------------------------------------- | |
229 | ||
230 | Properties / Entry arguments: | |
231 | - filename: Filename of file to read into entry | |
232 | ||
233 | This file contains code that sets up the integrated graphics subsystem on | |
234 | some Intel SoCs. U-Boot executes this when the display is started up. | |
235 | ||
236 | See README.x86 for information about Intel binary blobs. | |
237 | ||
238 | ||
239 | ||
240 | Entry: intel-vga: Entry containing an Intel Video Graphics Adaptor (VGA) file | |
241 | ----------------------------------------------------------------------------- | |
242 | ||
243 | Properties / Entry arguments: | |
244 | - filename: Filename of file to read into entry | |
245 | ||
246 | This file contains code that sets up the integrated graphics subsystem on | |
247 | some Intel SoCs. U-Boot executes this when the display is started up. | |
248 | ||
249 | This is similar to the VBT file but in a different format. | |
250 | ||
251 | See README.x86 for information about Intel binary blobs. | |
252 | ||
253 | ||
254 | ||
255 | Entry: section: Entry that contains other entries | |
256 | ------------------------------------------------- | |
257 | ||
258 | Properties / Entry arguments: (see binman README for more information) | |
259 | - size: Size of section in bytes | |
260 | - align-size: Align size to a particular power of two | |
261 | - pad-before: Add padding before the entry | |
262 | - pad-after: Add padding after the entry | |
263 | - pad-byte: Pad byte to use when padding | |
264 | - sort-by-offset: Reorder the entries by offset | |
265 | - end-at-4gb: Used to build an x86 ROM which ends at 4GB (2^32) | |
266 | - name-prefix: Adds a prefix to the name of every entry in the section | |
267 | when writing out the map | |
268 | ||
269 | A section is an entry which can contain other entries, thus allowing | |
270 | hierarchical images to be created. See 'Sections and hierarchical images' | |
271 | in the binman README for more information. | |
272 | ||
273 | ||
274 | ||
275 | Entry: text: An entry which contains text | |
276 | ----------------------------------------- | |
277 | ||
278 | The text can be provided either in the node itself or by a command-line | |
279 | argument. There is a level of indirection to allow multiple text strings | |
280 | and sharing of text. | |
281 | ||
282 | Properties / Entry arguments: | |
283 | text-label: The value of this string indicates the property / entry-arg | |
284 | that contains the string to place in the entry | |
285 | <xxx> (actual name is the value of text-label): contains the string to | |
286 | place in the entry. | |
287 | ||
288 | Example node: | |
289 | ||
290 | text { | |
291 | size = <50>; | |
292 | text-label = "message"; | |
293 | }; | |
294 | ||
295 | You can then use: | |
296 | ||
297 | binman -amessage="this is my message" | |
298 | ||
299 | and binman will insert that string into the entry. | |
300 | ||
301 | It is also possible to put the string directly in the node: | |
302 | ||
303 | text { | |
304 | size = <8>; | |
305 | text-label = "message"; | |
306 | message = "a message directly in the node" | |
307 | }; | |
308 | ||
309 | The text is not itself nul-terminated. This can be achieved, if required, | |
310 | by setting the size of the entry to something larger than the text. | |
311 | ||
312 | ||
313 | ||
314 | Entry: u-boot: U-Boot flat binary | |
315 | --------------------------------- | |
316 | ||
317 | Properties / Entry arguments: | |
318 | - filename: Filename of u-boot.bin (default 'u-boot.bin') | |
319 | ||
320 | This is the U-Boot binary, containing relocation information to allow it | |
321 | to relocate itself at runtime. The binary typically includes a device tree | |
322 | blob at the end of it. Use u_boot_nodtb if you want to package the device | |
323 | tree separately. | |
324 | ||
325 | U-Boot can access binman symbols at runtime. See: | |
326 | ||
327 | 'Access to binman entry offsets at run time (fdt)' | |
328 | ||
329 | in the binman README for more information. | |
330 | ||
331 | ||
332 | ||
333 | Entry: u-boot-dtb: U-Boot device tree | |
334 | ------------------------------------- | |
335 | ||
336 | Properties / Entry arguments: | |
337 | - filename: Filename of u-boot.dtb (default 'u-boot.dtb') | |
338 | ||
339 | This is the U-Boot device tree, containing configuration information for | |
340 | U-Boot. U-Boot needs this to know what devices are present and which drivers | |
341 | to activate. | |
342 | ||
6ed45ba0 SG |
343 | Note: This is mostly an internal entry type, used by others. This allows |
344 | binman to know which entries contain a device tree. | |
345 | ||
5a5da7ce SG |
346 | |
347 | ||
348 | Entry: u-boot-dtb-with-ucode: A U-Boot device tree file, with the microcode removed | |
349 | ----------------------------------------------------------------------------------- | |
350 | ||
351 | Properties / Entry arguments: | |
352 | - filename: Filename of u-boot.dtb (default 'u-boot.dtb') | |
353 | ||
354 | See Entry_u_boot_ucode for full details of the three entries involved in | |
355 | this process. This entry provides the U-Boot device-tree file, which | |
356 | contains the microcode. If the microcode is not being collated into one | |
357 | place then the offset and size of the microcode is recorded by this entry, | |
358 | for use by u_boot_with_ucode_ptr. If it is being collated, then this | |
359 | entry deletes the microcode from the device tree (to save space) and makes | |
360 | it available to u_boot_ucode. | |
361 | ||
362 | ||
363 | ||
fe1ae3ec SG |
364 | Entry: u-boot-elf: U-Boot ELF image |
365 | ----------------------------------- | |
366 | ||
367 | Properties / Entry arguments: | |
368 | - filename: Filename of u-boot (default 'u-boot') | |
369 | ||
370 | This is the U-Boot ELF image. It does not include a device tree but can be | |
371 | relocated to any address for execution. | |
372 | ||
373 | ||
374 | ||
5a5da7ce SG |
375 | Entry: u-boot-img: U-Boot legacy image |
376 | -------------------------------------- | |
377 | ||
378 | Properties / Entry arguments: | |
379 | - filename: Filename of u-boot.img (default 'u-boot.img') | |
380 | ||
381 | This is the U-Boot binary as a packaged image, in legacy format. It has a | |
382 | header which allows it to be loaded at the correct address for execution. | |
383 | ||
384 | You should use FIT (Flat Image Tree) instead of the legacy image for new | |
385 | applications. | |
386 | ||
387 | ||
388 | ||
389 | Entry: u-boot-nodtb: U-Boot flat binary without device tree appended | |
390 | -------------------------------------------------------------------- | |
391 | ||
392 | Properties / Entry arguments: | |
393 | - filename: Filename of u-boot.bin (default 'u-boot-nodtb.bin') | |
394 | ||
395 | This is the U-Boot binary, containing relocation information to allow it | |
396 | to relocate itself at runtime. It does not include a device tree blob at | |
397 | the end of it so normally cannot work without it. You can add a u_boot_dtb | |
398 | entry after this one, or use a u_boot entry instead (which contains both | |
399 | U-Boot and the device tree). | |
400 | ||
401 | ||
402 | ||
403 | Entry: u-boot-spl: U-Boot SPL binary | |
404 | ------------------------------------ | |
405 | ||
406 | Properties / Entry arguments: | |
407 | - filename: Filename of u-boot-spl.bin (default 'spl/u-boot-spl.bin') | |
408 | ||
409 | This is the U-Boot SPL (Secondary Program Loader) binary. This is a small | |
410 | binary which loads before U-Boot proper, typically into on-chip SRAM. It is | |
411 | responsible for locating, loading and jumping to U-Boot. Note that SPL is | |
412 | not relocatable so must be loaded to the correct address in SRAM, or written | |
b8ef5b6b | 413 | to run from the correct address if direct flash execution is possible (e.g. |
5a5da7ce SG |
414 | on x86 devices). |
415 | ||
416 | SPL can access binman symbols at runtime. See: | |
417 | ||
418 | 'Access to binman entry offsets at run time (symbols)' | |
419 | ||
420 | in the binman README for more information. | |
421 | ||
422 | The ELF file 'spl/u-boot-spl' must also be available for this to work, since | |
423 | binman uses that to look up symbols to write into the SPL binary. | |
424 | ||
425 | ||
426 | ||
427 | Entry: u-boot-spl-bss-pad: U-Boot SPL binary padded with a BSS region | |
428 | --------------------------------------------------------------------- | |
429 | ||
430 | Properties / Entry arguments: | |
431 | None | |
432 | ||
433 | This is similar to u_boot_spl except that padding is added after the SPL | |
434 | binary to cover the BSS (Block Started by Symbol) region. This region holds | |
435 | the various used by SPL. It is set to 0 by SPL when it starts up. If you | |
436 | want to append data to the SPL image (such as a device tree file), you must | |
437 | pad out the BSS region to avoid the data overlapping with U-Boot variables. | |
438 | This entry is useful in that case. It automatically pads out the entry size | |
439 | to cover both the code, data and BSS. | |
440 | ||
441 | The ELF file 'spl/u-boot-spl' must also be available for this to work, since | |
442 | binman uses that to look up the BSS address. | |
443 | ||
444 | ||
445 | ||
446 | Entry: u-boot-spl-dtb: U-Boot SPL device tree | |
447 | --------------------------------------------- | |
448 | ||
449 | Properties / Entry arguments: | |
450 | - filename: Filename of u-boot.dtb (default 'spl/u-boot-spl.dtb') | |
451 | ||
452 | This is the SPL device tree, containing configuration information for | |
453 | SPL. SPL needs this to know what devices are present and which drivers | |
454 | to activate. | |
455 | ||
456 | ||
457 | ||
fe1ae3ec SG |
458 | Entry: u-boot-spl-elf: U-Boot SPL ELF image |
459 | ------------------------------------------- | |
460 | ||
461 | Properties / Entry arguments: | |
462 | - filename: Filename of SPL u-boot (default 'spl/u-boot') | |
463 | ||
464 | This is the U-Boot SPL ELF image. It does not include a device tree but can | |
465 | be relocated to any address for execution. | |
466 | ||
467 | ||
468 | ||
5a5da7ce SG |
469 | Entry: u-boot-spl-nodtb: SPL binary without device tree appended |
470 | ---------------------------------------------------------------- | |
471 | ||
472 | Properties / Entry arguments: | |
473 | - filename: Filename of spl/u-boot-spl-nodtb.bin (default | |
474 | 'spl/u-boot-spl-nodtb.bin') | |
475 | ||
476 | This is the U-Boot SPL binary, It does not include a device tree blob at | |
477 | the end of it so may not be able to work without it, assuming SPL needs | |
478 | a device tree to operation on your platform. You can add a u_boot_spl_dtb | |
479 | entry after this one, or use a u_boot_spl entry instead (which contains | |
480 | both SPL and the device tree). | |
481 | ||
482 | ||
483 | ||
484 | Entry: u-boot-spl-with-ucode-ptr: U-Boot SPL with embedded microcode pointer | |
485 | ---------------------------------------------------------------------------- | |
486 | ||
f0253635 SG |
487 | This is used when SPL must set up the microcode for U-Boot. |
488 | ||
5a5da7ce SG |
489 | See Entry_u_boot_ucode for full details of the entries involved in this |
490 | process. | |
491 | ||
492 | ||
493 | ||
b8ef5b6b SG |
494 | Entry: u-boot-tpl: U-Boot TPL binary |
495 | ------------------------------------ | |
496 | ||
497 | Properties / Entry arguments: | |
498 | - filename: Filename of u-boot-tpl.bin (default 'tpl/u-boot-tpl.bin') | |
499 | ||
500 | This is the U-Boot TPL (Tertiary Program Loader) binary. This is a small | |
501 | binary which loads before SPL, typically into on-chip SRAM. It is | |
502 | responsible for locating, loading and jumping to SPL, the next-stage | |
503 | loader. Note that SPL is not relocatable so must be loaded to the correct | |
504 | address in SRAM, or written to run from the correct address if direct | |
505 | flash execution is possible (e.g. on x86 devices). | |
506 | ||
507 | SPL can access binman symbols at runtime. See: | |
508 | ||
509 | 'Access to binman entry offsets at run time (symbols)' | |
510 | ||
511 | in the binman README for more information. | |
512 | ||
513 | The ELF file 'tpl/u-boot-tpl' must also be available for this to work, since | |
514 | binman uses that to look up symbols to write into the TPL binary. | |
515 | ||
516 | ||
517 | ||
518 | Entry: u-boot-tpl-dtb: U-Boot TPL device tree | |
519 | --------------------------------------------- | |
520 | ||
521 | Properties / Entry arguments: | |
522 | - filename: Filename of u-boot.dtb (default 'tpl/u-boot-tpl.dtb') | |
523 | ||
524 | This is the TPL device tree, containing configuration information for | |
525 | TPL. TPL needs this to know what devices are present and which drivers | |
526 | to activate. | |
527 | ||
528 | ||
529 | ||
f0253635 SG |
530 | Entry: u-boot-tpl-dtb-with-ucode: U-Boot TPL with embedded microcode pointer |
531 | ---------------------------------------------------------------------------- | |
532 | ||
533 | This is used when TPL must set up the microcode for U-Boot. | |
534 | ||
535 | See Entry_u_boot_ucode for full details of the entries involved in this | |
536 | process. | |
537 | ||
538 | ||
539 | ||
540 | Entry: u-boot-tpl-with-ucode-ptr: U-Boot TPL with embedded microcode pointer | |
541 | ---------------------------------------------------------------------------- | |
542 | ||
543 | See Entry_u_boot_ucode for full details of the entries involved in this | |
544 | process. | |
545 | ||
546 | ||
547 | ||
5a5da7ce SG |
548 | Entry: u-boot-ucode: U-Boot microcode block |
549 | ------------------------------------------- | |
550 | ||
551 | Properties / Entry arguments: | |
552 | None | |
553 | ||
554 | The contents of this entry are filled in automatically by other entries | |
555 | which must also be in the image. | |
556 | ||
557 | U-Boot on x86 needs a single block of microcode. This is collected from | |
558 | the various microcode update nodes in the device tree. It is also unable | |
559 | to read the microcode from the device tree on platforms that use FSP | |
560 | (Firmware Support Package) binaries, because the API requires that the | |
561 | microcode is supplied before there is any SRAM available to use (i.e. | |
562 | the FSP sets up the SRAM / cache-as-RAM but does so in the call that | |
563 | requires the microcode!). To keep things simple, all x86 platforms handle | |
564 | microcode the same way in U-Boot (even non-FSP platforms). This is that | |
565 | a table is placed at _dt_ucode_base_size containing the base address and | |
566 | size of the microcode. This is either passed to the FSP (for FSP | |
567 | platforms), or used to set up the microcode (for non-FSP platforms). | |
568 | This all happens in the build system since it is the only way to get | |
569 | the microcode into a single blob and accessible without SRAM. | |
570 | ||
571 | There are two cases to handle. If there is only one microcode blob in | |
572 | the device tree, then the ucode pointer it set to point to that. This | |
573 | entry (u-boot-ucode) is empty. If there is more than one update, then | |
574 | this entry holds the concatenation of all updates, and the device tree | |
575 | entry (u-boot-dtb-with-ucode) is updated to remove the microcode. This | |
576 | last step ensures that that the microcode appears in one contiguous | |
577 | block in the image and is not unnecessarily duplicated in the device | |
578 | tree. It is referred to as 'collation' here. | |
579 | ||
580 | Entry types that have a part to play in handling microcode: | |
581 | ||
582 | Entry_u_boot_with_ucode_ptr: | |
583 | Contains u-boot-nodtb.bin (i.e. U-Boot without the device tree). | |
584 | It updates it with the address and size of the microcode so that | |
585 | U-Boot can find it early on start-up. | |
586 | Entry_u_boot_dtb_with_ucode: | |
587 | Contains u-boot.dtb. It stores the microcode in a | |
588 | 'self.ucode_data' property, which is then read by this class to | |
589 | obtain the microcode if needed. If collation is performed, it | |
590 | removes the microcode from the device tree. | |
591 | Entry_u_boot_ucode: | |
592 | This class. If collation is enabled it reads the microcode from | |
593 | the Entry_u_boot_dtb_with_ucode entry, and uses it as the | |
594 | contents of this entry. | |
595 | ||
596 | ||
597 | ||
598 | Entry: u-boot-with-ucode-ptr: U-Boot with embedded microcode pointer | |
599 | -------------------------------------------------------------------- | |
600 | ||
601 | Properties / Entry arguments: | |
602 | - filename: Filename of u-boot-nodtb.dtb (default 'u-boot-nodtb.dtb') | |
f0693038 SG |
603 | - optional-ucode: boolean property to make microcode optional. If the |
604 | u-boot.bin image does not include microcode, no error will | |
605 | be generated. | |
5a5da7ce SG |
606 | |
607 | See Entry_u_boot_ucode for full details of the three entries involved in | |
608 | this process. This entry updates U-Boot with the offset and size of the | |
609 | microcode, to allow early x86 boot code to find it without doing anything | |
610 | complicated. Otherwise it is the same as the u_boot entry. | |
611 | ||
612 | ||
613 | ||
24d0d3c3 SG |
614 | Entry: vblock: An entry which contains a Chromium OS verified boot block |
615 | ------------------------------------------------------------------------ | |
616 | ||
617 | Properties / Entry arguments: | |
618 | - keydir: Directory containing the public keys to use | |
619 | - keyblock: Name of the key file to use (inside keydir) | |
620 | - signprivate: Name of provide key file to use (inside keydir) | |
621 | - version: Version number of the vblock (typically 1) | |
622 | - kernelkey: Name of the kernel key to use (inside keydir) | |
623 | - preamble-flags: Value of the vboot preamble flags (typically 0) | |
624 | ||
a326b495 SG |
625 | Output files: |
626 | - input.<unique_name> - input file passed to futility | |
627 | - vblock.<unique_name> - output file generated by futility (which is | |
628 | used as the entry contents) | |
629 | ||
f0693038 | 630 | Chromium OS signs the read-write firmware and kernel, writing the signature |
24d0d3c3 SG |
631 | in this block. This allows U-Boot to verify that the next firmware stage |
632 | and kernel are genuine. | |
633 | ||
634 | ||
635 | ||
5a5da7ce SG |
636 | Entry: x86-start16: x86 16-bit start-up code for U-Boot |
637 | ------------------------------------------------------- | |
638 | ||
639 | Properties / Entry arguments: | |
640 | - filename: Filename of u-boot-x86-16bit.bin (default | |
641 | 'u-boot-x86-16bit.bin') | |
642 | ||
643 | x86 CPUs start up in 16-bit mode, even if they are 32-bit CPUs. This code | |
644 | must be placed at a particular address. This entry holds that code. It is | |
645 | typically placed at offset CONFIG_SYS_X86_START16. The code is responsible | |
646 | for changing to 32-bit mode and jumping to U-Boot's entry point, which | |
647 | requires 32-bit mode (for 32-bit U-Boot). | |
648 | ||
649 | For 64-bit U-Boot, the 'x86_start16_spl' entry type is used instead. | |
650 | ||
651 | ||
652 | ||
653 | Entry: x86-start16-spl: x86 16-bit start-up code for SPL | |
654 | -------------------------------------------------------- | |
655 | ||
656 | Properties / Entry arguments: | |
657 | - filename: Filename of spl/u-boot-x86-16bit-spl.bin (default | |
658 | 'spl/u-boot-x86-16bit-spl.bin') | |
659 | ||
660 | x86 CPUs start up in 16-bit mode, even if they are 64-bit CPUs. This code | |
661 | must be placed at a particular address. This entry holds that code. It is | |
662 | typically placed at offset CONFIG_SYS_X86_START16. The code is responsible | |
663 | for changing to 32-bit mode and starting SPL, which in turn changes to | |
664 | 64-bit mode and jumps to U-Boot (for 64-bit U-Boot). | |
665 | ||
666 | For 32-bit U-Boot, the 'x86_start16' entry type is used instead. | |
667 | ||
668 | ||
669 | ||
35b384cb SG |
670 | Entry: x86-start16-tpl: x86 16-bit start-up code for TPL |
671 | -------------------------------------------------------- | |
672 | ||
673 | Properties / Entry arguments: | |
674 | - filename: Filename of tpl/u-boot-x86-16bit-tpl.bin (default | |
675 | 'tpl/u-boot-x86-16bit-tpl.bin') | |
676 | ||
677 | x86 CPUs start up in 16-bit mode, even if they are 64-bit CPUs. This code | |
678 | must be placed at a particular address. This entry holds that code. It is | |
679 | typically placed at offset CONFIG_SYS_X86_START16. The code is responsible | |
680 | for changing to 32-bit mode and starting TPL, which in turn jumps to SPL. | |
681 | ||
682 | If TPL is not being used, the 'x86_start16_spl or 'x86_start16' entry types | |
683 | may be used instead. | |
684 | ||
685 | ||
686 |