Re: NetBSD for BeBox?

[Wolfgang Solfrank <ws%kurt.tools.de@localhost>]

Sorry for not responding earlier, but I was out of town over the weekend
(and wasn't even on this mailing list until today :-)).

While quite good basic description of the ideas of the PowerPC port was
given by Jason, let me fill in some details (I'm responding to several
posts at once here):

> NetBSD/powerpc was done by Wolfgang Solfrank.  It's in the tree, and
> currently supports the Firepower systems (a PReP-ish 604 box).
> The theory is that NetBSD/powerpc will run right now on any 604
> with OpenFirmware.  The reason for this is that OpenFirmware is used
> to do all i/o under NetBSD/powerpc at this time.

Actually it currently runs on 603 and 604 boxen.  I've already used
it on a Motorola Ultra board with 603 with a pre-release of their
OpenFirmware implementation.  Most of the two day work of adapting
to this machine was the difference between 604 and 603.  Especially
the code to handle software tlb reload that is in the 603(e) user manual
is quite buggy.

> In my mind, the goal for NetBSD on PowerPC systems would be to have
> as many different PowerPC systems as possible run under the "NetBSD/powerpc"
> banner - Essentially, this means any PowerPC system that has OpenFirmware.

Exactly.  And let me add that the existing standards for PowerPC systems,
that is PReP and CHRP/PPCP both mandate that systems must have OpenFirmware.

> Now, it's my understanding that the BeBox doens't have OpenFirmware (please
> correct me if I'm wrong).  So, NetBSD/powerpc, with the structure I'd like
> to see, won't run on them ... they'd require "NetBSD/be", or something.
> Now, NetBSD/be could pull _quite a lot_ of code from the "generic PowerPC"
> area of the source tree; essentially, trap handling, most of locore
> (except initialization), pmap (except for pmap bootstrap, probably), etc.
> This would save a lot of work doing a port to the BeBox.

This is the idea for PowerPC machines that don't have OpenFirmware.
To make this possible, I did (try to) separate out the code that depends
on OpenFirmware from the rest of the code into its own file.  This
(hopefully) allows sharing of the rest of the code with other ports.
Something similar to the existing sys/arch/m68k, but with a real
working implementation in this directory, too, that would run on
(eventually) most PowerPC machines.

> SMP is a goal for NetBSD in general... We'd like it for PCs, SPARCs,
> Alphas, PowerPCs, etc.  The FreeBSD SMP code, the last I looked at it,
> needed significant work to be "generic".

Note that the FirePower machine I used to develop this on does have
two 604s :-).

> Well, NetBSD/powerpc does run multi-user, and it is in the post-1.2
> current sources, so it should be available for supping Real Soon Now.

OK, leave me a few days to clean up the user level code before checking
it in.

> Also, I've been told that the OpenFirmware Macs don't use ELF for the
> boot program format, but use XCOFF instead.  This shouldn't be that
> big of a deal; just write a small program that converts a.out (which
> is currently the executable format used by NetBSD/powerpc) to XCOFF.
> (Something similar is currently used for ELF.)

This is the one thing that needs to be written to make NetBSD/powerpc
work on current PCI Macs.  The other thing that's probably neccessary
is the modification of the disklabel code, as it currently assumes
the existance of a MBR on disks, just like standard PCs.

Unfortunately, I don't have access to any PowerMac (let alone PCI
based ones).

> Perhaps a way to unify all these things is to build second stage boot
> loaders in the appropriate formats. (The idea that they'd have open
> firmware but NOT use one boot format seems mildly sick...)

Hmm, I don't think that it's appropriate to support all these object file
formats in the linker just for the boot code.  Apart from that, the
standard ELF format used for booting on PReP and CHRP/PPCP machines needs
a special notes section anyway, that probably doesn't make sense to
include in other object modules.

While your remark about the different boot formats is quite justified
let me say that the initial reason for vendors to choose a standard
firmware wasn't to allow the use of the same OS on different machines,
but that they would become able to use standard hardware without the
need to provide appropriate driver code in their machine's firmware.

Bye,
Wolfgang
-- 
ws%TooLs.DE@localhost     (Wolfgang Solfrank, TooLs GmbH)       +49-228-985800