DTC memory reserve question

DTC memory reserve question

[Jon Loeliger]

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

Re: DTC memory reserve question

[Benjamin Herrenschmidt]

On Mon, 2005-07-18 at 15:25 -0500, Jon Loeliger wrote:
> 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.

How are you getting these addresses ? You are trying to link the output
of dtc with the kernel directly ? Hrm...  That will not work for that
(and maybe a couple of other things). Might be better to link it with
the zImage wrapper...

Ben.

Re: DTC memory reserve question

[Jon Loeliger]

On Mon, 2005-07-18 at 21:08, Benjamin Herrenschmidt wrote:

> > 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.
> 
> How are you getting these addresses ? You are trying to link the output
> of dtc with the kernel directly ?

Yep.  I'm in testing mode, and wanted a QAD way to get my
initial DTC blob to the code without having to first do
wild U-Boot hackery, or downloading or flash burning or
any number of other annoying solutions. :-)

So I am not handing off r3 pointing to the blob yet.
It's just a data array assembled and linked into the kernel.
Later, when things work better, it will be r3'ed in as
per the spec, of course.

>  Hrm...  That will not work

Oddly, that is what I noticed too! :-)

>  for that
> (and maybe a couple of other things). Might be better to link it with
> the zImage wrapper...

Well, I need to u-boot this kernel into running...

Thanks,
jdl