Intel integrated sensor hub driver что это
A sensor hub enables the ability to offload sensor polling and algorithm processing to a dedicated low power co-processor. This allows the core processor to go into low power modes more often, resulting in the increased battery life.
There are many vendors providing external sensor hubs confirming to HID Sensor usage tables, and used in several tablets, 2 in 1 convertible laptops and embedded products. Linux had this support since Linux 3.9.
Intel® introduced integrated sensor hubs as a part of the SoC starting from Cherry Trail and now supported on multiple generations of CPU packages. There are many commercial devices already shipped with Integrated Sensor Hubs (ISH). These ISH also comply to HID sensor specification, but the difference is the transport protocol used for communication. The current external sensor hubs mainly use HID over i2C or USB. But ISH doesn’t use either i2c or USB.
1. Overview¶
Using a analogy with a usbhid implementation, the ISH follows a similar model for a very high speed communication:
Like USB protocol provides a method for device enumeration, link management and user data encapsulation, the ISH also provides similar services. But it is very light weight tailored to manage and communicate with ISH client applications implemented in the firmware.
The ISH allows multiple sensor management applications executing in the firmware. Like USB endpoints the messaging can be to/from a client. As part of enumeration process, these clients are identified. These clients can be simple HID sensor applications, sensor calibration application or senor firmware update application.
The implementation model is similar, like USB bus, ISH transport is also implemented as a bus. Each client application executing in the ISH processor is registered as a device on this bus. The driver, which binds each device (ISH HID driver) identifies the device type and registers with the hid core.
2. ISH Implementation: Block Diagram¶
3. High level processing in above blocks¶
3.1 Hardware Interface¶
The ISH is exposed as “Non-VGA unclassified PCI device” to the host. The PCI product and vendor IDs are changed from different generations of processors. So the source code which enumerate drivers needs to update from generation to generation.
3.2 Inter Processor Communication (IPC) driver¶
The IPC message used memory mapped I/O. The registers are defined in hw-ish-regs.h.
3.2.1 IPC/FW message types¶
There are two types of messages, one for management of link and other messages are to and from transport layers.
TX and RX of Transport messages¶
A set of memory mapped register offers support of multi byte messages TX and RX (E.g.IPC_REG_ISH2HOST_MSG, IPC_REG_HOST2ISH_MSG). The IPC layer maintains internal queues to sequence messages and send them in order to the FW. Optionally the caller can register handler to get notification of completion. A door bell mechanism is used in messaging to trigger processing in host and client firmware side. When ISH interrupt handler is called, the ISH2HOST doorbell register is used by host drivers to determine that the interrupt is for ISH.
Each side has 32 32-bit message registers and a 32-bit doorbell. Doorbell register has the following format: Bits 0..6: fragment length (7 bits are used) Bits 10..13: encapsulated protocol Bits 16..19: management command (for IPC management protocol) Bit 31: doorbell trigger (signal H/W interrupt to the other side) Other bits are reserved, should be 0.
3.2.2 Transport layer interface¶
To abstract HW level IPC communication, a set of callbacks are registered. The transport layer uses them to send and receive messages. Refer to struct ishtp_hw_ops for callbacks.
3.3 ISH Transport layer¶
3.3.1 A Generic Transport Layer¶
The transport layer is a bi-directional protocol, which defines: - Set of commands to start, stop, connect, disconnect and flow control (ishtp/hbm.h) for details - A flow control mechanism to avoid buffer overflows
3.3.2 Connection and Flow Control Mechanism¶
Each FW client and a protocol is identified by an UUID. In order to communicate to a FW client, a connection must be established using connect request and response bus messages. If successful, a pair (host_client_id and fw_client_id) will identify the connection.
Once connection is established, peers send each other flow control bus messages independently. Every peer may send a message only if it has received a flow-control credit before. Once it sent a message, it may not send another one before receiving the next flow control credit. Either side can send disconnect request bus message to end communication. Also the link will be dropped if major FW reset occurs.
3.3.3 Peer to Peer data transfer¶
Peer to Peer data transfer can happen with or without using DMA. Depending on the sensor bandwidth requirement DMA can be enabled by using module parameter ishtp_use_dma under intel_ishtp.
Each side (host and FW) manages its DMA transfer memory independently. When an ISHTP client from either host or FW side wants to send something, it decides whether to send over IPC or over DMA; for each transfer the decision is independent. The sending side sends DMA_XFER message when the message is in the respective host buffer (TX when host client sends, RX when FW client sends). The recipient of DMA message responds with DMA_XFER_ACK, indicating the sender that the memory region for that message may be reused.
DMA initialization is started with host sending DMA_ALLOC_NOTIFY bus message (that includes RX buffer) and FW responds with DMA_ALLOC_NOTIFY_ACK. Additionally to DMA address communication, this sequence checks capabilities: if thw host doesn’t support DMA, then it won’t send DMA allocation, so FW can’t send DMA; if FW doesn’t support DMA then it won’t respond with DMA_ALLOC_NOTIFY_ACK, in which case host will not use DMA transfers. Here ISH acts as busmaster DMA controller. Hence when host sends DMA_XFER, it’s request to do host->ISH DMA transfer; when FW sends DMA_XFER, it means that it already did DMA and the message resides at host. Thus, DMA_XFER and DMA_XFER_ACK act as ownership indicators.
At initial state all outgoing memory belongs to the sender (TX to host, RX to FW), DMA_XFER transfers ownership on the region that contains ISHTP message to the receiving side, DMA_XFER_ACK returns ownership to the sender. A sender needs not wait for previous DMA_XFER to be ack’ed, and may send another message as long as remaining continuous memory in its ownership is enough. In principle, multiple DMA_XFER and DMA_XFER_ACK messages may be sent at once (up to IPC MTU), thus allowing for interrupt throttling. Currently, ISH FW decides to send over DMA if ISHTP message is more than 3 IPC fragments and via IPC otherwise.
3.3.4 Ring Buffers¶
When a client initiate a connection, a ring or RX and TX buffers are allocated. The size of ring can be specified by the client. HID client set 16 and 32 for TX and RX buffers respectively. On send request from client, the data to be sent is copied to one of the send ring buffer and scheduled to be sent using bus message protocol. These buffers are required because the FW may have not have processed the last message and may not have enough flow control credits to send. Same thing holds true on receive side and flow control is required.
3.3.5 Host Enumeration¶
The host enumeration bus command allow discovery of clients present in the FW. There can be multiple sensor clients and clients for calibration function.
To ease in implantation and allow independent driver handle each client this transport layer takes advantage of Linux Bus driver model. Each client is registered as device on the the transport bus (ishtp bus).
Enumeration sequence of messages:
- Host sends HOST_START_REQ_CMD, indicating that host ISHTP layer is up.
- FW responds with HOST_START_RES_CMD
- Host sends HOST_ENUM_REQ_CMD (enumerate FW clients)
- FW responds with HOST_ENUM_RES_CMD that includes bitmap of available FW client IDs
- For each FW ID found in that bitmap host sends HOST_CLIENT_PROPERTIES_REQ_CMD
- FW responds with HOST_CLIENT_PROPERTIES_RES_CMD. Properties include UUID, max ISHTP message size, etc.
- Once host received properties for that last discovered client, it considers ISHTP device fully functional (and allocates DMA buffers)
3.4 HID over ISH Client¶
The ISHTP client driver is responsible for:
- enumerate HID devices under FW ISH client
- Get Report descriptor
- Register with HID core as a LL driver
- Process Get/Set feature request
- Get input reports
3.5 HID Sensor Hub MFD and IIO sensor drivers¶
The functionality in these drivers is the same as an external sensor hub. Refer to Documentation/hid/hid-sensor.rst for HID sensor Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space
3.6 End to End HID transport Sequence Diagram¶
3.7 ISH Debugging¶
To debug ISH, event tracing mechanism is used. To enable debug logs echo 1 > /sys/kernel/debug/tracing/events/intel_ish/enable cat sys/kernel/debug/tracing/trace
Предоставляет драйвер integrated Sensor Hub (ISH) для Windows® 10 для элемента ноутбука Intel® NUC P14E.
Лицензия на использование программного обеспечения Intel
Для скачивания этого файла Intel требует принять лицензионное соглашение. Хотите пересмотреть свое решение?
Файлы, доступные для скачивания
- Windows 10, 64-bit*, Windows 11*
- Размер: 2.7 MB
- SHA1: FDA42B6C22241050E0E8F0DB37AA520F64DCC32D
Подробное описание
Цель
Этот пакет содержит драйверы для интегрированного концентратора датчиков (ISH) для элемента ноутбука Intel® NUC P14E с® WINDOWS 10 и Windows 11*.
Этот скачиваемый файл подходит для нижеуказанных видов продукции.
Автоматическое обновление драйвера и программного обеспечения
Идентифицируйте свою продукцию и установите обновления драйверов Intel® и ПО для вашей ОС Windows*.
Содержание данной страницы представляет собой сочетание выполненного человеком и компьютерного перевода оригинального содержания на английском языке. Данная информация предоставляется для вашего удобства и в ознакомительных целях и не должна расцениваться как исключительная, либо безошибочная. При обнаружении каких-либо противоречий между версией данной страницы на английском языке и переводом, версия на английском языке будет иметь приоритет и контроль. Посмотреть английскую версию этой страницы.
Для работы технологий Intel может потребоваться специальное оборудование, ПО или активация услуг. // Ни один продукт или компонент не может обеспечить абсолютную защиту. // Ваши расходы и результаты могут отличаться. // Производительность зависит от вида использования, конфигурации и других факторов. // См. наши юридические уведомления и отказ от ответственности. // Корпорация Intel выступает за соблюдение прав человека и избегает причастности к их нарушению. См. Глобальные принципы защиты прав человека в корпорации Intel. Продукция и программное обеспечение Intel предназначены только для использования в приложениях, которые не приводят или не способствуют нарушению всемирно признанных прав человека.
A sensor hub enables the ability to offload sensor polling and algorithm processing to a dedicated low power co-processor. This allows the core processor to go into low power modes more often, resulting in increased battery life.
There are many vendors providing external sensor hubs conforming to HID Sensor usage tables. These may be found in tablets, 2-in-1 convertible laptops and embedded products. Linux has had this support since Linux 3.9.
Intel® introduced integrated sensor hubs as a part of the SoC starting from Cherry Trail and now supported on multiple generations of CPU packages. There are many commercial devices already shipped with Integrated Sensor Hubs (ISH). These ISH also comply to HID sensor specification, but the difference is the transport protocol used for communication. The current external sensor hubs mainly use HID over I2C or USB. But ISH doesn’t use either I2C or USB.
1. Overview¶
Using a analogy with a usbhid implementation, the ISH follows a similar model for a very high speed communication:
Like USB protocol provides a method for device enumeration, link management and user data encapsulation, the ISH also provides similar services. But it is very light weight tailored to manage and communicate with ISH client applications implemented in the firmware.
The ISH allows multiple sensor management applications executing in the firmware. Like USB endpoints the messaging can be to/from a client. As part of enumeration process, these clients are identified. These clients can be simple HID sensor applications, sensor calibration applications or sensor firmware update applications.
The implementation model is similar, like USB bus, ISH transport is also implemented as a bus. Each client application executing in the ISH processor is registered as a device on this bus. The driver, which binds each device (ISH HID driver) identifies the device type and registers with the HID core.
2. ISH Implementation: Block Diagram¶
3. High level processing in above blocks¶
3.1 Hardware Interface¶
The ISH is exposed as “Non-VGA unclassified PCI device” to the host. The PCI product and vendor IDs are changed from different generations of processors. So the source code which enumerates drivers needs to update from generation to generation.
3.2 Inter Processor Communication (IPC) driver¶
The IPC message uses memory mapped I/O. The registers are defined in hw-ish-regs.h.
3.2.1 IPC/FW message types¶
There are two types of messages, one for management of link and another for messages to and from transport layers.
TX and RX of Transport messages¶
A set of memory mapped register offers support of multi-byte messages TX and RX (e.g. IPC_REG_ISH2HOST_MSG, IPC_REG_HOST2ISH_MSG). The IPC layer maintains internal queues to sequence messages and send them in order to the firmware. Optionally the caller can register handler to get notification of completion. A doorbell mechanism is used in messaging to trigger processing in host and client firmware side. When ISH interrupt handler is called, the ISH2HOST doorbell register is used by host drivers to determine that the interrupt is for ISH.
Each side has 32 32-bit message registers and a 32-bit doorbell. Doorbell register has the following format:
3.2.2 Transport layer interface¶
To abstract HW level IPC communication, a set of callbacks is registered. The transport layer uses them to send and receive messages. Refer to struct ishtp_hw_ops for callbacks.
3.3 ISH Transport layer¶
3.3.1 A Generic Transport Layer¶
The transport layer is a bi-directional protocol, which defines: - Set of commands to start, stop, connect, disconnect and flow control (see ishtp/hbm.h for details) - A flow control mechanism to avoid buffer overflows
3.3.2 Connection and Flow Control Mechanism¶
Each FW client and a protocol is identified by a UUID. In order to communicate to a FW client, a connection must be established using connect request and response bus messages. If successful, a pair (host_client_id and fw_client_id) will identify the connection.
Once connection is established, peers send each other flow control bus messages independently. Every peer may send a message only if it has received a flow-control credit before. Once it has sent a message, it may not send another one before receiving the next flow control credit. Either side can send disconnect request bus message to end communication. Also the link will be dropped if major FW reset occurs.
3.3.3 Peer to Peer data transfer¶
Peer to Peer data transfer can happen with or without using DMA. Depending on the sensor bandwidth requirement DMA can be enabled by using module parameter ishtp_use_dma under intel_ishtp.
Each side (host and FW) manages its DMA transfer memory independently. When an ISHTP client from either host or FW side wants to send something, it decides whether to send over IPC or over DMA; for each transfer the decision is independent. The sending side sends DMA_XFER message when the message is in the respective host buffer (TX when host client sends, RX when FW client sends). The recipient of DMA message responds with DMA_XFER_ACK, indicating the sender that the memory region for that message may be reused.
DMA initialization is started with host sending DMA_ALLOC_NOTIFY bus message (that includes RX buffer) and FW responds with DMA_ALLOC_NOTIFY_ACK. Additionally to DMA address communication, this sequence checks capabilities: if thw host doesn’t support DMA, then it won’t send DMA allocation, so FW can’t send DMA; if FW doesn’t support DMA then it won’t respond with DMA_ALLOC_NOTIFY_ACK, in which case host will not use DMA transfers. Here ISH acts as busmaster DMA controller. Hence when host sends DMA_XFER, it’s request to do host->ISH DMA transfer; when FW sends DMA_XFER, it means that it already did DMA and the message resides at host. Thus, DMA_XFER and DMA_XFER_ACK act as ownership indicators.
At initial state all outgoing memory belongs to the sender (TX to host, RX to FW), DMA_XFER transfers ownership on the region that contains ISHTP message to the receiving side, DMA_XFER_ACK returns ownership to the sender. A sender need not wait for previous DMA_XFER to be ack’ed, and may send another message as long as remaining continuous memory in its ownership is enough. In principle, multiple DMA_XFER and DMA_XFER_ACK messages may be sent at once (up to IPC MTU), thus allowing for interrupt throttling. Currently, ISH FW decides to send over DMA if ISHTP message is more than 3 IPC fragments and via IPC otherwise.
3.3.4 Ring Buffers¶
When a client initiates a connection, a ring of RX and TX buffers is allocated. The size of ring can be specified by the client. HID client sets 16 and 32 for TX and RX buffers respectively. On send request from client, the data to be sent is copied to one of the send ring buffer and scheduled to be sent using bus message protocol. These buffers are required because the FW may have not have processed the last message and may not have enough flow control credits to send. Same thing holds true on receive side and flow control is required.
3.3.5 Host Enumeration¶
The host enumeration bus command allows discovery of clients present in the FW. There can be multiple sensor clients and clients for calibration function.
To ease implementation and allow independent drivers to handle each client, this transport layer takes advantage of Linux Bus driver model. Each client is registered as device on the transport bus (ishtp bus).
Enumeration sequence of messages:
Host sends HOST_START_REQ_CMD, indicating that host ISHTP layer is up.
FW responds with HOST_START_RES_CMD
Host sends HOST_ENUM_REQ_CMD (enumerate FW clients)
FW responds with HOST_ENUM_RES_CMD that includes bitmap of available FW client IDs
For each FW ID found in that bitmap host sends HOST_CLIENT_PROPERTIES_REQ_CMD
FW responds with HOST_CLIENT_PROPERTIES_RES_CMD. Properties include UUID, max ISHTP message size, etc.
Once host received properties for that last discovered client, it considers ISHTP device fully functional (and allocates DMA buffers)
3.4 HID over ISH Client¶
The ISHTP client driver is responsible for:
enumerate HID devices under FW ISH client
Get Report descriptor
Register with HID core as a LL driver
Process Get/Set feature request
Get input reports
3.5 HID Sensor Hub MFD and IIO sensor drivers¶
The functionality in these drivers is the same as an external sensor hub. Refer to HID Sensors Framework for HID sensor Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space.
A sensor hub enables the ability to offload sensor polling and algorithm processing to a dedicated low power co-processor. This allows the core processor to go into low power modes more often, resulting in increased battery life.
There are many vendors providing external sensor hubs conforming to HID Sensor usage tables. These may be found in tablets, 2-in-1 convertible laptops and embedded products. Linux has had this support since Linux 3.9.
Intel® introduced integrated sensor hubs as a part of the SoC starting from Cherry Trail and now supported on multiple generations of CPU packages. There are many commercial devices already shipped with Integrated Sensor Hubs (ISH). These ISH also comply to HID sensor specification, but the difference is the transport protocol used for communication. The current external sensor hubs mainly use HID over I2C or USB. But ISH doesn’t use either I2C or USB.
1. Overview¶
Using a analogy with a usbhid implementation, the ISH follows a similar model for a very high speed communication:
Like USB protocol provides a method for device enumeration, link management and user data encapsulation, the ISH also provides similar services. But it is very light weight tailored to manage and communicate with ISH client applications implemented in the firmware.
The ISH allows multiple sensor management applications executing in the firmware. Like USB endpoints the messaging can be to/from a client. As part of enumeration process, these clients are identified. These clients can be simple HID sensor applications, sensor calibration applications or sensor firmware update applications.
The implementation model is similar, like USB bus, ISH transport is also implemented as a bus. Each client application executing in the ISH processor is registered as a device on this bus. The driver, which binds each device (ISH HID driver) identifies the device type and registers with the HID core.
2. ISH Implementation: Block Diagram¶
3. High level processing in above blocks¶
3.1 Hardware Interface¶
The ISH is exposed as “Non-VGA unclassified PCI device” to the host. The PCI product and vendor IDs are changed from different generations of processors. So the source code which enumerates drivers needs to update from generation to generation.
3.2 Inter Processor Communication (IPC) driver¶
The IPC message uses memory mapped I/O. The registers are defined in hw-ish-regs.h.
3.2.1 IPC/FW message types¶
There are two types of messages, one for management of link and another for messages to and from transport layers.
TX and RX of Transport messages¶
A set of memory mapped register offers support of multi-byte messages TX and RX (e.g. IPC_REG_ISH2HOST_MSG, IPC_REG_HOST2ISH_MSG). The IPC layer maintains internal queues to sequence messages and send them in order to the firmware. Optionally the caller can register handler to get notification of completion. A doorbell mechanism is used in messaging to trigger processing in host and client firmware side. When ISH interrupt handler is called, the ISH2HOST doorbell register is used by host drivers to determine that the interrupt is for ISH.
Each side has 32 32-bit message registers and a 32-bit doorbell. Doorbell register has the following format:
3.2.2 Transport layer interface¶
To abstract HW level IPC communication, a set of callbacks is registered. The transport layer uses them to send and receive messages. Refer to struct ishtp_hw_ops for callbacks.
3.3 ISH Transport layer¶
3.3.1 A Generic Transport Layer¶
The transport layer is a bi-directional protocol, which defines: - Set of commands to start, stop, connect, disconnect and flow control (see ishtp/hbm.h for details) - A flow control mechanism to avoid buffer overflows
3.3.2 Connection and Flow Control Mechanism¶
Each FW client and a protocol is identified by a UUID. In order to communicate to a FW client, a connection must be established using connect request and response bus messages. If successful, a pair (host_client_id and fw_client_id) will identify the connection.
Once connection is established, peers send each other flow control bus messages independently. Every peer may send a message only if it has received a flow-control credit before. Once it has sent a message, it may not send another one before receiving the next flow control credit. Either side can send disconnect request bus message to end communication. Also the link will be dropped if major FW reset occurs.
3.3.3 Peer to Peer data transfer¶
Peer to Peer data transfer can happen with or without using DMA. Depending on the sensor bandwidth requirement DMA can be enabled by using module parameter ishtp_use_dma under intel_ishtp.
Each side (host and FW) manages its DMA transfer memory independently. When an ISHTP client from either host or FW side wants to send something, it decides whether to send over IPC or over DMA; for each transfer the decision is independent. The sending side sends DMA_XFER message when the message is in the respective host buffer (TX when host client sends, RX when FW client sends). The recipient of DMA message responds with DMA_XFER_ACK, indicating the sender that the memory region for that message may be reused.
DMA initialization is started with host sending DMA_ALLOC_NOTIFY bus message (that includes RX buffer) and FW responds with DMA_ALLOC_NOTIFY_ACK. Additionally to DMA address communication, this sequence checks capabilities: if thw host doesn’t support DMA, then it won’t send DMA allocation, so FW can’t send DMA; if FW doesn’t support DMA then it won’t respond with DMA_ALLOC_NOTIFY_ACK, in which case host will not use DMA transfers. Here ISH acts as busmaster DMA controller. Hence when host sends DMA_XFER, it’s request to do host->ISH DMA transfer; when FW sends DMA_XFER, it means that it already did DMA and the message resides at host. Thus, DMA_XFER and DMA_XFER_ACK act as ownership indicators.
At initial state all outgoing memory belongs to the sender (TX to host, RX to FW), DMA_XFER transfers ownership on the region that contains ISHTP message to the receiving side, DMA_XFER_ACK returns ownership to the sender. A sender need not wait for previous DMA_XFER to be ack’ed, and may send another message as long as remaining continuous memory in its ownership is enough. In principle, multiple DMA_XFER and DMA_XFER_ACK messages may be sent at once (up to IPC MTU), thus allowing for interrupt throttling. Currently, ISH FW decides to send over DMA if ISHTP message is more than 3 IPC fragments and via IPC otherwise.
3.3.4 Ring Buffers¶
When a client initiates a connection, a ring of RX and TX buffers is allocated. The size of ring can be specified by the client. HID client sets 16 and 32 for TX and RX buffers respectively. On send request from client, the data to be sent is copied to one of the send ring buffer and scheduled to be sent using bus message protocol. These buffers are required because the FW may have not have processed the last message and may not have enough flow control credits to send. Same thing holds true on receive side and flow control is required.
3.3.5 Host Enumeration¶
The host enumeration bus command allows discovery of clients present in the FW. There can be multiple sensor clients and clients for calibration function.
To ease implementation and allow independent drivers to handle each client, this transport layer takes advantage of Linux Bus driver model. Each client is registered as device on the transport bus (ishtp bus).
Enumeration sequence of messages:
Host sends HOST_START_REQ_CMD, indicating that host ISHTP layer is up.
FW responds with HOST_START_RES_CMD
Host sends HOST_ENUM_REQ_CMD (enumerate FW clients)
FW responds with HOST_ENUM_RES_CMD that includes bitmap of available FW client IDs
For each FW ID found in that bitmap host sends HOST_CLIENT_PROPERTIES_REQ_CMD
FW responds with HOST_CLIENT_PROPERTIES_RES_CMD. Properties include UUID, max ISHTP message size, etc.
Once host received properties for that last discovered client, it considers ISHTP device fully functional (and allocates DMA buffers)
3.4 HID over ISH Client¶
The ISHTP client driver is responsible for:
enumerate HID devices under FW ISH client
Get Report descriptor
Register with HID core as a LL driver
Process Get/Set feature request
Get input reports
3.5 HID Sensor Hub MFD and IIO sensor drivers¶
The functionality in these drivers is the same as an external sensor hub. Refer to HID Sensors Framework for HID sensor Documentation/ABI/testing/sysfs-bus-iio for IIO ABIs to user space.
Начиная с PCH 100-й серии компания Intel полностью переработала эту микросхему. Был осуществлен переход на новую архитектуру встроенных микроконтроллеров - с ARCompact компании ARC на x86. За основу был выбран 32-битный микроконтроллер Minute IA (MIA), который использовался в микрокомпьютерах Intel Edison и SoC Quark. Он основан на дизайне весьма старого, скалярного микропроцессора Intel 486 с добавлением системы команд (ISA) от процессора Pentium. Однако для PCH компания выпускает данное ядро с применением 22-нм полупроводниковой технологии, получая высокую энергоэффективность микроконтроллера. Но теперь таких ядер в PCH 100-й серии три: Management Engine (ME), Integrated Sensors Hub (ISH) и Innovation Engine (IE). Последние два могут активироваться и деактивироваться в зависимости от модели PCH и целевой платформы, а ME-ядро работает всегда.
Подсистема Intel ME (Intel Management Engine).
Intel Management Engine - это закрытая технология, которая представляет собой интегрированный в микросхему Platform Controller Hub (PCH) микроконтроллер с набором встроенных периферийных устройств. Именно через PCH проходит почти все общение процессора с внешними устройствами, следовательно Intel ME имеет доступ практически ко всем данным на компьютере и возможность исполнения стороннего кода.
При инициализации системы Intel® Management Engine загружает свой код из флэш-памяти системы. Это позволяет Intel® Management Engine работать до запуска основной операционной системы. Для хранения данных во время выполнения процессор управления Intel® имеет доступ к защищенной области системной памяти (в дополнение к небольшому количеству встроенной кэш-памяти для более быстрой и эффективной обработки).
Intel® ME выполняет различные задачи, пока система находится в спящем режиме, во время процесса запуска и когда ваша система работает. Без ME не возможна загрузка процессора. ME имеет полный доступ к памяти (без всякого ведома на то родительского ЦПУ); ME имеет полный доступ к TCP/IP стеку и может посылать и принимать пакеты независимо от операционной системы, обходя таким образом её файрволл.
ME имеет свой MAC-адрес и IP-адрес для своего дополнительного интерфейса, с прямым доступом к контроллеру Ethernet. Каждый пакет Ethernet-траффика переадресуется в ME даже до достижения операционной системы хоста, причём такое поведение поддерживается многими контроллерами, настраиваемыми по протоколу MCTP.
Integrated Sensors Hub (ISH).
Концентратор датчиков - это микроконтроллер/сопроцессор/DSP, который помогает интегрировать данные от различных датчиков и обрабатывать их. Эта технология может помочь разгрузить эти задания от основного центрального процессора, тем самым экономя потребление батареи и обеспечивая повышение производительности. Начиная с Cherrytrail, несколько поколений процессоров Intel предлагают концентратор датчиков.
- Мониторинг таких параметров, как температура, напряжение, скорость вращения вентиляторов, состояние источников питания, наличие ошибок шины, физическая безопасность системы.
- Автоматически или вручную локально и удаленно инициируемые включение/выключение и перезагрузка системы.
- Фиксирование аномальных или выходящих из допустимого диапазона состояний для последующего исследования и предупреждения.
- Предоставляет информацию, которая помогает идентифицировать вышедшее из строя устройство.
- Функции управления системой могут быть доступны даже в выключенном состоянии.
Baseboard Management Controller (BMC).
В компьютере часто присутствует и Baseboard Management Controller (BMC) — контроллер, реализующий логику работы IPMI. IPMI (Intelligent Platform Management Interface) - интеллектуальный интерфейс управления платформой, предназначенный для автономного мониторинга и управления функциями, встроенными непосредственно в аппаратное и микропрограммное обеспечения серверных платформ. Ключевые характеристики IPMI - мониторинг, восстановление функций управления, журналирование и инвентаризация, которые доступны независимо от процессора, BIOS'a и операционной системы. Функции управления платформой могут быть доступны, даже если система находится в выключенном состоянии.
Возможности интеллектуального управления платформой - ключевой компонент обеспечения управления системами с высокой степенью готовности на предприятии (первая спецификация интерфейса представлена еще 16 сентября 1998 года совместно корпорациями Intel, Dell, NEC и Hewlett-Packard; текущая версия описывается в документе Intelligent Platform Management Interface Specification Second Generation) - использовать этот документ следует с учетом поправок и предупреждений.
Innovation Engine (IE).
IE - это крошечный сопроцессор (микроконтроллер), интегрированный в наборы серверных микросхем Intel, который обеспечивает платформу, необходимую для разработчиков систем для создания своих собственных высоко настраиваемых прошивок. С архитектурной точки зрения IE очень похож на Intel Management Engine (ME), но спроектирован как «открытый движок», позволяющий разработчикам систем разрабатывать свои собственные дифференцирующие микропрограммы. IE дополняет ME, и оба присутствуют, начиная с введения чипсета Lewisburg PCH.
Intel представила Innovation Engine (IE), начиная с набора микросхем Lewisburg (то есть компонентов Skylake-SP). IE интегрирован вместе с ME в чипсет. Принимая во внимание, что ME разработан специально для функций Intel, IE разработан специально для системных разработчиков. То есть Intel предоставляет только оборудование для работы с IE, но если системные разработчики не разработают для него специальную прошивку, она ничего не делает.
Как и ME от Intel, IE работает на 32-битном микроконтроллере Quark x86. IE выполняет только криптографически подписанный «код IE», привязанный к сборщику системы. Неаутентифицированный код не будет загружен. В отличие от ME, IE имеет дополнительный доступ к UART. Также имеется дополнительный доступ к контроллеру системной платы (BMC) для разработчиков систем, которые реализуют функции встроенного ПО IE, которые обмениваются данными напрямую с сетью.
Таким образом, Innovation Engine - это небольшой процессор архитектуры Intel и подсистема ввода-вывода, встроенная в серверные платформы Intel следующего поколения. Intel IE позволяет сборщикам систем создавать свои собственные уникальные, дифференцированные прошивки для серверов, систем хранения и сетей. Некоторые возможные применения включают в себя облегченный BMC, обеспечивающий базовую управляемость и сниженную общую стоимость системы, или для повышения производительности сервера путем разгрузки BIOS и подпрограмм BMC в IE.
Конкурентное преимущество в конструкциях Intel часто исходит от встроенного программного обеспечения, либо кода BIOS, либо кода контроллера основной платы (BMC). А в мире серверов OEM-производители часто обязаны поставщикам UEFI для настройки. Поэтому OEM-производители часто вкладывают средства в настройку управления системой для создания дифференциации - вот в чем заключается IE.
IE может дополнять или заменять большую часть функциональности, которая может существовать на современных BMC. Кроме того, для систем более низкого уровня, которые могут не требовать BMC, IE может предоставить платформу, которая предоставляет возможности управления системой без дополнительных затрат на спецификацию. По словам Intel, «некоторые возможные варианты использования включают в себя размещение облегченных функций управления для снижения общей стоимости системы, повышения производительности сервера за счет разгрузки процедур BIOS и BMC или расширения Intel Management Engine для таких вещей, как телеметрия и доверенная загрузка».
Однако в IE появляются и новые, инновационные функции. Одним из таких приложений является встроенная диагностика ASSET ScanWorks (SED). SED обеспечивает возможность полного комплекта валидации, тестирования и отладки, встроенного в систему, в отличие от требования доступа через внешние кабели, аппаратные пробники и фиксацию.
Для SED для некоторых приложений (таких как функции Trace) IE требуется только дополнение прошивки для доступа к таким ресурсам, как буферы Trace. Для других приложений, таких как тест граничного сканирования, он должен иметь доступ к цепочке сканирования JTAG. Для функций управления работой Intel требуется доступ к подмножеству сигналов XDP. В конечном счете, IE представляет собой новую платформу для инноваций в проектах Intel, которая имеет и будет иметь преимущества как для OEM-производителей, так и для их клиентов.
Читайте также: