aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/powerpc
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/powerpc')
-rw-r--r--Documentation/powerpc/booting-without-of.txt43
-rw-r--r--Documentation/powerpc/eeh-pci-error-recovery.txt4
-rw-r--r--Documentation/powerpc/hvcs.txt2
3 files changed, 24 insertions, 25 deletions
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index b57e7da78976..27b457c09729 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -145,7 +145,7 @@ it with special cases.
145 in case you are entering the kernel with MMU enabled 145 in case you are entering the kernel with MMU enabled
146 and a non-1:1 mapping. 146 and a non-1:1 mapping.
147 147
148 r5 : NULL (as to differenciate with method a) 148 r5 : NULL (as to differentiate with method a)
149 149
150 Note about SMP entry: Either your firmware puts your other 150 Note about SMP entry: Either your firmware puts your other
151 CPUs in some sleep loop or spin loop in ROM where you can get 151 CPUs in some sleep loop or spin loop in ROM where you can get
@@ -245,7 +245,7 @@ the block to RAM before passing it to the kernel.
245--------- 245---------
246 246
247 The kernel is entered with r3 pointing to an area of memory that is 247 The kernel is entered with r3 pointing to an area of memory that is
248 roughtly described in include/asm-powerpc/prom.h by the structure 248 roughly described in include/asm-powerpc/prom.h by the structure
249 boot_param_header: 249 boot_param_header:
250 250
251struct boot_param_header { 251struct boot_param_header {
@@ -335,7 +335,7 @@ struct boot_param_header {
335 "compact" format for the tree itself that is however not backward 335 "compact" format for the tree itself that is however not backward
336 compatible. You should always generate a structure of the highest 336 compatible. You should always generate a structure of the highest
337 version defined at the time of your implementation. Currently 337 version defined at the time of your implementation. Currently
338 that is version 16, unless you explicitely aim at being backward 338 that is version 16, unless you explicitly aim at being backward
339 compatible. 339 compatible.
340 340
341 - last_comp_version 341 - last_comp_version
@@ -418,9 +418,9 @@ zero terminated string and is mandatory for version 1 to 3 of the
418format definition (as it is in Open Firmware). Version 0x10 makes it 418format definition (as it is in Open Firmware). Version 0x10 makes it
419optional as it can generate it from the unit name defined below. 419optional as it can generate it from the unit name defined below.
420 420
421There is also a "unit name" that is used to differenciate nodes with 421There is also a "unit name" that is used to differentiate nodes with
422the same name at the same level, it is usually made of the node 422the same name at the same level, it is usually made of the node
423name's, the "@" sign, and a "unit address", which definition is 423names, the "@" sign, and a "unit address", which definition is
424specific to the bus type the node sits on. 424specific to the bus type the node sits on.
425 425
426The unit name doesn't exist as a property per-se but is included in 426The unit name doesn't exist as a property per-se but is included in
@@ -550,11 +550,11 @@ Here's the basic structure of a single node:
550 * [child nodes if any] 550 * [child nodes if any]
551 * token OF_DT_END_NODE (that is 0x00000002) 551 * token OF_DT_END_NODE (that is 0x00000002)
552 552
553So the node content can be summmarised as a start token, a full path, 553So the node content can be summarised as a start token, a full path,
554a list of properties, a list of child node and an end token. Every 554a list of properties, a list of child nodes, and an end token. Every
555child node is a full node structure itself as defined above. 555child node is a full node structure itself as defined above.
556 556
5574) Device tree 'strings" block 5574) Device tree "strings" block
558 558
559In order to save space, property names, which are generally redundant, 559In order to save space, property names, which are generally redundant,
560are stored separately in the "strings" block. This block is simply the 560are stored separately in the "strings" block. This block is simply the
@@ -573,7 +573,7 @@ implementation of Open Firmware or an implementation compatible with
573the Open Firmware client interface, those properties will be created 573the Open Firmware client interface, those properties will be created
574by the trampoline code in the kernel's prom_init() file. For example, 574by the trampoline code in the kernel's prom_init() file. For example,
575that's where you'll have to add code to detect your board model and 575that's where you'll have to add code to detect your board model and
576set the platform number. However, when using the flatenned device-tree 576set the platform number. However, when using the flattened device-tree
577entry point, there is no prom_init() pass, and thus you have to 577entry point, there is no prom_init() pass, and thus you have to
578provide those properties yourself. 578provide those properties yourself.
579 579
@@ -630,12 +630,11 @@ like address space bits, you'll have to add a bus translator to the
630prom_parse.c file of the recent kernels for your bus type. 630prom_parse.c file of the recent kernels for your bus type.
631 631
632The "reg" property only defines addresses and sizes (if #size-cells 632The "reg" property only defines addresses and sizes (if #size-cells
633is 633is non-0) within a given bus. In order to translate addresses upward
634non-0) within a given bus. In order to translate addresses upward
635(that is into parent bus addresses, and possibly into cpu physical 634(that is into parent bus addresses, and possibly into cpu physical
636addresses), all busses must contain a "ranges" property. If the 635addresses), all busses must contain a "ranges" property. If the
637"ranges" property is missing at a given level, it's assumed that 636"ranges" property is missing at a given level, it's assumed that
638translation isn't possible. The format of the "ranges" proprety for a 637translation isn't possible. The format of the "ranges" property for a
639bus is a list of: 638bus is a list of:
640 639
641 bus address, parent bus address, size 640 bus address, parent bus address, size
@@ -689,7 +688,7 @@ is present).
6894) Note about node and property names and character set 6884) Note about node and property names and character set
690------------------------------------------------------- 689-------------------------------------------------------
691 690
692While open firmware provides more flexibe usage of 8859-1, this 691While open firmware provides more flexible usage of 8859-1, this
693specification enforces more strict rules. Nodes and properties should 692specification enforces more strict rules. Nodes and properties should
694be comprised only of ASCII characters 'a' to 'z', '0' to 693be comprised only of ASCII characters 'a' to 'z', '0' to
695'9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally 694'9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally
@@ -732,12 +731,12 @@ address which can extend beyond that limit.
732 that typically get driven by the same platform code in the 731 that typically get driven by the same platform code in the
733 kernel, you would use a different "model" property but put a 732 kernel, you would use a different "model" property but put a
734 value in "compatible". The kernel doesn't directly use that 733 value in "compatible". The kernel doesn't directly use that
735 value (see /chosen/linux,platform for how the kernel choses a 734 value (see /chosen/linux,platform for how the kernel chooses a
736 platform type) but it is generally useful. 735 platform type) but it is generally useful.
737 736
738 The root node is also generally where you add additional properties 737 The root node is also generally where you add additional properties
739 specific to your board like the serial number if any, that sort of 738 specific to your board like the serial number if any, that sort of
740 thing. it is recommended that if you add any "custom" property whose 739 thing. It is recommended that if you add any "custom" property whose
741 name may clash with standard defined ones, you prefix them with your 740 name may clash with standard defined ones, you prefix them with your
742 vendor name and a comma. 741 vendor name and a comma.
743 742
@@ -817,7 +816,7 @@ address which can extend beyond that limit.
817 your board. It's a list of addresses/sizes concatenated 816 your board. It's a list of addresses/sizes concatenated
818 together, with the number of cells of each defined by the 817 together, with the number of cells of each defined by the
819 #address-cells and #size-cells of the root node. For example, 818 #address-cells and #size-cells of the root node. For example,
820 with both of these properties beeing 2 like in the example given 819 with both of these properties being 2 like in the example given
821 earlier, a 970 based machine with 6Gb of RAM could typically 820 earlier, a 970 based machine with 6Gb of RAM could typically
822 have a "reg" property here that looks like: 821 have a "reg" property here that looks like:
823 822
@@ -970,7 +969,7 @@ device-tree in another format. The currently supported formats are:
970 - "asm": assembly language file. This is a file that can be 969 - "asm": assembly language file. This is a file that can be
971 sourced by gas to generate a device-tree "blob". That file can 970 sourced by gas to generate a device-tree "blob". That file can
972 then simply be added to your Makefile. Additionally, the 971 then simply be added to your Makefile. Additionally, the
973 assembly file exports some symbols that can be use 972 assembly file exports some symbols that can be used.
974 973
975 974
976The syntax of the dtc tool is 975The syntax of the dtc tool is
@@ -984,10 +983,10 @@ generated. Supported versions are 1,2,3 and 16. The default is
984currently version 3 but that may change in the future to version 16. 983currently version 3 but that may change in the future to version 16.
985 984
986Additionally, dtc performs various sanity checks on the tree, like the 985Additionally, dtc performs various sanity checks on the tree, like the
987uniqueness of linux,phandle properties, validity of strings, etc... 986uniqueness of linux, phandle properties, validity of strings, etc...
988 987
989The format of the .dts "source" file is "C" like, supports C and C++ 988The format of the .dts "source" file is "C" like, supports C and C++
990style commments. 989style comments.
991 990
992/ { 991/ {
993} 992}
@@ -1069,13 +1068,13 @@ while all this has been defined and implemented.
1069 around. It contains no internal offsets or pointers for this 1068 around. It contains no internal offsets or pointers for this
1070 purpose. 1069 purpose.
1071 1070
1072 - An example of code for iterating nodes & retreiving properties 1071 - An example of code for iterating nodes & retrieving properties
1073 directly from the flattened tree format can be found in the kernel 1072 directly from the flattened tree format can be found in the kernel
1074 file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function, 1073 file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function,
1075 it's usage in early_init_devtree(), and the corresponding various 1074 its usage in early_init_devtree(), and the corresponding various
1076 early_init_dt_scan_*() callbacks. That code can be re-used in a 1075 early_init_dt_scan_*() callbacks. That code can be re-used in a
1077 GPL bootloader, and as the author of that code, I would be happy 1076 GPL bootloader, and as the author of that code, I would be happy
1078 do discuss possible free licencing to any vendor who wishes to 1077 to discuss possible free licencing to any vendor who wishes to
1079 integrate all or part of this code into a non-GPL bootloader. 1078 integrate all or part of this code into a non-GPL bootloader.
1080 1079
1081 1080
diff --git a/Documentation/powerpc/eeh-pci-error-recovery.txt b/Documentation/powerpc/eeh-pci-error-recovery.txt
index 3764dd4b12cb..4530d1bf0286 100644
--- a/Documentation/powerpc/eeh-pci-error-recovery.txt
+++ b/Documentation/powerpc/eeh-pci-error-recovery.txt
@@ -90,7 +90,7 @@ EEH-isolated, there is a firmware call it can make to determine if
90this is the case. If so, then the device driver should put itself 90this is the case. If so, then the device driver should put itself
91into a consistent state (given that it won't be able to complete any 91into a consistent state (given that it won't be able to complete any
92pending work) and start recovery of the card. Recovery normally 92pending work) and start recovery of the card. Recovery normally
93would consist of reseting the PCI device (holding the PCI #RST 93would consist of resetting the PCI device (holding the PCI #RST
94line high for two seconds), followed by setting up the device 94line high for two seconds), followed by setting up the device
95config space (the base address registers (BAR's), latency timer, 95config space (the base address registers (BAR's), latency timer,
96cache line size, interrupt line, and so on). This is followed by a 96cache line size, interrupt line, and so on). This is followed by a
@@ -116,7 +116,7 @@ At this time, a generic EEH recovery mechanism has been implemented,
116so that individual device drivers do not need to be modified to support 116so that individual device drivers do not need to be modified to support
117EEH recovery. This generic mechanism piggy-backs on the PCI hotplug 117EEH recovery. This generic mechanism piggy-backs on the PCI hotplug
118infrastructure, and percolates events up through the userspace/udev 118infrastructure, and percolates events up through the userspace/udev
119infrastructure. Followiing is a detailed description of how this is 119infrastructure. Following is a detailed description of how this is
120accomplished. 120accomplished.
121 121
122EEH must be enabled in the PHB's very early during the boot process, 122EEH must be enabled in the PHB's very early during the boot process,
diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.txt
index 1e38166f4e54..f93462c5db25 100644
--- a/Documentation/powerpc/hvcs.txt
+++ b/Documentation/powerpc/hvcs.txt
@@ -259,7 +259,7 @@ This index of '2' means that in order to connect to vty-server adapter
259 259
260It should be noted that due to the system hotplug I/O capabilities of a 260It should be noted that due to the system hotplug I/O capabilities of a
261system the /dev/hvcs* entry that interacts with a particular vty-server 261system the /dev/hvcs* entry that interacts with a particular vty-server
262adapter is not guarenteed to remain the same across system reboots. Look 262adapter is not guaranteed to remain the same across system reboots. Look
263in the Q & A section for more on this issue. 263in the Q & A section for more on this issue.
264 264
265--------------------------------------------------------------------------- 265---------------------------------------------------------------------------