On Tue, 2 Jun 1998, Chris G. Demetriou wrote:

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

I agree. Strong ARM support was added before the DNARD existed.
Given that PCI drivers would have to be written no matter what OS was
ported to the Netwinder porting NetBSD would not have been difficult.
Anyway NetBSD already has lots of PCI drivers that are bus spaced and thus
easy to utilise on multiple platforms.

> 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?),
Yep.

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

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

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

I'm currently running NetBSD/arm32 on several PCI based machines I can say
that one that CPU-PCI bridge support was in place lots of cards just
worked. e.g. ethernet, SCSI etc.

> 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.
Sounds like it to me as well.

Cheers,
				Mark