DTC memory reserve question
Jon Loeliger
jdl at freescale.com
Tue Jul 19 06:25:31 EST 2005
So, when the Device Tree Compiler lays down a memory
reserve table into an assembly file, it always adds
a reserved region covering the whole DT blob itself.
That is, it does this:
.balign 8
.globl dt_reserve_map
dt_reserve_map:
_dt_reserve_map:
.long 0, _dt_blob_start
.long 0, _dt_blob_end - _dt_blob_start
.llong 0
.llong 0
Naturally, that yields System.map entries like this:
c0013988 t _dt_blob_start
c0013988 T dt_blob_start
c0013988 t _dt_header
c0013988 T dt_header
c00139b0 t _dt_reserve_map
c00139b0 T dt_reserve_map
c00139d0 t _dt_struct_start
c00139d0 T dt_struct_start
c0013df0 t _dt_strings_start
c0013df0 T dt_strings_start
c0013df0 t _dt_struct_end
c0013df0 T dt_struct_end
c0013f05 t _dt_blob_end
c0013f05 T dt_blob_end
Notice that these are 0xC-gazillion addresses.
And way over here in the Ben H documentation, the memory
reserve map is described as containing physical addresses:
- off_mem_rsvmap
This is an offset from the beginning of the header to the start
of the reserved memory map. This map is a list of pairs of 64
bits integers. Each pair is a physical address and a size. The
list is terminated by an entry of size 0. This map provides the
kernel with a list of physical memory areas that are "reserved"
and thus not to be used for memory allocations, especially during
early initialisation.
Uh, so here's my dilemma: I can't just pa() all the addresses
that come in from the memreserve table, can I? They should
already _be_ physical, right? We aren't going to be able to
handle a mix of them without a flag or test or something?
jdl
More information about the Linuxppc-dev
mailing list