Re: DTC memory reserve question

[Jon Loeliger <jdl@freescale.com>]

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