Последний элемент UDID — 32-битный идентификатор устройства, играющий важную роль в распознавании похожих устройств. Это может быть либо число, назначаемое изготовителем (отвечающим за его неповторимость), либо случайное число, генерируемое (и запоминаемое) устройством каждый раз при включении или выполнении команды сброса.
Устройство, поддерживающее ARP, должно иметь специальные флаги:
♦
AR
(Address Resolved) — данному устройству процедурой ARP назначен адрес;
♦
AV
(Address Valid) — устройство имеет действительный личный адрес, на который оно отзывается в обычных транзакциях (при
AV
=0
устройство должно игнорировать все адреса, кроме «дежурного»).
При
AV
=
AR
=0 устройство не имеет личного адреса и должно участвовать в процессе ARP (отвечать на общий опрос идентификатора). При
AV
=1 и
AR
=0 устройство имеет личный адрес, но должно участвовать в ARP. При
AV
=
AR
=1 устройство имеет личный адрес, но не должно отвечать на общий запрос идентификатора. При этом оно должно отрабатывать адресованную ему команду назначения адреса (и впоследствии пользоваться новым назначенным адресом). Комбинация
AV
=0 и
AR
=1 недопустима.
Для протокола ARP введены специальные команды.
♦
Get UDID (general)
— общий запрос идентификатора — команда чтения блока данных с адресом 1100 001 и кодом команды 3. На нее устройства, поддерживающие ARP, отвечают посылкой блока с длиной 17 байт, сопровождаемого PEC. Первые 16 байт блока — UDID, 17-й байт — адрес устройства (с единицей в младшем бите). Если у устройства флаг
AV
=0, оно вместо адреса передает код «1111 111». Команда не влияет на флаги
AV
и
AR
.
♦
Assign address
— назначить адрес — команда записи блока данных с адресом 1100 001 и кодом команды 4 и длиной 17 байт, сопровождаемого PEC. Первые 16 байт блока — UDID, 17-й байт — назначаемый адрес устройства (младший бит игнорируется). По этой команде устройство, обнаружившее полное совпадение UDID со своим собственным, устанавливает флаги
AV
=
AR
=1.
♦
Get UDID (directed)
— направленный запрос идентификатора — команда чтения блока данных с адресом 1100 001, в поле кода команды находится адрес интересующего устройства с единицей в младшем бите. На нее отвечает только устройство, опознавшее свой адрес в поле команды, и отвечает посылкой блока с длиной 17 байт, сопровождаемого PEC. Первые 16 байт блока — UDID, 17-й байт — адрес устройства (с единицей в младшем бите). Команда не влияет на флаги
AV
и
AR
.
♦
Reset device (general)
— общий сброс устройства — посылка по адресу 1100 001 байта команды с кодом 2, сопровождаемого байтом PEC. По этой команде все устройства инициализируются и обнуляют флаги
AR
и
AV
(PSA-устройства флага
AV
не изменяют).
♦
Reset device ARP (dirеcted)
— направленный сброс устройства — посылка по адресу 1100 001 байта с адресом целевого устройства (с нулем в младшем бите), сопровождаемого байтом PEC. По этой команде выбранное устройство инициализируется и обнуляет флаги
AR
и
AV
(PSA-устройства флага
AV
не изменяют).
♦
Notify ARP master
— уведомление ведущего устройства ARP — посылка на адрес 0001 000 байта с «дежурным»
адресом 1100 0010, за которым следуют два байта нулей. Устройство может посылать это уведомление о необходимости выполнения ARP при включении питания, а также при обнаружении коллизии в процессе выполнении чтения данных по индивидуальному адресу устройства.
На каждый байт команд ARP-устройства, поддерживающие этот протокол, отвечают подтверждением
ACK
. Отсутствие подтверждений трактуется ведущим ARP-устройством как отсутствие ARP-устройств на шине.
«Переучет» и назначение адресов вкратце выглядит следующим образом: ведущее ARP-устройство выполняет команду общего запроса идентификатора и по ней получает UDID и, возможно, адрес первого «победителя» в арбитраже. Далее этому победителю назначается личный адрес — тот же или по усмотрению ведущего ARP-устройства, после чего он уже не участвует в арбитраже по общему запросу. Сведения об устройстве и его адрес ведущим ARP-устройством заносятся в таблицу устройств. После этого общий запрос и назначение адреса повторяются снова и снова, пока все ARP-устройства не будут удовлетворены. Признаком «общего удовлетворения» для ведущего ARP-устройства будет отсутствие подтверждений приема команд общего запроса.
Поддержка SMBus в BIOS и ACPI
Шина SMBus, в отличие от ACCESS.bus, сразу получила спецификацию ее поддержки на уровне BIOS. Позже появились спецификации, позволяющие интегрировать устройства SMBus в систему ACPI.
В 1995 г. была опубликована спецификация интерфейса SMBus BIOS — System Management Bus BIOS Interface Specification, основные идеи которой вкратце изложены ниже. Интерфейс позволяет верхним уровням ПО абстрагироваться от аппаратной реализации хост-контроллера. Поддержка BIOS обеспечивается для трех типов режимов работы процессора: реального (и V86), защищенного 16-разрядного и защищенного 32-разрядного. Вызов функций может выполняться либо через BIOS
Int 15h
(в реальном режиме и в V86), либо через точку входа, полученную при подключении в соответствующем режиме. Для подключения (и отключения) также используется сервис BIOS
Int 15h
; после подключения доступ через
Int 15h
блокируется (до отключения). В защищенном режиме вызов интерфейсных функций возможен только через точку входа, полученную при подключении. Поддержка точки входа для реального режима необязательна.
Спецификация SMBus BIOS обеспечивает хост-центрическое обращение к абонентам шины: по инициативе вызывающей программы хост-контроллер посылает устройству команду, которая может предполагать и немедленный ответ устройства. Однако устройства могут посылать хосту сообщения по собственной инициативе, при этом они обязаны использовать протокол
Write Word
. Хост способен помещать принятые сообщения в небольшую очередь, из которой они могут программно извлекаться путем вызова функции 7 (программа должна периодически выполнять этот вызов для проверки наличия сообщений в очереди). В очереди каждое сообщение представлено байтом адреса источника и парой байт тела сообщения.
Шина SMBus тесно связана с оборудованием, управляющим питанием и участвующим в генерации запросов системного прерывания SMI (System Management Interrupt — особое аппаратное прерывание процессора) и их обработки. Из-за этого в BIOS введен специальный механизм, позволяющий обнаружить обработку SMI во время выполнения транзакций и в иное время. Это необходимо, поскольку обработчик SMI, работающий в режиме SMM, совершенно невидим прикладной программе, а результаты его работы могут существенно влиять на работу программы, вызывающей BIOS SMBus.