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...
Thanks,
jdl
More information about the Linuxppc-dev
mailing list