heci: a new driver for review and testing

Wed Oct 14 23:36:09 UTC 2009

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 at 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 at FreeBSD.org>
FreeBSD