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