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
