IMA proposal

Yoder Stuart-B08248 B08248 at freescale.com
Sat Sep 18 00:08:55 EST 2010


-Scott Wood, Dan Hettena, and myself discussed IMAs and have
 a proposal for ePAPR 1.1

-there are a number of issues/questions/inconsistencies  around IMAs
 (initial mapped areas) as described in ePAPR 1.0
    -5.3 says IMAs are applicable to book III-E only, but
     in 5.4.4 real mode CPUs have a 'boot IMA'
    -real mode CPUs appear have no way to determine starting
     address of the IMA
    -why is there a natural alignment constraint?
    -some vague references to identity mappings
   
-what a client program needs to know is the initial memory
 region it can use without fiddling with the MMU

-IMA proposal for ePAPR 1.1

   -IMA refers to 'initial memory area'
    (i.e. applicable to both real mode and Book III-E)

   -size of the IMA is passed to the client program in r7

   -the 'effective address' of the IMA is passed to the 
    client program in r8

   -the physical address range corresponding to the IMA
    must consist entirely of normal RAM and must not overlap
    any memory reservations specified in the device tree.

   -no requirement for
      -being mapped to lowest physical address
      -natural alignment to size of IMA

   -Book III-E client determines physical address of IMA by
    searching for EA in TLB

-Thus, all memory in the IMA is free to be used by the client
 program, though the client program should be careful not to
 overwrite its own image or the device tree.

Regards,
Stuart Yoder



More information about the devicetree-discuss mailing list