Доступ к информации об оборудовании UEFI из Linux
Откройте два терминала и введите на обоих:
nc -u -l 55555
Откройте третий терминал, установите socat, если нужно, и введите:
echo -n "TEST" | socat - udp-datagram:127.255.255.255:55555,broadcast
Вы должны увидеть, что оба терминала получили сообщение.
Если вы попробуете провести тот же эксперимент с 127.0.0.1, только один терминал получит сообщение, как и ожидалось.
Нет устройств, управляемых UEFI. Потому что ОС Linux вызвала функцию UEFI ExitBootServices. Это необходимо для того, чтобы ОС могла вообще начать управлять любым устройством.
Современные ОС включают драйверы для аппаратных устройств. Одно устройство не должно управляться двумя разными драйверами. Сюда входят родительские устройства/«шины», которые используются для перечисления и связи со своими дочерними устройствами.
Например, концентратор USB на вашем мониторе, который вы подключаете к компьютеру через порт USB -C, который находится на карте PCI -E, подключенной к разъему PCI -E на вашем системная плата. Ваша загрузочная прошивка может иметь возможность загружать исполняемый файл EFI с USB-накопителя, подключенного к этому USB-порту. Но когда вы запускаете этот исполняемый файл и он вызывает UEFI ExitBootServices, ему разрешается контролировать все это.
Таким образом, общее правило состоит в том, что ОС — это то, что перечисляет подключенное оборудование. Прошивка больше не имеет управления. Вы не можете попросить прошивку перечислить в настоящее время подключенное оборудование и получить какой-либо разумный результат.
Есть исключения из общего правила. Со всеми очень страшно иметь дело. Вопрос в том виде, в котором он написан, не содержит причин для перечисления всех исключений, применимых к вашей машине. Так что не делай этого.
Некоторая информация об оборудовании доступна через ACPI и DMI. Таблицы ACPI технически предоставляются через UEFI за счет передачи одного указателя (и, я полагаю, путем оставления соответствующей зарезервированной памяти в карте памяти, которую ОС передает UEFI ). Предположительно DMI аналогичен.
Команда DMI — dmidecode.DMI в основном кажется набором идентификаторов. Некоторые из них собираются с аппаратного обеспечения во время загрузки. Ни один из них не должен быть исчерпывающим, поэтому в основном вам нужны драйверы шины, чтобы найти все необходимые аппаратные устройства.
Существует ряд команд ACPI, включая acpidumpи acpixtract. Одним из инструментов является дизассемблер для интерпретируемого языка под названием AML, который ОС запускает в различных случаях.
AML может показаться несколько ужасным, но он, по крайней мере, разработан таким образом, что вы можете избежать связывания драйвера ОС и драйвера AML с одним и тем же оборудованием и возникновения конфликтов. Например, у ОС есть драйвер для встроенного контроллера, и AML может фактически взаимодействовать с драйвером ОС. Или ACPI может зарезервировать определенные аппаратные ресурсы, чтобы AML мог использовать их напрямую, а ОС знала, что ей не разрешено их использовать.
ACPI также заменяет предыдущую версию ISA PNP. Это используется для перечисления устаревших устройств, таких как последовательные порты, где они не могут быть перечислены самой ОС.
Точно так же ACPI номинально отвечает за указание ОС искать начальные регистры PCI или адреса памяти ввода-вывода. (Я не в курсе событий. Но если ACPI говорит, что их нет, я могу представить, что Linux все равно попытается проверить нормальный адрес для этого ).
Доступ к множеству устройств осуществляется через шину PCI прямо или косвенно.
IIRC Windows покажет это в диспетчере устройств, показывая PCI как дочернее устройство ACPI. Linux, кажется, не беспокоит (у меня есть pci0000:00/прямо в/sys/devices); Я не помню, является ли ACPI ->PCI специализированным форматом, который в принципе не имеет смысла раскрывать, или это Linux, в котором это делается в особых случаях -и не беспокоится о том, чтобы выставлять ACPI в качестве родительского устройства.