OpenBSD Journal

Developer blog: dlg: pcfiic

Contributed by marco on from the more-sensors-coming-your-way dept.

At home I have two boxes that I do most of my code on, a Dell PowerEdge 2500 (an i386) and a Sun Netra T1 105 (a sparc64). I like working on both of them cos the architectures are so different from each other. i386 is a 32bit little-endian arch without strict alignment requirements and its cache coherent. sparc64 on the other hand is 64bit, big endian, needs strict alignment and isn't cache coherent. If I can get code working on both these boxes it is likely to work everywhere else as well.

However, they do have some hardware specific features. One thing I really love about the sparc is the lights out management on it. Turning the machine on and off via a serial cable is cool. I can't do that on the poweredge. Another thing that is different between them is the way they do hardware monitoring. The poweredge has esm, the sparc has an i2c controller. Jordan wrote code for esm and the end of last year and I ported it into the kernel, so my poweredge was happily telling me how hot it was. Unfortunately, no driver existed for the i2c bits on my netra. Until now...

I had spent some time looking around on google for hints as to what the controller was, and whether there was doco on it but never found anything. I think I just suck at searching for stuff on the internet.

Anyway, it wasn't until someone showed me how to navigate the device tree in openfirmware that i discovered that the i2c controllers node had a property called "compatible" with the value of "i2cpcf,8584". The pcf 8584 part turns out to be the name of the chip used, which is a Phillips PCF8584. Google quickly found me a pdf and the pcfiic(4) driver for this i2c controller was on its way.

Somehow Damien Miller (djm@) found out that I was making progress on sensor support for the netra and got involved. He got working on a driver for the temp sensor and we soon had some working code for the controller and for the temp sensor. Unfortunately we came up against two problems: the generic scan didnt find the device, and the temp sensor is incredibly dumb. All you can do is read values off it, but to make any sense of those values you need configuration information. Fortunately the devices location and its configuration info is available, but in openfirmware. djm's first code hardcoded this info into his driver, but that just isn't the Right Way(tm) to do things. We needed to get openfirmware more involved.

The i2c stack in openbsd is organised similairly to the scsi stack: there are drivers for controllers, a midlayer and then drivers for the i2c devices. The i2c controller is responsible for providing access to the bus, the midlayer scans the bus and brokers access to it, and the device drivers are consumers on the bus. Thanks to this layering there is am almost total separation between the i2c controller and its devices.

The generic i2c scan routine that tries to discover which devices are on the bus uses a series of heuristics, but that didn't work for us since the pcf device was unknown and outside the address ranges we scan. This problem has cropped up before in i2c land though, and the solution is to provide a custom scan routine for the midlayer to use. This was already done on sparc64 for the alipm(4) controller, but it wouldn't work with pcfiic. The alipm device presents multiple devices to openfirmware, one of which is the i2c bus. So to scan devices on alipm you have to look for its i2c bus, and then scan that bus for the devices. pcfiic just has i2c listed against it.

Our solution to this problem was to split the scan routine up into two parts, one that found the i2c bus on a pci device, and one that scans the i2c bus. alipm uses the pci one, which in turn uses the i2c one. pcfiic just uses the i2c one directly.

The other problem of getting openfirmware info down to the i2c device driver was a bit more interesting. There was no way for us to pass any info from the controller down to the devices. The reason we want to do this is so we can get an ofw node (which the i2c controllers scan routine knows about) down to the device. This is needed with the temp sensor on the netra cos the values off the device are useless without the information in openfirmware.

We ended up adding a generic cookie member to the i2c attach args that are passed from the midlayer down to the device. Because we were providing a custom scan routine from the controller to the midlayer, we were able to get it to fill in this cooke with a pointer to the ofw node.

Using both of these changes we are now able to fully probe the i2c devices and configure them according to ofw. The good thing about these changes is that theyre agnostic about the information you pass between the controller and the device, so the same mechanism can be used on macppc to pass ofw to its i2c devices. I believe that ACPI can hold information about smbus/i2c devices, so that too could be passed along.

Anyway, apart from these changes in the i2c midlayer the code for the netras i2c bits is very straightforward. If you have a Netra T1 105 or similair you should be able to see something like the following in your sysctl hw.sensors output:

hw.sensors.0=pcfadc0, temp,cpu, temp, 31.00 degC / 87.80 degF

Pretty cool isn't it?

The pcfiic driver should also work on e450s and ultra 250s. If anyone has one of these machines and is willing to work with us we can try and get some sensor action happening on those hosts as well. Contact me and we'll figure it out.

(Comments are closed)


Comments
  1. By sebastian (85.176.116.30) on

    I've already read about the i2c for sparc64 in the current changelog and since i'm looking forward to boot my netra x1 with a current snapshot. Thanks for the driver and the good read in the blog. cheers, sebastian

  2. By Venture37 (217.22.88.123) venture37 # hotmail com on www.geeklan.co.uk

    I wonder if the Ultra AXi board will work??

    Comments
    1. By Martin Reindl (62.178.75.222) martin@ on

      Unfortunately the Sun Ultra AXi board has no sensors.

  3. By Anonymous Coward (69.207.29.191) on

    you mentioned you can turn the machine on via the serial cable. mind explaining how? (i dont keep my sun blade 1000 on all the time, due to power consumption. but sometimes i am away from the machine and would like to turn it on. i can ssh into a machine which has the serial console connected to the sun blade, and would love to be able to turn it on via that). any help?

    Comments
    1. By Brad (216.138.195.228) brad at comstyle dot com on

      Sun's LOM is only available for Netra and Sun Fire series servers.

  4. By Erik Carlseen (68.6.193.220) on

    You can get a DRAC-II controller for a PowerEdge 2500 (but not a 2500SC) that gives you some out-of-band manageability. It has to go in Slot 7. My experience with DRAC leads me to believe that it was designed and built by a team of engineers cloned up from the secretly frozen DNA of Rube Goldberg, but it can swimmingly get the job done when the planets align correctly (may require sacrifice of small animal as well).

    Comments
    1. By David Gwynne (220.245.180.133) loki@animata.net on

      I actually have some DRAC-IIs and one is sitting in my 2500 right now. Unfortunately the planets haven't lined up properly yet. If you have any clues for me on how to get it working without needing to install windows I would love to hear it.

      Comments
      1. By Anonymous Coward (220.240.54.229) on

        You haven't sacrificed that small animal. A Bilby sounds about right.

        Comments
        1. By David Gwynne (220.245.180.133) loki@animata.net on

          do the chocolate ones count?

      2. By Erik Carlseen (68.6.193.220) on

        DRAC II - it even sounds like a horror movie sequel! Unfortunately, my suggestions for making it work involve "Throw the [expletive deleted] in the trash and buy a Proliant with iLO". Manageablility via http/https and telnet/ssh, with optional LDAP and client certificate authentication! True hardware remote console! Yum!

        Comments
        1. By David Gwynne (130.102.78.195) loki@animata.net on

          i'll admit the drac 2 isnt as great as it could be. i was hoping i could plug it in and it would get a dhcp lease and all would be well. perhaps i should spend more time with it and harrass dell for more info.

          anyway, from what i've heard there isnt a huge difference in the out of band management on recent i386/amd64 machines from any big vendor. all the features you listed on hps ilo are available on the drac4s from dell (we have a lot of these at work). from my tinkerings on the new sun galaxy servers, the same is true there.

          however, i still think that they all suck compared to the lom on my t105 simply because it is possible to properly work with a sparc64 using a serial console. serial consoles on i386 and amd64 are still hacks and it feels like it to me. actually, i am really looking forward to seeing what apple does when they move to intel chips on their server machines. since they appear to be going with efi instead of the bios it will be interesting to see how their serial consoles work.

          im going to keep the 2500 at the moment since it is actually a nice box (apart from the drac) and i don't have any other i386s or amd64s to work on. its hard to hack on ami if you don't have either of the two archs it works on.

  5. By Anonymous Coward (151.136.100.2) on

    sparc64 is not exactly incoherent io.
    for a full effect you need mips or hppa*...

    Comments
    1. By sthen (81.168.66.248) on

      Out of interest, do these have alignment requirements like sparc64?

      Comments
      1. By Miod Vallat (82.101.10.46) miod@ on

        grep __STRICT_ALIGNMENT /usr/src/sys/arch/*/include/endian.h will tell you which platforms have strong alignment requirements. Apart from x86/amd64, m68k and vax, all machines need strict alignment.

      2. By Jason Wright (65.202.219.66) jason@thought.net on http://www.thought.net/jason

        Both HPPA and MIPS have strict alignment requirements.

  6. By Anonymous Coward (216.220.225.229) on

    Great work, and the blog is very interesting. Is anyone working to something for the front-end? Would we see any of this sensor output in any existing userland tools?

    Comments
    1. By Anonymous Coward (87.78.127.13) on

      sysctl hw.sensors
      sensorsd

  7. By Anonymous Coward (64.1.201.131) root@allyourbasearebelongto.us on

    I have an e250 you can test with. I'm not sure from the article who to email.

    Comments
    1. By Ray (199.67.138.210) on

      Try marco@:

      Contributed by marco on Sat Feb 11 15:53:59 2006 (GMT)

      Comments
      1. By Anonymous Coward (87.78.64.223) on

        "Developer blog: dlg: pcfiic"
        dlg == David Gwynne (loki)(animata)(net)

        Comments
        1. By Marco Peereboom (67.64.89.177) marco@peereboom.us on http://www.peereboom.us

          That's right, send it to dlg@

          I just hit the submit button :-)

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]