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