anchor.diff:  deprecated, and it should be included only on cpu and memory nodes for compatibility with
   IEEE 1275–derived device trees.
   
  -Copyright © 2008, 2011 Power.org, Inc. All Rights Reserved.
  -Page 29 of 108
  -
  --Version 1.1 – 7 March 2011
  -
  -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
  -
  -Power.org ePAPR
  -
  -2.4 Interrupts and Interrupt Mapping
  -The ePAPR adopts the interrupt tree model of representing interrupts specified in Open Firmware
  -Recommended Practice: Interrupt Mapping, Version 0.9 [7]. Within the device tree a logical interrupt
  -tree exists that represents the hierarchy and routing of interrupts in the platform hardware. While
  -generically referred to as an interrupt tree it is more technically a directed acyclic graph.
  -The physical wiring of an interrupt source to an interrupt controller is represented in the device tree
  -with the interrupt-parent property. Nodes that represent interrupt-generating devices contain an
  -interrupt-parent property which has a phandle value that points to the device to which the device's
  -interrupts are routed, typically an interrupt controller. If an interrupt-generating device does not have
  -an interrupt-parent property, its interrupt parent is assumed to be its device tree parent.
  -Each interrupt generating device contains an interrupts property with a value describing one or more
  -interrupt sources for that device—each source represented with information called an interrupt
  -specifier. The format and meaning of an interrupt specifier is interrupt domain specific, i.e., it is
  -dependent on properties on the node at the root of its interrupt domain. The #interrupt-cells property
  -is used by the root of an interrupt domain to define the number of <u32> values needed to encode an
  -interrupt specifier. For example, for an Open PIC interrupt controller, an interrupt-specifer takes two
  -32-bit values and consists of an interrupt number and level/sense information for the interrupt.
  -An interrupt domain is the context in which an interrupt specifier is interpreted. The root of the
  -domain is either (1) an interrupt controller or (2) an interrupt nexus.
  +=== Interrupts and Interrupt Mapping
  +The ePAPR adopts the interrupt tree model of representing interrupts
  +specified in Open Firmware Recommended Practice: Interrupt Mapping,
  +Version 0.9 [7]. Within the device tree a logical interrupt tree exists
  +that represents the hierarchy and routing of interrupts in the platform
  +hardware. While generically referred to as an interrupt tree it is more
  +technically a directed acyclic graph.
  +
  +The physical wiring of an interrupt source to an interrupt controller is
  +represented in the device tree with the interrupt-parent property. Nodes
  +that represent interrupt-generating devices contain an interrupt-parent
  +property which has a phandle value that points to the device to which
  +the device's interrupts are routed, typically an interrupt controller.
  +If an interrupt-generating device does not have an interrupt-parent
  +property, its interrupt parent is assumed to be its device tree parent.
  +
  +Each interrupt generating device contains an interrupts property with a
  +value describing one or more interrupt sources for that device—each
  +source represented with information called an interrupt specifier. The
  +format and meaning of an interrupt specifier is interrupt domain
  +specific, i.e., it is dependent on properties on the node at the root of
  +its interrupt domain. The #interrupt-cells property is used by the root
  +of an interrupt domain to define the number of <u32> values needed to
  +encode an interrupt specifier. For example, for an Open PIC interrupt
  +controller, an interrupt-specifer takes two 32-bit values and consists
  +of an interrupt number and level/sense information for the interrupt.
  +
  +An interrupt domain is the context in which an interrupt specifier is
  +interpreted. The root of the domain is either (1) an interrupt
  +controller or (2) an interrupt nexus.
  +
   1. An interrupt controller is physical device and will need a driver to handle interrupts routed
   through it. It may also cascade into another interrupt domain. An interrupt controller is
   specified by the presence of an interrupt-controller property on that node in the device tree.
  
positive.code: 64
  00
  
  2
  3
  4
  
  Copyright © 2008, 2011 Power.org, Inc. All Rights Reserved.
  Page 20 of 108
  
  Version 1.1 – 7 March 2011
  
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  
  2.3 Standard Properties
  
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  
  2.3.1 compatible
  
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  
  2.3.2 model
  
  Power.org ePAPR
  
  The ePAPR specifies a set of standard properties for device nodes. These properties are described in
  detail in this section. Device nodes defined by the ePAPR (see Chapter 3, Device Node
  Requirements) may specify additional requirements or constraints regarding the use of the standard
  properties. Device bindings (Chapter 6) that describe the representation of specific devices may also
  specify additional requirements.
  Note: All examples of device tree nodes in this document use the Device Tree Source (DTS) format
  for specifying nodes and properties.
  
  Property: compatible
  Value type: <stringlist>
  
negative.code: };
  };
  
  
  
  
  
  4 Client Program Image Format
  
  
  === Variable Address Image Format
  
  
  ==== ELF Basics
  
  
  ==== Boot Program Requirements
  
  
  ===== Pr ocessing of PT_LOAD segments
  
  This section describes the image format in which an ePAPR client is encoded in order to boot it from
  an ePAPR-compliant boot program. Two variants on the image format are described: variable-address
  