All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@oss.sgi.com>
To: John Tobey <jtobey@john-edwin-tobey.org>
Cc: linux-mips@oss.sgi.com
Subject: Re: 64-bit on Cobalt?
Date: Mon, 9 Apr 2001 03:54:53 +0200	[thread overview]
Message-ID: <20010409035453.B774@bacchus.dhis.org> (raw)
In-Reply-To: <20010408184241.A3443@john-edwin-tobey.org>; from jtobey@john-edwin-tobey.org on Sun, Apr 08, 2001 at 06:42:41PM -0400

On Sun, Apr 08, 2001 at 06:42:41PM -0400, John Tobey wrote:

> The CPU is a QED RM5231 (CONFIG_NEVADA) 150MHz.  May I assume that
> nobody has run a 64-bit kernel on this thing?  The RaQ has no video
> card but a serial console, PCI, IDE, Ethernet, and special LEDs, panel
> buttons, and LCD display.  If I can get a 64-bit kernel to boot and
> prove its existence through any of these devices, I will be drunk with
> power.

So far the only supported machine by the mips64 kernel is the SGI Origin
200 / 2000 series.

> The reason I want 64 bits is that I (a) want a challenge, (b) plan to
> write an application that uses a sparse address space (40 bits is
> better than 31), (c) plan to outlive the 31-bit time_t, and (d) am
> p.o.ed at having bought the thing based on misleading advertising that
> mentioned a 64-bit processor but not the 32-bit OS.

> Big/little endian macht nichts.  I guess big will be easier, and I'm
> not concerned with running any existing 32-bit binaries.

Go for little endian because the firmware is little endian; supporting
``other-endian'' for userspace would be unecessary extra pain.  We already
have suport for 32-bit binaries in the 64-bit kernel; in fact ALL
software we run on 64-bit kernels is 32-bit.

32-bit wasn't only the easy thing to do - it's also the more efficient
thing for most software which doesn't need 64-bit registers or 64-bit
address space.  For a system with a dog slow 32-bit memory bus such as
the Qube 64-bit kernels would mean a dramatic slowdown.

I admit it's interesting though, mostly for engineering reasons, not
as a platform.

> I imagine that I would start by grafting Cobalt's peripheral support
> code from arch/mips/cobalt (now defunct) and include/asm-mips/cobalt.h
> into the mips64 tree from cvs@oss.sgi.com:/cvs/linux.

Somebody else was already working on upgrading the Cobalt kernel to 2.4.

  Ralf

  reply	other threads:[~2001-04-09  1:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-08 22:42 64-bit on Cobalt? John Tobey
2001-04-09  1:54 ` Ralf Baechle [this message]
2001-04-09  9:37   ` Carsten Langgaard
2001-04-09 16:57     ` John Tobey
2001-04-10 18:02   ` John Tobey
2001-04-12 22:06   ` 64-bit on Origin (was: 64-bit on Cobalt?) Lukas Hejtmanek
2001-04-12 23:25     ` Ralf Baechle
2001-04-12 22:50       ` Lukas Hejtmanek
2001-04-13  0:48         ` Ralf Baechle

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=20010409035453.B774@bacchus.dhis.org \
    --to=ralf@oss.sgi.com \
    --cc=jtobey@john-edwin-tobey.org \
    --cc=linux-mips@oss.sgi.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.