Re: fastest UltraSPARC hardware NetBSD runs on?

[Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost>]

On Tue, 28 Oct 2008 17:44:21 -0400
Michael <macallan%netbsd.org@localhost> wrote:

> >  With your method you will have to reinvent the
> > bus attachment wheel over and over again in several places for many
> > ports and devices.
> No, I can use the exact same thing over and over again, just need to  
> pull a few lines out of ki2c and put then into a header.
You still need a separate bus attachment for every port and a separate
frontend for every driver, that uses this MD i2c bus. With the OpenBSD
method all you have to do is supply an optional enumeration function to
the MI i2c bus code.

But lets defer this discussion until we are at 5.99.0 to tech-kern.

> > OK. I'll rip out the direct configuration stuff and commit the plain
> > device drivers. We'll see more once we are at 5.99.0..
> We can already wildcard i2c addresses - if your hw can be probed
> ( as in - has chip ID registers of some sort ) there really isn't
> much of a problem.
Probing is a bad idea. I remember back in the NetBSD 1.3 to 1.4 days,
when booting NetBSD on a VAXstation 4000/90 caused permanent damage to
the hardware: A probe routine for a device, that can't exist on a
VAXstation 4000/90, accidently issued the right sequence of read /
write commands to overwrite part of the FLASH boot ROM. Fortunately the
machine was still functional with the damaged FALSH ROM. But it
complained at every POST about a PROM checksum mismatch and disabled
auto-boot. It took years until someone dug out a FLASH ROM update image
out of the reminders of DEC, as reflashing the firmware was the only way
to repair the damage.

If the firmware _knows_ where devices are located, by all means, use
this information instead fscking the hardware and _guess_ the existence
of devices.
-- 


tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/