Date: Mon, 24 Sep 2001 10:54:02 -0700 From: Kent Stewart <kstewart@owt.com> To: Kenneth Wayne Culver <culverk@wam.umd.edu> Cc: John Merryweather Cooper <john_m_cooper@yahoo.com>, Mike Bruins <bruins@hal9000.net.au>, freebsd-questions@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG Subject: Re: health chip driver - vt82c686 - finishing off Message-ID: <3BAF733A.D243C6@owt.com> References: <Pine.GSO.4.21.0109241241550.1253-100000@sun09pg2.wam.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Kenneth Wayne Culver wrote:
>
> It seems that xmbmon is only in the ports if you're running -CURRENT...
You aren't using a current ports-all. I just installed it in 4.4-stable.
Kent
>
> Ken
>
> On Mon, 24 Sep 2001, John Merryweather Cooper wrote:
>
> >
> > On 2001.09.24 07:11 Mike Bruins wrote:
> > > Hello,
> > >
> > > I have put together most of a device driver for the health
> > > monitoring chip via technologies vt82c686 function 4 (PCI 3057:1106).
> > > All the kernel loadable module, device probe/attach code,
> > > temperature/fan/voltage conversion routines are there.
> > > I can read the device registers for PCI Vendor/Device, chip enable,
> > > class, subclass etc.
> > >
> > > Basically what I am not able to do is read the values
> > > hardware offset registers. The call to bus_alloc_resource
> > > fails (returns null) and I can't work out why.
> > >
> > > If anyone could please help with the following questions:
> > >
> > > 1. It looks like bus_alloc_resource() gets resources from it's parent
> > > device driver.
> > > Does the vt82c686 function 4, talk I2C to it's parent to get
> > > resources?
> > > If so, do I need a device driver for this parent?
> > > Anyone know it's PCI vendor/device chip code?
> > >
> > > 2. Perhaps I am going down the wrong path. Ideas, example code
> > > references appreciated. I have looked at many examples of
> > > code, but can't work out what is relevent/required for the 686a/b,
> > > in terms of resources and how it communicates.
> > >
> > > 3. The bit of my code that is actually failing is below.
> > > Like I said, I am pretty much sure the code to this point
> > > is correct and working as I can print any of the registers
> > > and they have sane values.
> > >
> > > I have tried every conbination I can think of for hwm_io_base_reg
> > > and the type of resource I am asking for.
> > > I have read the 686a.pdf file many times, tried all I can think of.
> > > According to the 686a.pdf the data size is 0x80 bytes.
> > >
> > >
> > > via->mem_rid = hwm_io_base_reg;
> > > via->res_mem = bus_alloc_resource(dev, SYS_RES_MEMORY,
> > > &(via->mem_rid),
> > > 0ul, ~0ul, 0x80, RF_ACTIVE);
> > > if (!via->res_mem) {
> > > device_printf(dev, "could not map memory\n");
> > > goto bad;
> > > }
> > > via->memt = rman_get_bustag(via->res_mem);
> > > via->memh = rman_get_bushandle(via->res_mem);
> > >
> > > Ultimately I need the memt and memh values, so I can make calls
> > > like:
> > >
> > > val = bus_space_read_1(via->memt, via->memh, regno);
> > >
> > >
> > >
> > > My system:
> > > Motherboard: Gigabyte 6vxd7
> > > CPU : dual 866
> > > OS : 4.3-RELEASE free-bsd
> > >
> > > I have altered chip_match() so no driver is loaded at boot time for
> > > 0x30571106.
> > >
> > > chip0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x06911106
> > > rev=0xc4 hdr=0x00
> > > pcib1@pci0:1:0: class=0x060400 card=0x00000080 chip=0x85981106
> > > rev=0x00 hdr=0x01
> > > isab0@pci0:7:0: class=0x060100 card=0x06861106 chip=0x06861106
> > > rev=0x22 hdr=0x00
> > > uhci0@pci0:7:2: class=0x0c0300 card=0x12340925 chip=0x30381106
> > > rev=0x10 hdr=0x00
> > > uhci1@pci0:7:3: class=0x0c0300 card=0x12340925 chip=0x30381106
> > > rev=0x10 hdr=0x00
> > > none0@pci0:7:4: class=0x0c0500 card=0x00000000 chip=0x30571106
> > > rev=0x30 hdr=0x00
> > > sym0@pci0:9:0: class=0x010000 card=0x00000000 chip=0x00201000
> > > rev=0x01 hdr=0x00
> > > sym1@pci0:9:1: class=0x010000 card=0x00000000 chip=0x00201000
> > > rev=0x01 hdr=0x00
> > > rl0@pci0:10:0: class=0x020000 card=0x0027a0a0 chip=0x813910ec
> > > rev=0x10 hdr=0x00
> > > pcm0@pci0:13:0: class=0x040100 card=0x13711274 chip=0x13711274
> > > rev=0x08 hdr=0x00
> > > none1@pci0:14:0: class=0x040100 card=0x20601458 chip=0x13711274
> > > rev=0x07 hdr=0x00
> > > none2@pci1:0:0: class=0x030000 card=0x00000000 chip=0x002c10de
> > > rev=0x15 hdr=0x00
> > >
> > >
> > >
> > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > with "unsubscribe freebsd-hardware" in the body of the message
> > >
> >
> > xmbmon works great (for temperature sorts of things) on my VIA 686B.
> > You
> > might want to take a look at that code (it's in ports).
> >
> > --
> > jmc
> >
> > MacroHard -- the perfection of form over
> > substance, marketing over
> > performance, and greed over
> > design . . .
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-questions" in the body of the message
> >
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message
--
Kent Stewart
Richland, WA
It is hard to believe you are soaring with Eagles (las águilas)
when you accept SPAM like a mouse (el ratón).
mailto:kbstew99@hotmail.com
http://kstewart.urx.com/kstewart/index.html
FreeBSD News http://daily.daemonnews.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BAF733A.D243C6>