Re: PATCH: linux_2_4: add support for the Ocelot-G board

Re: PATCH: linux_2_4: add support for the Ocelot-G board

[Ralf Baechle]

On Tue, Aug 27, 2002 at 04:00:51PM -0700, Matthew Dharm wrote:

> The attached two patches and small tar archive (I can't figure out how
> to make CVS do the equivalent of a diff -N) add support to the 2.4
> branch for the Ocelot-G board (RM7000 processor with GT-64240 bridge).
> 
> I've gone ahead and created an linux/arch/mips/momenco directory, as
> we've got another board almost ready to add to the repository (the
> Ocelot-C and -CS), and we've got concrete plans to port to our
> RM9000x2 board (Jaguar), which has at least a couple of varieties.  I
> figured getting all this organized under one directory would be wise.
> 
> Presuming this gets accepted, there are a few more patches in this
> series... some updates to the MTD probing address for these boards, as
> well as a new ethernet driver for the GT-64240 on-board ethernet.
> 
> Ralf, please apply these to the CVS repository.

As a note - most boards are now selectable for the 32-bit and 64-bit kernel.
For a board like the Ocelot having a 64-bit kernel certainly makes sense ...

   Ralf

Re: PATCH: linux_2_4: add support for the Ocelot-G board

[Matthew Dharm]

Oh, I agree that a 64-bit kernel makes sense.  I'm just not sure what is
needed to get from where I am now to where I want to be.

There is _much_ interest from our customers for 64-bit linux.  Especially
if the toolchain catches up so that we can have 64-bit userspace.

Anyone have some quick pointers on how to get from here to there?

Matt

On Mon, Sep 02, 2002 at 07:00:38PM +0200, Ralf Baechle wrote:
> On Tue, Aug 27, 2002 at 04:00:51PM -0700, Matthew Dharm wrote:
> 
> > The attached two patches and small tar archive (I can't figure out how
> > to make CVS do the equivalent of a diff -N) add support to the 2.4
> > branch for the Ocelot-G board (RM7000 processor with GT-64240 bridge).
> > 
> > I've gone ahead and created an linux/arch/mips/momenco directory, as
> > we've got another board almost ready to add to the repository (the
> > Ocelot-C and -CS), and we've got concrete plans to port to our
> > RM9000x2 board (Jaguar), which has at least a couple of varieties.  I
> > figured getting all this organized under one directory would be wise.
> > 
> > Presuming this gets accepted, there are a few more patches in this
> > series... some updates to the MTD probing address for these boards, as
> > well as a new ethernet driver for the GT-64240 on-board ethernet.
> > 
> > Ralf, please apply these to the CVS repository.
> 
> As a note - most boards are now selectable for the 32-bit and 64-bit kernel.
> For a board like the Ocelot having a 64-bit kernel certainly makes sense ...
> 
>    Ralf

-- 
Matthew Dharm                              Work: mdharm@momenco.com
Senior Software Designer, Momentum Computer

Re: PATCH: linux_2_4: add support for the Ocelot-G board

[Ralf Baechle]

On Mon, Sep 02, 2002 at 12:38:50PM -0700, Matthew Dharm wrote:

> Oh, I agree that a 64-bit kernel makes sense.  I'm just not sure what is
> needed to get from where I am now to where I want to be.
> 
> There is _much_ interest from our customers for 64-bit linux.  Especially
> if the toolchain catches up so that we can have 64-bit userspace.

The toolchain stuff is being worked on.  Hold your breath but cheat every
once in a while when your face turns blue ;-)

> Anyone have some quick pointers on how to get from here to there?

The basic receipe is easy.  The 64-bit kernel has a binary compatibility
layer that allows you to use 32-bit software with no changes.  Just use
a 64-bit compiler, for now that's probably still the egcs 1.1.2 /
binutils 2.9.5 based mips64-linux / mips64el-linux tool chain.  Using your
old .config file do a "make ARCH=mips64 oldconfig" etc.  The resulting
binary file will be a 32-bit ELF file so you can just feed that to your
firmware for booting as usual.  Problems may be hit along the way ;-)

  Ralf

Re: PATCH: linux_2_4: add support for the Ocelot-G board

[Matthew Dharm]

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).

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) 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.
Yes? No?  Or am I smoking something too strong again?

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?

Matt

On Mon, Sep 02, 2002 at 10:46:15PM +0200, Ralf Baechle wrote:
> On Mon, Sep 02, 2002 at 12:38:50PM -0700, Matthew Dharm wrote:
> 
> > Oh, I agree that a 64-bit kernel makes sense.  I'm just not sure what is
> > needed to get from where I am now to where I want to be.
> > 
> > There is _much_ interest from our customers for 64-bit linux.  Especially
> > if the toolchain catches up so that we can have 64-bit userspace.
> 
> The toolchain stuff is being worked on.  Hold your breath but cheat every
> once in a while when your face turns blue ;-)
> 
> > Anyone have some quick pointers on how to get from here to there?
> 
> The basic receipe is easy.  The 64-bit kernel has a binary compatibility
> layer that allows you to use 32-bit software with no changes.  Just use
> a 64-bit compiler, for now that's probably still the egcs 1.1.2 /
> binutils 2.9.5 based mips64-linux / mips64el-linux tool chain.  Using your
> old .config file do a "make ARCH=mips64 oldconfig" etc.  The resulting
> binary file will be a 32-bit ELF file so you can just feed that to your
> firmware for booting as usual.  Problems may be hit along the way ;-)
> 
>   Ralf

-- 
Matthew Dharm                              Work: mdharm@momenco.com
Senior Software Designer, Momentum Computer

Re: PATCH: linux_2_4: add support for the Ocelot-G board

[Ralf Baechle]

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