anchor.diff:  
   The format of the value of the ranges property is an arbitrary number of
   triplets of (child-busaddress, parent-bus-address, length)
  -* The child-bus-address is a physical address within the child bus’
  +* The child-bus-address is a physical address within the child bus'
     address space. The number of cells to represent the address is bus
     dependent and can be determined from the #address-cells of this node
     (the node in which the ranges property appears).
  -* The parent-bus-address is a physical address within the parent bus’
  +* The parent-bus-address is a physical address within the parent bus'
     address space. The number of cells to represent the parent address is
     bus dependent and can be determined from the #address-cells property
  -  of the node that defines the parent’s address space.
  -* The length specifies the size of the range in the child’s address
  +  of the node that defines the parent's address space.
  +* The length specifies the size of the range in the child's address
     space. The number of cells to represent the size can be determined
     from the #size-cells of this node (the node in which the ranges
     property appears).
  
positive.code: fixed-address format, and may also support other formats not described
  in this document.
  
  This ePAPR image format is a constrained form of ELF (Executable and
  Linking Format, see <<17>>) executable. That is, an ePAPR client image
  shall be a valid ELF file, but also has additional requirements
  described in the next sections.
  
  A variable-address client image is a 32-bit ELF client image with the
  following ELF header field values:
  e_ident[EI_CLASS]
  e_ident[EI_DATA]
  e_type
  e_machine
  
  ELFCLASS32(0x1)
  ELFDATA2MSB(0x2)
  ET_DYN(0x3)
  EM_PPC(0x14)
  
  That is, it is a 32-bit Power shared-object image in 2's complement, big-endian format.
  Every ePAPR image shall have at least one program header of type PT_LOAD. It may also have other
  valid ELF program headers. The client image shall be arranged so that all its ELF program headers lie
  within the first 1024 bytes of the image.
  
  When loading a client image, the boot program need only consider ELF segments of type PT_LOAD.
  Other segments may be present, but should be ignored by the boot program. In particular, the boot
  program should not process any ELF relocations found in the client image.
  
  The boot program shall load the contents of any PT_LOAD segments into RAM, and then pass control
  to the entry point specified in the ELF header in the manner specified in section 5.4.
  Each PT_LOAD segments shall be loaded at an address decided by the boot program, subject to the
  following constraints.
  • The load address shall be congruent with the program header’s p_paddr value, modulo with
  the program header’s p_align value.
  
  
  
  
  •
  
  
  If there is more than one PT_LOAD segment, then the difference between the loaded address
  and the address specified in the p_paddr field shall be the same for all segments. That is,
  the boot program shall preserve the relative offsets between PT_LOAD segments by physical
  address.
  
  The p_vaddr field is reserved to represent the effective address at which the segments will appear
  after the client program has performed MMU setup. The boot program should not use the program
  header’s p_vaddr field for determining the load address of segments.
  
  
  ===== Entr y point
  
  
  ==== Client Program Requirements
  
  The program entry point is the address of the first instruction that is to be executed in a program image.
  The ELF header e_entry field gives the effective address of the program entry point. However, as
  described in section 5.4, CPU Entry Point Requirements, the client program shall be entered either in
  real mode or with an initial MMU mapping at effective address 0x0.
  Therefore, the boot program shall compute the physical address of the entry point before entering the
  client program. To perform this calculation, it shall locate the program segment containing the entry
  point, determine the difference between e_entry and the p_vaddr of that segment, and add this
  difference to the physical address where the segment was loaded.
  This adjusted address will be the physical address of the first client program instruction executed after
  the boot program jumps to the client program.
  
  The client program is entered with MMU state as described in section 5.4, CPU Entry Point
  Requirements. Therefore, the code at the client program’s entry point shall be prepared to execute in
  this environment, which may be different than the MMU environment in which most of the client
  program executes. The p_vaddr fields of the client’s ELF program headers will reflect this final
  environment, not the environment in which the entry point is executed.
  The code at the entry point shall be written so that it can be executed at any address. It shall establish a
  suitable environment in which the remainder of the client program executes. The ePAPR does not
  specify its method, but the task could involve:
  •
  
  •
  •
  
  •
  
  Processing ELF relocations to relocate the client’s own image to its loaded address. Note that
  in this case the client image shall be specially linked so that the ELF relocation information,
  plus any data required to find that information is contained in both the loaded segments and
  the segments and sections set aside for relocation information.
  Processing other tables of relocation information in some format specific to the client
  program.
  Physically copying the client image to the address at which it prefers to execute.
  Configuring the MMU so that the client image can execute at its preferred effective address,
  regardless of the physical address at which it is loaded.
  
  
  
  
  
  === Fixed Address Image Format
  Fixed-address client images are identical to variable-address client images except for the following
  changes:
  o The e_type ELF header field shall have the value ET_EXEC (0x2).
  o The boot program, instead of loading each PT_LOAD segment at an address of its choosing
  shall load each PT_LOAD segment at the physical address given in the program header's
  p_paddr field. If it cannot load the segment at this address (because memory does not exist
  at that address or is already in use by the boot program itself), then it shall refuse to load the
  image and report an error condition.
  The fixed-address image format is intended for use by very simple clients (such as diagnostic
  programs), avoiding the need for such clients to physically relocate themselves to a suitable address.
  Clients should in general avoid using the fixed-address format, because creating a usable fixedaddress image requires knowing which physical areas will be available for client use on the platform
  in question.
  
  
  
  
  
  == Client Program Boot Requirements
  
  
negative.code: CPUs that belong to the client, the state of those CPUs, and the address of the spin table entry to
  release each CPU.
  For each secondary CPU, the physical address of the spin table entry for the CPU is specified in the
  device tree in the cpu node's cpu-release-addr property. To activate a secondary CPU, the client
  program (running on the boot cpu) may write the pir field value, may write the r3 value, may write
  the most significant 32 bits of the entry_addr value, and shall write the least significant 32 bits of
  the entry_addr value. After the client has written the least significant 32 bits of the entry_addr
  