Subject: Re: Corel's NetWinder Network computer. What do you think?
To: Michael C. Richardson <mcr@sandelman.ottawa.on.ca>
From: Chris G. Demetriou <cgd@NetBSD.ORG>
List: netbsd-help
Date: 06/02/1998 11:22:31
[ This message should not be in any way construed as an official (or
even unofficial) statement by Digital Equipment corporation (my
employer), or anything other than my personal opinion.  If you have a
problem with it, take it up with me. ]

>   Corel ported Linux to their Netwinder because of issues with 
> the way NetBSD/StrongARM relied on the the OpenFirmware. Unless you
> want to implement OpenFirmware for the Netwinder, or write a whole
> bunch of PCI drivers for the chips that the Netwinder uses, you
> won't see NetBSD on it.

That's ridiculous.  If they actually claimed that, they looked before
they leaped, or didn't know what they were looking at.


First of all, NetBSD/arm32 has included StrongARM support for a while.
Until very, very recently (as in, until the last few weeks),
NetBSD/arm32 did not include any OFW-related code whatsoever.
NetBSD/arm32 did not _support_, let alone rely on, OFW until recently.

Second, in the "Shark" development bits that we at DEC created, we do
have and use OFW support, but its use is nothing like that alleged in
the quoted bit above.  It is possible to build a "generic" kernel
which relies on OpenFirmware drivers, and indeed that can be a useful
thing to do.  (For a while, during the initial bootstrapping process,
that was all that was possible with the Shark development bits.)
However, the correct evolution of that situation is to do what the
group doing the Shark did (before I got here, I might add): switch to
native drivers.  All of the "real" device drivers for devices in the
Shark (serial, parallel, audio, keyboard, video, and mouse, IDE/ATAPI,
network, and PCI if we actually used our PCI for anything) are native
drivers.  There are generic drivers which implement the 'busses' that
OpenFirmware's non-leaf nodes represents, but other than those, all
drivers are 'native' and run with native performance.

Third, having OpenFirmware ported to a box isn't a big deal.  You need
system firmware, and you have to pay _someone_ to create it for you.
Given that, you might as well pay FirmWorks to port OpenFirmware.  By
doing so, you get a great firmware environment and the help and
cooperation of a wonderful development team who are experienced in and
helpful with system debugging, in addition to firmware design.


In summary, the situation with NetBSD/arm32 and OpenFirmware is:

(1) NetBSD/arm32 has supported StrongARM processors for a while,
independent of OpenFirmware (right?),

(2) NetBSD/arm32 didn't support, let alone use, OFW _at all_ until
recently,

(3) NetBSD/arm32 can still run on systems without OFW (and indeed
those systems probably far out number OFW-capable ARM systems), and

(4) Even on systems with OFW, unless you want a completely generic
OFW-driver-only-using kernel, OFW is only used to help booting and
configuration.


The issue of PCI driver support is a separate one.  Every PCI system
out there has to cope with wacky PCI devices and driver support for
them.  PCI video, PCI ethernet, etc.  Driver support in the operating
system is mostly orthogonal to OpenFirmware.  I say "mostly" rather
than completely, because if you have OFW and can use the firmware
drivers, having OFW can mean that you can _delay_ writing drivers
until you actually need to.  (E.g. I've seen cases where people want
to bring up a generic OFW-driver-using kernel on fresh hardware that
OFW, and only OFW, has just been ported to.)  Given that NetBSD has
one of the better PCI device infrastructures out there, and has had
extensive work to allow easy porting of existing drivers to a new bus
(the PCI bus), I'd say that in terms of writing portable native
drivers, it's probably the best choice.


In other words, if that was their excuse, I'd say, "They ported linux
because somebody sold them on linux and now they're trying to justify
it after the fact."  They may have other, more valid reasons, but that
statement about why they didn't use NetBSD is simply nonsense.



cgd
[ This message should not be in any way construed as an official (or
even unofficial) statement by Digital Equipment corporation (my
employer), or anything other than my personal opinion.  If you have a
problem with it, take it up with me. ]