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>