Andriy Gapon
2009-10-14 17:12:30 UTC
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:
***@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.
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:
***@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
Andriy Gapon