DTC memory reserve question

Jon Loeliger jdl at freescale.com
Wed Jul 20 01:29:20 EST 2005

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...


More information about the Linuxppc-dev mailing list