diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2007-03-13 20:50:40 -0400 |
---|---|---|
committer | Paul Mackerras <paulus@samba.org> | 2007-03-16 01:38:19 -0400 |
commit | 0e0293c898c424c52e5d4e7f6923a203d06b9c4b (patch) | |
tree | 54078533f47d45c0840095901e416dfa543393ba /Documentation/powerpc | |
parent | a782a9e3a12bcea4916117b0832016c24fffeb85 (diff) |
[POWERPC] Update documentation for flat device tree format v17
This patch updates booting-without-of.txt to describe version 17 of
the flattened device tree format. Version 17 is a small, backwards
compatible change from version 16, adding an extra field giving the
size of the device tree's structure block. At this time, the kernel
has no use for the extra information, however its presence can make
life easier for bootloaders or other software manipulating the tree.
In addition this patch adds information on the size_dt_strings field
of the device tree header, present since version 3 of the flattened
tree format, but omitted from the documentation. It also makes
changes to consistently refer to versions 16 and 17 as versions 16 and
17 in decimal, rather than version 0x10 which was occasionally used
for version 16 previously.
Finally, we also add the new field to the definition of the device
tree header structure in prom.h
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Diffstat (limited to 'Documentation/powerpc')
-rw-r--r-- | Documentation/powerpc/booting-without-of.txt | 29 |
1 files changed, 23 insertions, 6 deletions
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 6d5a5a0fa5e8..a1f83f1c24c9 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt | |||
@@ -265,6 +265,9 @@ struct boot_param_header { | |||
265 | booting on */ | 265 | booting on */ |
266 | /* version 3 fields below */ | 266 | /* version 3 fields below */ |
267 | u32 size_dt_strings; /* size of the strings block */ | 267 | u32 size_dt_strings; /* size of the strings block */ |
268 | |||
269 | /* version 17 fields below */ | ||
270 | u32 size_dt_struct; /* size of the DT structure block */ | ||
268 | }; | 271 | }; |
269 | 272 | ||
270 | Along with the constants: | 273 | Along with the constants: |
@@ -335,10 +338,13 @@ struct boot_param_header { | |||
335 | to reallocate it easily at boot and free up the unused flattened | 338 | to reallocate it easily at boot and free up the unused flattened |
336 | structure after expansion. Version 16 introduces a new more | 339 | structure after expansion. Version 16 introduces a new more |
337 | "compact" format for the tree itself that is however not backward | 340 | "compact" format for the tree itself that is however not backward |
338 | compatible. You should always generate a structure of the highest | 341 | compatible. Version 17 adds an additional field, size_dt_struct, |
339 | version defined at the time of your implementation. Currently | 342 | allowing it to be reallocated or moved more easily (this is |
340 | that is version 16, unless you explicitly aim at being backward | 343 | particularly useful for bootloaders which need to make |
341 | compatible. | 344 | adjustments to a device tree based on probed information). You |
345 | should always generate a structure of the highest version defined | ||
346 | at the time of your implementation. Currently that is version 17, | ||
347 | unless you explicitly aim at being backward compatible. | ||
342 | 348 | ||
343 | - last_comp_version | 349 | - last_comp_version |
344 | 350 | ||
@@ -347,7 +353,7 @@ struct boot_param_header { | |||
347 | is backward compatible with version 1 (that is, a kernel build | 353 | is backward compatible with version 1 (that is, a kernel build |
348 | for version 1 will be able to boot with a version 2 format). You | 354 | for version 1 will be able to boot with a version 2 format). You |
349 | should put a 1 in this field if you generate a device tree of | 355 | should put a 1 in this field if you generate a device tree of |
350 | version 1 to 3, or 0x10 if you generate a tree of version 0x10 | 356 | version 1 to 3, or 16 if you generate a tree of version 16 or 17 |
351 | using the new unit name format. | 357 | using the new unit name format. |
352 | 358 | ||
353 | - boot_cpuid_phys | 359 | - boot_cpuid_phys |
@@ -360,6 +366,17 @@ struct boot_param_header { | |||
360 | point (see further chapters for more informations on the required | 366 | point (see further chapters for more informations on the required |
361 | device-tree contents) | 367 | device-tree contents) |
362 | 368 | ||
369 | - size_dt_strings | ||
370 | |||
371 | This field only exists on version 3 and later headers. It | ||
372 | gives the size of the "strings" section of the device tree (which | ||
373 | starts at the offset given by off_dt_strings). | ||
374 | |||
375 | - size_dt_struct | ||
376 | |||
377 | This field only exists on version 17 and later headers. It gives | ||
378 | the size of the "structure" section of the device tree (which | ||
379 | starts at the offset given by off_dt_struct). | ||
363 | 380 | ||
364 | So the typical layout of a DT block (though the various parts don't | 381 | So the typical layout of a DT block (though the various parts don't |
365 | need to be in that order) looks like this (addresses go from top to | 382 | need to be in that order) looks like this (addresses go from top to |
@@ -417,7 +434,7 @@ root node who has no parent. | |||
417 | A node has 2 names. The actual node name is generally contained in a | 434 | A node has 2 names. The actual node name is generally contained in a |
418 | property of type "name" in the node property list whose value is a | 435 | property of type "name" in the node property list whose value is a |
419 | zero terminated string and is mandatory for version 1 to 3 of the | 436 | zero terminated string and is mandatory for version 1 to 3 of the |
420 | format definition (as it is in Open Firmware). Version 0x10 makes it | 437 | format definition (as it is in Open Firmware). Version 16 makes it |
421 | optional as it can generate it from the unit name defined below. | 438 | optional as it can generate it from the unit name defined below. |
422 | 439 | ||
423 | There is also a "unit name" that is used to differentiate nodes with | 440 | There is also a "unit name" that is used to differentiate nodes with |