Re: Porting to IBM Risc 6000

[Matt Thomas <matt%3am-software.com@localhost>]

At 07:34 AM 8/13/2002, Jochen Kunz wrote:
> On Sun, Aug 11, 2002 at 12:22:05PM -0700, Matt Thomas wrote:
>
> > My inclination is to have to move to a rs6k port and have
> > GENERIC and GENERIC64 for 32bit and 64bit PPC platforms.
> This would require a 32 bit userland, as 64 bit applications can't
> run on a 32 bit machine and 32 bit applications will run in some
> kind of emulation when a 64 bit kernel is running?

Yes it would.  But one advantage to this is that 32-bit programs
are usually smaller and use less memory than their 64-bit counterparts.
Note that more Solaris/SPARC program are 32bits even though the
kernel is 64bits (for UltraSPARC).

> (Sorry for this questions. I don't have The Clue (C) (R) (TM), but
> I wane learn more about all this OS internas. This is the reason
> for my interrest in getting the rs6k port going: Learning by doing.)
>
> > The real question is do we want a single kernel which can work
> > on 32bit and 64bit platforms?
> Stupid question: How can this work? A single Kernel for 32 and 64 bit
> machines? Wouldn't the 32 bit compatibility force compromises that we
> probably don't want? Like a 4GB address space limit?

All 64-bit PPC CPUs can run 32-bit PPC code since it the same
instructions (you just aren't executing any 64 bit instructions).
The real issue is that the 32bit kernel needs to deal >32bit physical
addresses.  But some 32bit PPC CPUs (Motorola MPC745x and IBM 405GP)
already can deal with 36bit physical addresses so when/if we ever
support those physical address models, we will need 64bit physical
address support even in 32bit kernels.

> > The most significant thing is to create a RTAS module with the
> > various functions we need.
> As I understand the CHRP spec and the CHRP to OFW binding RTAS is a
> CHRP speciffic extension to OFW, so there is no RTAS already in NetBSD
> (macppc e.g)?

Correct, no RTAS in macppc.  Though, just like PReP, we can write
a RTAS work alike which has the intimate knowledge of macppc machines.

The advantage of this is that we start supporting more machines out
of a single "port".  chrp, prep, ofppc, macppc could all be combined
into one port (for example).

> > Now if we do it right, there could
> > be an RTAS work-alike implemented for PReP.
> I had a brief look into the PReP spec. There is also some hardware
> abstraction called RTAS. But the PReP RTAS is hardware _and_ OS
> dependend. The PReP spec "defines the functions that must be abstracted,
> but it does not define the interface to the operating system nor does
> it define the way the functions are collected into usable services."
> [...] "Initial versions of the RTAS are distributed by an operating
> system vendor." I.e. we have to write our own PReP RTAS. We are free
> to choose an OS interface for it so (perhaps) we can make it CHRP
> compatible.

That would make the most sense.

> > But the most significant difference is that one uses a PC'ish
> > PNP database and CHRP uses OFW.
> Next stupid question: Can't this be solved by attaching different busses?

It could and will.  but the point to use the device configuration
information that the firmware gives us, not to do self-discovery
(unless we really really have to).

--
Matt Thomas               Internet:   matt%3am-software.com@localhost
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message