From: Jun Sun <jsun@mvista.com>
To: Matthew Dharm <mdharm@momenco.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>, jsun@mvista.com
Subject: Re: LOADADDR and low physical addresses?
Date: Fri, 6 Sep 2002 13:53:24 -0700 [thread overview]
Message-ID: <20020906135324.D1382@mvista.com> (raw)
In-Reply-To: <NEBBLJGMNKKEEMNLHGAIAENHCIAA.mdharm@momenco.com>; from mdharm@momenco.com on Fri, Sep 06, 2002 at 01:04:28PM -0700
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
next prev parent reply other threads:[~2002-09-06 21:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-06 20:04 LOADADDR and low physical addresses? Matthew Dharm
2002-09-06 20:53 ` Jun Sun [this message]
2002-09-06 21:13 ` Matthew Dharm
2002-09-06 21:42 ` Jun Sun
2002-09-09 18:17 ` Maciej W. Rozycki
-- strict thread matches above, loose matches on Subject: below --
2002-09-06 22:35 Manoj Ekbote
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020906135324.D1382@mvista.com \
--to=jsun@mvista.com \
--cc=linux-mips@linux-mips.org \
--cc=mdharm@momenco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.