Date: Wed, 14 Oct 2009 16:35:29 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing Message-ID: <1255556129.95374.160.camel@balrog.2hip.net> In-Reply-To: <4AD6067E.2010503@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote: > 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. Could you also post the client code in some form more readily accessible than trying to cut/paste from the web page? robert. > 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. > -- Robert Noland <rnoland@FreeBSD.org> FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1255556129.95374.160.camel>