Comments 17
Хорошая попытка была у Intel с их AMT на базе чипсета, который имеет доступ ко всем интерфейсам. Но завязка на встроенный GPU в процессор и остальные косяки, такие как закрытость решения и собственные костыли, пилящиеся, по ощущениям, по остаточному принципу убили хорошее начинание. Есть материнка - уже не дектоп, но еще не сервер от gigabyte, и на ней с AMT то тут, то там вылезают косяки. То расшаренный сетевой интерфейс тупит с руганью в dmesg, то рвется коннект к консоли в MeshCommander. Монтирование iso в принципе не работает - виртуальный DVD впадает в бесконечный цикл подключения и отключения USB-устройства.
Вообще-то BMC обязан работать при выключенном питании сервера (или при неисправности / ошибке настроек, исключающей возможность успешного включения материнской платы и инициализации PCI). Он именно для этого и нужен.
Зачем нужен такой BMC, который работает только при работе PCIe, я затрудняюсь представить. Тогда уж проще удалённо админить средствами ОС.
Типичной случай, АМД сервер умирает ещё до запуска биоса. Внутри AMDшного PSP кода.
О каком PCIe тут можно говорить?
Так он и будет работать отдельно. Когда линк подымется, то будет взаимодействовать.
Какой тогда в нем смысл? Любая проблема на этапах BIOS/UEFI до инициализации PCIe становится не диагностируемой.
Смысл в том, и я видел это в железе, что прошивка BMC может участвовать в инициализации и управлении PCIe устройств.
Любая проблема вылезет до перезагрузки сервера, а значит с большой вероятностью попадет в SEL LOG BMC. А уж если PCIe init не прошел, то всегда можно это увидеть на экране через удаленное видео.
Каким образом BMC может участвовать в инициализации PCIe root root complex хоста?
BMC может (и должно) дергать линии типа Reset, Power Enable, идущие в сторону устройств, но вот как средство взаимодействия BMC и хоста (точнее даже, сервисного процессора хоста, как его не назови) PCIe, на мой взгляд, слишком сложно.
Что касается проблемы и SEL, то хост может и не загрузиться, банально битая планка памяти, и всё, до DXE фазы дело не дойдет. В классической схеме мы это увидим по пост коду (который будет очень очень простым и надежным образом получен по LPC, eSPI или от сервисного процессора по UART, например), а если у нас только PCIe, то как? До инициализации PCIe дело не дойдёт, у хоста памяти-то нету, только кэши.
Вероятно, я плохо артикулировал это в статье - но сокеты сервера - это устройства PCIe для BMC. Он их включает/выключает и общается с ними по PCIe, когда возможно.
Как устройство PCIe, сокет может инициализировать линк на этапе BOOT ROM, когда фирмварь даже не загружена. И т.к. на сокете реализованы несколько PCIe функций, то уже на этапе работы BOOT ROM BMC может следить за статусом загрузки, устанавливать различные параметры загрузки и, собственно, передавать по линку сам образ ПО, если флэш сервера еще ни разу не прошивали.
Мой опыт в работе с железом говорит, что инициализация PCIe на таких ранних этапах вполне возможна. Посмотрите к примеру, что творят NXP в их I.MX6/8 SoC.
А кто реализует в таком случае распределение ресурсов на шине PCIe? Как я понял, вы предлагаете фактически либо двойную загрузку, поочерёдно BMC и BIOS, либо первоначальную загрузку целиком силами BMC. Но устройства-то сами согласятся ли быть слейвами у BMC?
Например, одним из устройств PCIe может быть какой-нибудь аппаратный модуль доверенной загрузки, который сам контролирует дальнейшую работу BOOT ROM в зависимости от различных условий. Это всё само по себе требует определённых танцев с бубнами вокруг настроек BIOS для своей работоспособности, а в случае, если этим будет заниматься BMC, это всё приведёт в лучшем случае к повисанию BMC в определённых ситуациях, а в худшем – к неработоспособности системы в принципе.
Что касается ресурсов PCIe, то речь в статье идет об отдельной иерархии management PCIe, где BMC является хостом, а серверные сокеты в ней - устройства. В этой иерархии рутовый комплекс находится в BMC и тот занимается инициализацией устройств на сокетах. Но речь, опять же, о тех IP внутри серверных SoC, которые находятся в домене platform management и не относятся к серверной функции. Т.е. те, что отвечают за коммуникацию информации между серверным сокетом и BMC.
За инициализацию устройств в иерархии PCIe сервера отвечает само ПО сервера.
Что касается загрузкт, то загрузка самого сервера начинается с инициализации SoC. Так например, при включении сокет проверяет бутстрап пины для определения конфигурации загрузки. В статье я предлагаю выбросить эти пины, заменив их IP блоком/PCIe функцией в домене platform management, которая бы захватывала загрузочную конфигурацию по шине (через виртуальные GPIO). А сама загрузка сервера вполне может происходить как обычно - с бут флэша. С т.з. серверного ПО все эти изменения будут видны лишь на самых ранних этапах, возможно до запуска BIOS. У BIOS остаются все те же функции и ответсвенность.
то загрузка самого сервера начинается с инициализации SoC.
Поясните, пожалуйста, что вы имели ввиду?
Если линк не поднимается, значит либо не работает "железо", или BOOT ROM не способно выполнить функцию по его инициализации. BMC будет считать, что SOC неисправен.
Инициализация SoC в данном случае - проведение "сброса" железа и этап работы BOOT ROM, до загрузки ПО из BOOT FLASH.
1x PCIe чтобы управлять всем