Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Nov 1996 00:03:02 +0100
From:      se@zpr.uni-koeln.de (Stefan Esser)
To:        smp@csn.net (Steve Passe)
Cc:        freebsd-hackers@freebsd.org (FreeBSD hackers), chuckr@glue.umd.edu (Chuck Robey), joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Subject:   Re: motherboard chipset identification
Message-ID:  <199611082303.AAA05902@x14.mi.uni-koeln.de>
In-Reply-To: <199611082240.PAA02599@clem.systemsix.com>; from Steve Passe on Nov 8, 1996 15:40:08 -0700
References:  <199611082240.PAA02599@clem.systemsix.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Steve Passe writes:
> Hi,
> 
> > I need to be able to tell which chipset is being used on a motherboard
> > during the boot process (Neptune, Triton, Natoma, etc.)  Could someone
> > point me towards the code in the kernel that determines this info???
> 
> Several people have pointed out sys/pci/pcisupport.c.  This is a starting
> point, but the chips of interest to me are non-PCI things, like system
> controller chips (combo chips that are typically part of the  MB "chip-set"
> and contain the timers, icus, etc.)  The IO APIC is sometimes contained

Hmmm, but did you take a look at "pcisupport.c" ?
Check out the code that dumps the support chip registers
if "bootverbose" is true ...

> in these, and comes in different flavors that need slightly different
> programming techniques.  My specific problem is that you need (so the manuals
> claim) to access the IOSELREG via byte writes on some flavors, but DWORD writes
> on others.  so its a catch-22 situation, I need to know which flavor it is
> before I can access it, but I can't safely probe it for clues, cause I don't
> know which flavor it is.  (thank you very much, #$&^*&# Intel)

What does it depend on ?

Why can't you probe for it ? 
(Does a probe lock up the system if the wrong flavor is assumed ?)

> The closest I will come is by knowing what types of other system chips
> are used, then deducing which IO APIC is most likely to be present from that.
> The MP spec defines boards without PCI busses, so I need a more general
> mechanism.
> 
> Note that it might not be quite this problematic, all I know right now is we
> have flavors that aren't working, and this appears to be a likely reason.

Regards, STefan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611082303.AAA05902>