Yes, the having two devices at the same physical address might be a
problem, but one I _might_ be able to work around. Not only do I have
a large bank of SDRAM, but I also have a small bank of on-chip SRAM.
So I'm thinking that the map will go (starting from 0) like this:
on-chip SRAM, control registers, main memory
And this is where I think the add_memory_region() magic might need to
happen. Do I need to add the on-chip SRAM and control registers using
add_memory_region()? Is it going to be okay to have a large and
mis-aligned bank of SDRAM?
Questions abound. Needless to say, I'm going to have some choice
words with the chip designers over this...
Matt
--
Matthew D. Dharm Senior Software Designer
Momentum Computer Inc. 1815 Aston Ave. Suite 107
(760) 431-8663 X-115 Carlsbad, CA 92008-7310
Momentum Works For You www.momenco.com
> -----Original Message-----
> From: Jun Sun [mailto:jsun@mvista.com]
> Sent: Friday, September 06, 2002 1:53 PM
> To: Matthew Dharm
> Cc: Linux-MIPS; jsun@mvista.com
> Subject: Re: LOADADDR and low physical addresses?
>
>
> On Fri, Sep 06, 2002 at 01:04:28PM -0700, Matthew Dharm wrote:
> > So, I've got an interesting problem... which has forced
> me to look at
> > the use of the LOADADDR variable in the Makefile, and try
> (quickly) to
> > brush up on my linker scripting...
> >
> > Basically I've got a processor with on-chip registers
> that need to be
> > located in the first 512MByte of _physical_ address. To
> make things
> > difficult, they cannot be re-located once placed (configuration is
> > done by a hardware config stream at reset). It's only 16KBytes of
> > address, but since I recall that linux on mips can't
> (well, probably
> > can't) handle discontiguous memory maps (we discussed this about a
> > year ago, I think), I was looking for a good place to put them.
> >
> > Now, I think my problems are solved if the LOADADDR
> variable works the
> > way I think it does -- that the kernel loads at that
> address, and only
> > uses memory from that point upwards. So, if my LOADADDR is
> > 0x80100000, then the first 0x100000 won't get used. Of
> course, the
> > exception vectors are there, but that doesn't take up
> that much space.
> > So there should be a chunk of address space I can use for other
> > things, like this register bank.
> >
> > Yes? No? Is my understanding even close?
> >
>
> That is right.
>
> The only catch is that if you make LOADADDR very high (as
> in the case
> system ram starts at a high address), the kernel page
> table will be very high too. It starts from phys address 0.
>
> Also if you map your control registers at near-zero phy
> address, don't you
> also have system RAM there too? Normally it is not ok to have two
> devices decoded at the same phys address.
>
> > P.S. Of course, if this is right, then I need to figure out the
> > proper/best way to use the add_memory_region() function....
>
> Unless I misunderstand something here, I don't think you need
> to mess with add_memory_region().
>
> Jun
>
|