Date: Wed, 14 Oct 2009 20:12:30 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: freebsd-acpi@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: heci: a new driver for review and testing Message-ID: <4AD6067E.2010503@icyb.net.ua>
next in thread | raw e-mail | index | archive | help
Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 I actually got around to implementing it (in initial/basic form): http://people.freebsd.org/~avg/heci.tgz Other drivers are: [Linux] http://www.openamt.org/ [OpenSolaris] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/ An example of what functionality this driver could provide: http://article.gmane.org/gmane.linux.drivers.sensors/20398 This actually was my primary motivation for looking into this driver. Your hardware may be supported by this driver if pciconf -lv has something like the following: none0@pci0:0:3:0: class=0x078000 card=0x50448086 chip=0x29c48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '(Bearlake) HECI Controller' class = simple comms Here's how successful attachment of this driver looks on my system: heci0: <Intel 82G33/G31/P35/P31 Express HECI/MEI Controller> mem 0xe0426100-0xe042610f irq 16 at device 3.0 on pci0 heci0: using MSI heci0: [ITHREAD] heci0: found ME client at address 0x03: heci0: status = 0x00 heci0: protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881 heci0: found ME client at address 0x07: heci0: status = 0x00 heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB heci0: found ME client at address 0x20: heci0: status = 0x00 heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 heci0: found ME client at address 0x21: heci0: status = 0x00 heci0: protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607 The driver has many functional and programming shortcomings, but I still would like to ask for its review and testing. Please read the following warnings and notices: 1. right now the driver is provided only as a module. 2. the driver recognizes only PCI ID of 0x29c48086, which is what I tested it with; please see hecireg.h for a list of potentially supported IDs and add your ID to heci_probe(). 3. heciio.h does not get installed into /usr/include, so for time being you need to take an extra step to make it available to code that wishes to communicate to heci. 4. this driver has far less capabilities than Linux and OpenSolaris drivers, so don't expect every OpenAMT program to work with it (but it does reliably work for me for the QST thing). Now more details about the code: 1. the code contains some style violations like overly long lines, probably others; but I still would like to hear your comments on its style. 2. there are some bad design decisions like using the same mutex+condvar pair for signaling different events (reception of data from ME, emptying of user buffer); but I still would like to hear your comments about improving the design. 3. only a single connection is allowed for a host client 4. only a single connection is allowed to a ME client (if the client can support more). 5. quite an arbitrary timeout is used in all places where we wait for simething to happen. 6. no power management supported. 7. only messages of size less than 512 bytes are supported. 8. only complete messages are supported, multi-part messages are not. 9. userland is expected to read or write the whole message in one go. 10. poll/select functionality is not tested. 11. non-blocking reads/writes are not supported. 12. some (probably important) properties and statuses of ME clients are not interpreted. 13. no specific support for watchdog and PTHI, only simple HECI/MEI communications. 14. probably many more... I think that ultimately, if complete feature support is needed, it would be easier to port the driver from either OpenSolaris or Linux than to add all the features to the presented driver. This is because documentation/description for many features is severely lacking in public access. I guess that Intel developers that worked on the OpenAMT driver had much more detailed specifications to work with. But reverse-engineering some parts of OpenAMT code is very hard. You can see for yourself, if not for the hacker who decompiled a Windows DLL, there would be no way of obtaining even GUID of QST client from public sources. Thank you very much in advance for any feedback, comments, ideas! P.S. BTW, can/may I drop "alternatively GPL" wording from License block of the files I borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only? Some additional info. The files contain only some data structure/constants definitions. I guess those are not copyrightable at all? I added a bunch of comments to those file describing the constants and structs. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AD6067E.2010503>