Re: fastest UltraSPARC hardware NetBSD runs on?

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Oct 29, 2008, at 4:58 AM, Jochen Kunz wrote:

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

Except that none of it is MD.

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

Agreed.

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

Well, some (many?) i2c devices, especially temperature monitors,  have  
chip ID registers these days, many even in standardized places. So all  
it takes are a couple reads. Also, most i2c chips have hardwired  
addresses ( some can switch between two or four different ones by  
wiring some pins to ground or not ) so no i2c driver would have to  
probe all over the place. To screw things up you'd need to have a  
screwy chip that's allergic to register reads at an address where your  
driver expects its own. No i2c chip I know of would do anything funny  
when you try to read its ID registers, even if it doesn't have any.  
They'd either return bogus or nothing but that's it.

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

I agree completely, which is why I added just that to ki2c long ago.

have fun
Michael