From: Ralf Baechle <ralf@linux-mips.org>
To: Matthew Dharm <mdharm@momenco.com>
Cc: Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: PATCH: linux_2_4: add support for the Ocelot-G board
Date: Tue, 3 Sep 2002 00:03:13 +0200 [thread overview]
Message-ID: <20020903000313.A23265@linux-mips.org> (raw)
In-Reply-To: <20020902134053.A28347@momenco.com>; from mdharm@momenco.com on Mon, Sep 02, 2002 at 01:40:53PM -0700
On Mon, Sep 02, 2002 at 01:40:53PM -0700, Matthew Dharm wrote:
> Hrm... okay... first question, where do I get the 64-bit toolchain? Right
> now, I'm using HJ's toolchain RPMs (from over a year ago -- I should update
> those).
ftp.linux-mips.org:/pub/linux/mips/crossdev/.
> Second, what about all those nifty extras? Things like the fact that
> kseg0/1 (well, their 64-bit equivalents) are now larger (how big are they,
> anyway)
Giant. The entire XKPHYS space has a size of 60 Exabyte. Three bits of
the address specify one of the caching modes. That leaves punny 59 bits
or 512 Petabyte for each of these segments. And simply because that's
still a shitload for most applications (unless you want to mmap a decent
sized disk array or so ...) most MIPS implementations actually only use
a fraction of this space; 1TB is typical but the R10000 family actually
supports 16TB and I guess another extension will be due soon ...
> so they can map all of my SDRAM as well as most (all?) of my
> I/O space... I guess for that I need to reprogram all my address decoders,
> and then that sort of thing must be what the arch/mips64/* stuff is for.
I've actually eleminated all board support code from arch/mips64.
The way Ocelot support was done for 32-bit kernel was mapping all RAM
contiguously starting from address 0. That will be the right thing for
64-bit as well. Just all the highmem crap goes away and the ioremap code
becomes a trivial 1:1 mapping.
> Yes? No? Or am I smoking something too strong again?
As long as you don't inhale ;-)
> The 64/32 mixed-mode linux is certainly of some interest to our customers,
> but full 64-bit is really where the demand is. Is there anything that a
> non-compiler guy can do to help the effort along?
The lion part of the effort will be the toolchain for this round. Once
that part is done we'll have to port libc at which point rebuilding code as
N32 or N64 should have become trivial.
Ralf
prev parent reply other threads:[~2002-09-02 22:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <NEBBLJGMNKKEEMNLHGAIKEJOCIAA.mdharm@momenco.com>
2002-09-02 17:00 ` PATCH: linux_2_4: add support for the Ocelot-G board Ralf Baechle
2002-09-02 19:38 ` Matthew Dharm
2002-09-02 20:46 ` Ralf Baechle
2002-09-02 20:40 ` Matthew Dharm
2002-09-02 22:03 ` Ralf Baechle [this message]
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=20020903000313.A23265@linux-mips.org \
--to=ralf@linux-mips.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox