reimu.md

Назначение программы

Пакет программного обеспечения REIMU (REmote Intelligent Management Unit) предназначен для проведения действий с модулем на основе процессора Эльбрус-8С или Эльбрус-8СВ (далее платформа). При этом платформа может быть выключена, достаточно подключить к ней STANDBY-питание.

ПО REIMU может устанавливаться как на интегрированный в материнскую плату менеджер AST2400 или AST2500, так и на модуль МУС-А (на базе микросхемы AST2400), вставляемый в специализированный разъём на материнской плате платформы.

ПО REIMU выпускается в виде следующих типов (флаворов) бинарных файлов (прошивок), предназначенных для записи (прошивки) в устройства:

• REIMU-4232M: для прошивки в модули МУС-А.
• REIMU-4232: для прошивки в материнские платы, снабжённые ИС AST2400 с Flash-памятью размера 32 МБ и выводом в порт UART2.
• REIMU-4264: для прошивки в материнские платы, снабжённые ИС AST2400 с Flash-памятью размера 64 МБ и выводом в порт UART2.
• REIMU-4564 (соответствует ТВГИ.00308-01): для прошивки в материнские платы, снабжённые ИС AST2400 с Flash-памятью размера 64 МБ и выводом в порт UART5.
• REIMU-5564 (соответствует ТВГИ.00306-01 и 643.ДАЦН.20001-01): для прошивки в материнские платы, снабжённые ИС AST2500 с Flash-памятью размера 64 МБ и выводом в порт UART5.

Флаворы, число в обозначении которых заканчивается на 32, в дальнейшем называются 32-мегабайтными, остальные - 64-мегабайтными. Флаворы, обозначение которых оканчивается на M, применяются на модулях МУС-А или подобных, остальные - на BMC, интегрированном на материнскую плату.

Модули МУС-А или подобные предназначены для работы в связке с ПЛИС, установленной на материнской плате и реализующей часть функций BMC при его отсутствии. BMC, интегрированные на материнскую плату, реализуют эти функции самостоятельно, и потому ПЛИС на таких платах отсутствует.

ПО REIMU предоставляет следующий функционал:

• Удаленная работа по сети (протокол SSH).
• Включение, выключение и перезагрузка платформы.
• Подключение к последовательному порту платформы (Serial-over-LAN).
• Логирование данных последовательного порта.
• Работа с I²C-устройствами (сенсорами) платформы.
• Отслеживание и индикация состояния перегрева процессоров.
• Отслеживание и установка состояния UID.
• Обновление программы начального старта платформы.
• KVM-over-IP и Media-over-IP (только на AST2500).

Условия выполнения программы

Минимальные системные требования для установки ПО REIMU:

• Используемая ИС типа «система на чипе»: Aspeed AST2400 или AST2500.
• Постоянная память: для AST2400 не менее 32 МБ NOR Flash ROM (рекомендуется: не менее 64 МБ); для AST2500 не менее 64 МБ.
• Оперативная память: не менее 128 МБ (рекомендуется: не менее 256 МБ).

Перед установкой МУС-А в материнскую плату следует убедиться, что все ключи микропереключателя МУС-А стоят в неактивном положении (off).

После подключения STANDBY-питания к платформе её не рекомендуется включать вручную до полной загрузки менеджера (в случае такого включения платформа будет находиться под сбросом до момента готовности менеджера). Процесс загрузки индицируется соответствующим светодиодом (при его наличии) и состоит из следующих этапов:

• Инициализация аппаратуры AST2400 (примерно 5 секунд, светодиод не горит).
• Инициализация U-Boot (примерно 30 секунд, светодиод горит).
• Инициализация ядра ОС и ПО REIMU (примерно 65 секунд, светодиод мигает).
• Окончание загрузки (менеджер готов к работе, светодиод гаснет).

В случае наличия светодиода HEARTBEAT он мигает с частотой порядка 2 Гц начиная с момента инициализации U-Boot.

Полный процесс загрузки занимает примерно полторы минуты. При загрузке U-Boot производится вывод в консоль UART5 (ttyS4) менеджера, при последующих этапах – в основную консоль, которой на различных платах могут являться либо UART2 (ttyS1), либо также UART5 (ttyS4). По окончании загрузки на всех консолях появляется приглашение ко входу в систему (также менеджер становится доступен по протоколу SSH через его сетевые интерфейсы) и загорается светодиод готовности менеджера (сигнал ACTIVE#) при его наличии.

Время загрузки указано условно; в разных случаях загрузка может происходить быстрее или дольше.

Выполнение программы и сообщения оператору

Работа с ПО REIMU

Работа с ПО REIMU осуществляется по последовательному порту (обычно выведен на штыревой или поверхностно-контактный соединитель платформы, помеченный как MNGR CONSOLE, BMC SP или подобным образом), или по локальной сети (один или два интерфейса LAN 10/100 выведены на соединители задней панели платформы).

Параметры подключения к последовательной консоли:

• Скорость: 115200 бит/с.
• Биты данных: 8.
• Стоп-биты: 1.
• Чётность: нет.
• Контроль потока: аппаратный отсутствует, программный отсутствует.
• Кодировка: UTF-8.

Начальные IP-и MAC-адреса интерфейсов:

• Ethernet 0: IP/prefix 192.168.1.1/24 (при недоступности DHCP-сервера), MAC 98:A7:B0:00:00:01 (при отсутствии корректного MAC-адреса во FRU ID).
• Ethernet 1: IP/prefix 192.168.2.1/24 (при недоступности DHCP-сервера), MAC 98:A7:B0:00:00:02 (при отсутствии корректного MAC-адреса во FRU ID).

Можно подключиться к менеджеру по данным адресам, создав локальную сеть.

Для первоначального входа надо ввести логин «root» и пароль «0penBmc» (без кавычек, с учётом регистра, пароль начинается с цифры «ноль»).

Для всех флаворов, кроме REIMU-6564m, в случае наличия корректного MAC-адреса в микросхеме энергонезависимой памяти FRU ID на материнской плате, при загрузке BMC его интерфейсам назначаются следующие MAC-адреса (здесь MAC - MAC-адрес, прочитанный из этой микросхемы):

• Ethernet 0: MAC + 00:00:00:00:00:1E.
• Ethernet 1: MAC + 00:00:00:00:00:1F.

Для флавора REIMU-6564m, в случае наличия корректного MAC-адреса в микросхеме энергонезависимой памяти FRU ID на модуле AST2600_MNGR, при загрузке BMC его интерфейсам назначаются следующие MAC-адреса (здесь MAC - MAC-адрес, прочитанный из этой микросхемы):

• Ethernet 0: MAC + 00:00:00:00:00:00.
• Ethernet 1: MAC + 00:00:00:00:00:01.

Таким образом, MAC-адреса Ethernet-портов BMC задаются данными во FRU ID модуля (для REIMU-6564m), либо во FRU ID материнской платы платформы (все остальные флаворы).

Если ранее интерфейсам BMC были назначены другие MAC-адреса, то после их изменения BMC автоматически перезагружается с новыми адресами.

Если в упомянутой микросхеме указанных данных нет, то MAC-адреса остаются неизменными (если BMC ранее не загружался с корректным FRU ID, то это будут адреса по умолчанию; иначе последние корректные адреса на основе прочитанного из FRU ID).

В случае наличия DHCP-сервера по умолчанию адрес запрашивается у этого сервера (в качестве идентификатора используется MAC-адрес). Если это не удалось, то IP-адреса устанавливаются по умолчанию.

Первоначальная настройка REIMU

Смена пароля производится по аналогии с GNU/Linux, командой passwd (см. документацию: https://www.opennet.ru/man.shtml?topic=passwd&category=1).

Настройки профиля пользователей (например, переменные для задания прокси-сервера и т. п.) могут быть заданы с помощью файлов в каталоге /etc/profile.d/. Файлы должны иметь расширение .sh. По умолчанию там есть файл 00-exportvars.sh, в котором экспортируются переменные LANG, TERM и BASH (для более корректной работы mc).

Смена настроек сети (IP- и MAC-адресов и шлюза по умолчанию) производится редактированием файлов /etc/systemd/network/00-bmc-eth?.network (на место знака вопроса следует подставить номер необходимого интерфейса). Синтаксис этих файлов описан в руководстве по systemd-networkd (https://wiki.archlinux.org/index.php/Systemd-networkd).

Пример задания статических настроек сети:

[Match]
Name=eth0
[Address]
Address=192.168.1.1/24
[Route]
Gateway=192.168.1.100

Поддерживается получение настроек по DHCP; для этого содержимое секций [Network] и [DHCP] соответствующего файла должно выглядеть примерно так (детали зависят от настройки DHCP-сервера в сети):

[Network]
DHCP=yes
[DHCP]
ClientIdentifier=mac
UseDNS=yes
UseDomains=yes

В файлах /etc/ip-fallback/fallback-eth0.conf и /etc/ip-fallback/fallback-eth1.conf также указаны параметры FallbackAddress и FallbackTimeout, например:

FallbackAddress=192.168.1.1/24
FallbackTimeout=60

Если эти файлы существуют и эти настройки в них заданы, то после прошествия FallbackTimeout секунд с момента запуска сети, если DHCP-сервер не назначил корректного IP-адреса, или из-за отсутствия сетевого кабеля не установился статический адрес, то этому интерфейсу будет назначен адрес FallbackAddress.

Следует отметить, что этот режим предназначен исключительно для первоначальной настройки REIMU без DHCP-сервера. В частности, при активации FallbackAddress не устанавливается broadcast-адрес, gateway и другие параметры, только IP-адрес.

При отключении и повторном подключении кабеля IP-адрес FallbackAddress будет отключен до перезагрузки BMC (если это критично, то следует воспользоваться параметром ConfigureWithoutCarrier настройки systemd-networkd). Если необходимо использовать статическую настройку IP-адреса, его нужно вручную прописать в настройках, а не полагаться на FallbackAddress: это позволит сэкономить время активации сети при загрузке BMC, а также избежать отключения сети при пропадании соединения.

Если настройка какого-нибудь интерфейса не требуется (например, eth1 на многих платах просто не выведен, и его настраивать смысла нет), то в файле /etc/systemd/network/00-bmc-eth?.network его нужно обозначить как unmanaged. В таком случае это будет выглядеть как-то так (для примера, показан интерфейс eth1):

[Match]
Name=eth1
[Link]
Unmanaged=yes

Для авторизации пользователей возможно использовать LDAP. Для этого необходимо скопировать в файловую систему менеджера правильно сконфигурированные файлы /etc/openldap/ldap.conf, /etc/nslcd.conf и отредактировать нужным образом файл /etc/nsswitch.conf. Возможно подключение файловых систем через AutoFS с поддержкой NFS и LDAP; данный функционал настраивается посредством редактирования файла /etc/auto.master.

Изменения файловой системы сохраняются между перезагрузками благодаря механизму OverlayFS (см. https://en.wikipedia.org/wiki/OverlayFS), при этом размеры разделов составляют (соответственно на ПЗУ размером 32 и 64 МБ):

• Данные только для чтения: 28 или 48 МБ (путь к слою: /run/initramfs/ro).
• Данные для чтения и записи: 4 или 16 МБ (путь к слою: /run/initramfs/rw).

Техническая возможность не сбрасывать время при выключении питания менеджера (т. е. STANDBY-питания платформы) на данный момент предусмотрена только на материнских платах с AST2500, имеющих часы реального времени, питаемые от батарейки, на шине I²C. По умолчанию это часы, использующие драйвер mcp7941x с адресом 0x6f на второй шине BMC; это можно настроить, соответствующим образом отредактировав файл /etc/reimu.d/rtc.conf. При наличии таких часов, при каждой загрузке время из них прочитывается и по нему устанавливаются системные часы операционной системы BMC и встроенные в AST2500 внутренние часы реального времени.

В случае, если такой микросхемы на плате не установлено, или в ней находится неверное время, рекомендуется его настроить командой date после загрузки менеджера после подачи STANDBY-питания (согласно руководству по её использованию: https://www.opennet.ru/man.shtml?topic=date&category=1).

Чтобы установленное время не сбрасывалось при перезагрузке (а также при снятии STANDBY-питания на материнских платах, где это возможно), необходимо сохранить его во всех доступных BMC часах реального времени BMC, например, командой for i in /dev/rtc?; do hwclock --systohc --rtc $i; done.

В случае неправильно установленного времени возможна некорректная работа различного ПО, например, web-сервера или программы htop (она не запускается, сообщая об ошибке типа No btime in /proc/stat: Success).

Корневой каталог пользователя root настроен на путь /home/root. Если необходимо перенести его в другой каталог (например, если /home является точкой монтирования AutoFS), то нужно отредактировать соответствующим образом файл /etc/profile, или создать в новом домашнем каталоге файл .profile (если его там нет), в который добавить строчку:

export PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin

Это позволит пользователю root использовать исполняемые файлы из указанных каталогов.

Сброс к заводским настройкам

Для сброса ПО к заводским настройкам следует при подаче STANDBY-питания (либо во время перезагрузки BMC) произвести определённые манипуляции с кнопкой UID:

• На BMC, интегрированных на материнскую плату: зажать и держать кнопку UID.
• На модулях МУС-А: сразу (в течение 10 секунд) после включения питания или начала перезагрузки BMC (или заранее, до начала перезагрузки) включить светодиод UID кнопкой, а после того, как он выключится в процессе загрузки, немедленно (в течение 5 секунд) включить его ещё раз.

После этого светодиод UID мигнёт три раза и погаснет: это будет подтверждением того, что команда на сброс настроек принята BMC (после этого можно отпустить кнопку UID). BMC удалит все данные с пользовательского раздела и перезагрузится.

Следует иметь в виду, что настройки MAC-адреса не будут стёрты, так как хранятся в блоке настроек U-Boot, а не пользовательском разделе. Штатный способ изменить настройки MAC-адреса после того, как они были подгружены из FRU ID EEPROM - это вставить модуль в материнскую плату платформы с другим FRU ID (или перепрошить эту EEPROM).

При необходимости (при наладке платформы) возможно сбросить настройки MAC-адреса (при наличии доступа к SSH-консоли или последовательному порту BMC) подачей следующих команд и последующей перезагрузкой BMC:

fw_setenv ethaddr; fw_setenv ethaddr; fw_setenv eth1addr; fw_setenv eth1addr

Здесь для каждой из двух переменных ethaddr и eth1addr команда fw_setenv подаётся дважды, поскольку переменная должна быть сброшена в двух разделах параметров U-Boot, основном и вторичном.

Очевидно, что при наличии FRU ID EEPROM на материнской плате платформы, настройки из неё будут вновь подгружены при следующей перезагрузке менеджера (с последующей перезагрузкой ещё раз с прочитанными MAC-адресами).

SSH-консоли и COM-over-IP

Подключение к REIMU по сети с удаленной машины осуществляется по протоколу SSH на порт 22. При первом заходе на несконфигурированный менеджер возможно длительное ожидание (порядка 2-3 минут), поскольку в это время будут создаваться SSH-ключи хоста.

С удалённой машины также реализована возможность подключиться сразу к последовательному порту платформы (по умолчанию SSH на порт 2022). При этом будет произведено подключение к мультиплексору терминалов tmux, внутри которого запущен minicom, настроенный на работу с портом UART1 (ttyS0) менеджера, который на материнской плате соединён с портом ttyS1 платформы.

Для того, чтобы через последовательную консоль, предоставляемую REIMU, можно было войти в сеанс командной строки платформы, на ОС Эльбрус необходимо убедиться, что в файле /etc/inittab присутствует строчка вида:

s1:2345:respawn:/sbin/agetty -L ttyS1 115200

Если её там нет, то нужно добавить её в конец файла и перезагрузить платформу.

На ОС, использующих systemd (ОС Эльбрус-Д, Astra Linux, Alt Linux) нужно штатным образом включить юнит serial-getty@ttyS1.service, если он не включен.

Также, если интересует вывод ядра и init в процессе загрузки, то следует в файле /boot/boot.conf указать в качестве одного из параметров ядра console=ttyS1,115200. При этом больше в строке параметров ядра не должно присутствовать консолей типа ttySx из-за ограничений ядра Linux.

Изменить порт прямого входа на COM-порт платформы (по умолчанию: 2022) можно, изменив необходимый номер порта в трёх местах:

• в файле /etc/ssh/sshd_config в строке Port 2022;
• там же, в строке Match LocalPort 2022;
• в файле /lib/systemd/system/sshd.socket в строке ListenStream=2022.

При подключении по SSH (на любой из сконфигурированных портов) будет запрошен пароль пользователя. Отключиться от cессии Serial-over-LAN можно, последовательно нажав сочетание клавиш Ctrl+B, отпустив его, затем нажав D (далее такие комбинации клавиш будут указаны через пробел, например, в данном случае – «Ctrl+B D») – это команда «detach» мультиплексора терминалов tmux. Подключаться может одновременно неограниченное количество пользователей, все пользователи имеют доступ как на ввод, так и вывод. Размер терминала выбирается наименьший из всех подключенных сессий.

Если пользователь уже подключен к менеджеру по SSH на обычный порт, то он может получить доступ к COM-порту платформы, выполнив команду tmux attach. При отключении по «Ctrl+B D» он вернётся в свой шелл, откуда он выполнил указанную команду.

Локаль на всех консолях: ru_RU.UTF-8.

Лог данных из COM-порта платформы по умолчанию сохраняется в файле /var/log/sol.log, хранящемся в оперативной памяти менеджера (при перезагрузке менеджера содержимое лога теряется). Лог автоматически сбрасывается в каталог /usr/log по достижении объёма 1 МБ (сохраняются три последних лога). Также в этом каталоге имеется ссылка на текущий лог с именем current и его сжатый бэкап current.gz, который пересоздаётся раз в минуту.

Возможно сменить этот путь на какой-либо сетевой ресурс (например, общий каталог NFS, подключаемый механизмом AutoFS). Путь меняется в файле /etc/sol.conf; следует отредактировать строку «SOL_LOGPATH="/var/log/sol.log"», заменив в нём имя файла на нужное. Если логирование не нужно, то достаточно закомментировать эту строчку. После изменения этого файла следует перезапустить менеджер (или можно просто перезапустить сервис tmux-logger с помощью команд systemctl stop tmux-logger, затем, через пару секунд, systemctl start tmux-logger). При отключении или переносе лога также рекомендуется отключить сервисы systemd с названиями logrotate-sol.service и logrotate-sol.timer, поскольку ротация несуществующего более лога смысла не имеет.

Логирование (если оно включено) ведётся даже в отсутствие подключенной SSH-сессии. Временно отключить (и затем включить) логирование в сессии можно, нажав «Ctrl+A L». Файл не следует удалять (в таком случае Minicom потеряет к нему доступ); если его нужно вручную очистить, то для этого следует пользоваться командой truncate.

Web-интерфейс

Web-интерфейс менеджера присутствует только на 64-мегабайтных флаворах. Он доступен по протоколу https.

При заходе на страничку предлагается ввести логин и пароль (в общем случае можно вводить логин root и пароль, назначенный для этого пользователя). Аутентификацию по LDAP можно настроить, воспользовавшись пунктом меню Access – LDAP; локальным пользователям можно дать доступ к web-интерфейсу через пункт Access – Local Users.

При первичном заходе браузер может предупреждать о том, что SSL-сертификат хоста самоподписанный. В случае, если имеется возможность сделать сертификат для менеджера, его можно загрузить, воспользовавшись пунктом меню Access – SSL Certificates.

Пункты web-интерфейса:

• Overview – позволяет посмотреть информацию о менеджере и состоянии платформы.
• Health – Event log – позволяет посмотреть логи системы (SEL, Event, OEM). На данный момент в эти логи ничего не пишется.
• Health – Hardware status – позволяет посмотреть аппаратные компоненты системы. На данный момент в нём ничего нет, в перспективе планируется собирать информацию из FRU ID и с устройств материнской платы и добавлять её туда.
• Health – Sensors – позволяет посмотреть показания сенсоров BMC и платформы (при наличии их описания в device tree платформы).
• Control – Server power operations – позволяет включать, выключать, перезагружать платформу, а также смотреть, включена ли она.
• Control – Server LED – позволяет управлять и просматривать статус светодиода UID.
• Control – Reboot BMC – позволяет перезагрузить BMC. Внимание: это приведёт и к перезагрузке платформы, если она работает.
• Control – Virtual Media – позволяет подключить виртуальный носитель к платформе (только на материнских платах с BMC AST2500).
• Configuration – Network settings – позволяет задать настройки сети BMC.
• Configuration – SNMP settings – позволяет добавить дополнительные SNMP-датчики.
• Configuration – Date and time settings – позволяет задать дату и время на менеджере или настроить их синхронизацию по NTP.
• Access – LDAP – позволяет настроить аутентификацию LDAP-пользователей для доступа к web-интерфейсу.
• Access – Local users – позволяет настроить аутентификацию локальных пользователей для доступа к web-интерфейсу.
• Access – SSL certificates – позволяет загрузить SSL-сертификаты для доступа к web-интерфейсу.

После обновления прошивки, перезагрузки BMC, перенастройки сети, времени и других системных настроек BMC рекомендуется закрыть все открытые страницы web-интерфейса и аутентифицироваться в нём заново.

Иногда при заходе в web-интерфейс может появиться предупреждение Can't subscribe to notifications, use Refresh button.. Это означает, что из-за проблем с сетью не получилось подписаться на обновления статусов питания сервера через WebSocket. В таком случае статус на странице Control – Server power operations и в заголовке интерфейса обновляться не будет, пока пользователь не нажмёт кнопку Refresh в заголовке.

В случае частого появления таких предупреждений рекомендуется обновить браузер и/или проверить настройку сети между BMC и компьютером, на котором открыт web-интерфейс.

KVM-over-IP

Для флавора REIMU-5564 возможно подключение по VNC к экрану :0 на менеджере.

Пароль VNC по умолчанию – «0penBmc» (без кавычек, с учётом регистра, пароль начинается с цифры «ноль»). Сменить его можно командой vncpasswd в шелле REIMU.

Рекомендуется использовать следующие параметры подключения к VNC-серверу (в особенности, если подключение с более качественными настройками не устанавливается):

• Размер экрана (Screen size): не более 1024х768.
• Сжатие (Compression): ZRLE (не Tight).
• Качество цветопередачи (Color quality): Medium (не Full).
• Разрешить сжатие JPEG (Allow JPEG compression): выключено.

Media-over-IP

Для флавора REIMU-5564 возможно подключение удалённых образов дисков к платформе.

Для этого необходимо в web-интерфейсе выбрать пункт меню Control – Virtual Media, выбрать необходимый образ диска и запустить подключение кнопкой "Start". Отключить его можно кнопкой "Stop" (которая появится на месте кнопки "Start").

Подключенный образ будет виден в операционной системе платформы как USB-диск (например, /dev/sdb).

Включение, выключение, перезагрузка платформы, работа с UID

Следующие команды SSH- или COM-консоли REIMU позволяют включать, выключать и перезагружать платформу:

• server_pwr_on – включение платформы (если платформа выключена, нажатие кнопки питания на 0,2 секунды);
• server_pwr_off – запрос на мягкое выключение платформы (если платформа включена, нажатие кнопки питания на 0,2 секунды);
• server_pwr_off_hard – жёсткое выключение платформы (если платформа включена, нажатие кнопки питания на 5 секунд);
• server_reset – перезагрузка платформы (нажатие кнопки сброса на 0,2 секунды);
• server_pwrbut_s – безусловное нажатие кнопки питания на 0,2 секунды (для совместимости с предыдущими версиями REIMU);
• server_pwrbut_h – безусловное нажатие кнопки питания на 5 секунд (для совместимости с предыдущими версиями REIMU).

Команды server_pwr_* не производят никаких действий, если платформа уже находится в нужном состоянии.

Вместо запуска некоторых из этих команд можно запустить следующие сервисы systemd (например, с помощью команды systemctl start):

• server_pwr_on – сервис host-poweron.service;
• server_pwr_off – сервис host-poweroff.service;
• server_pwr_off_hard – сервис host-poweroff-hard.service;
• server_reset – сервис host-reset.service.

Возможно автоматическое включение питания платформы при подключении к ней STANDBY-питания. Этот функционал конфигурируется с помощью файла /etc/auto_power_on. Данный файл представляет собой включаемый bash-скрипт с заданием следующих переменных:

• AUTO_POWER_ON: off – оставлять платформу выключенной, on – включать её в любом случае, auto – включать только в случае, если за PS_DISCHARGE_TIME секунд до пропадания STANDBY-питания она была включена.
• POWER_ON_DELAY: значение в секундах, не менее которого следует ожидать перед включением питания платформы, если AUTO_POWER_ON=on или AUTO_POWER_ON=auto и последний сохранённый статус питания был "платформа включена". Отсчёт времени начинает вестись с момента запуска systemd-сервиса allow_host_boot; этот же сервис снимает сброс с платформы.
• PS_DISCHARGE_TIME: значение в секундах, сколько следует ожидать перед тем, как сохранить изменённый статус питания платформы после его изменения.

Актуальность последнего параметра связана с тем, что некоторые блоки питания выключают STANDBY-питание немного позже, чем основное при пропадании входного напряжения. Из-за этого платформа выключается чуть раньше, чем BMC, и последний успевает записать статус "выключен", хотя перед пропаданием входного напряжения платформа была включена.

Значение этого параметра следует подбирать в зависимости от используемого блока питания. Оно должно быть не меньше, чем то время, которое STANDBY-питание ещё подаётся на материнскую плату платформы после пропадания входного напряжения, но и не больше, чем разумное время между нормальным выключением платформы, а потом отключением первичного питания, при котором платформа считается штатно переведённой предварительно в выключенное состояние. Для многих блоков питания разумной величиной является 10-15 секунд, хотя у некоторых (в особенности мощностью от 1000 Вт) это время может достигать 30-40 секунд.

Текущий статус питания (независимо от значения AUTO_POWER_ON) также сохраняется в файле /var/lib/reimu/last_power_state в виде значения 0 или 1 (он обновляется через PS_DISCHARGE_TIME секунд после актуального момента включения/выключения платформы).

Следует отметить, что на материнских платах, на которых отсутствует схема задержки включения питания, необходимая для КПИ-2, BMC не имеет возможности управлять состоянием питания платформы в момент подачи STANDBY-питания, и описанная функциональность не будет работать: платформа включится сразу при подаче STANDBY-питания вне зависимости от настроек /etc/auto_power_on.

Работа с UID осуществляется, помимо кнопки UID, командой server_uid:

• server_uid on – включить индикатор UID;
• server_uid off – выключить индикатор UID;
• server_uid query – проверить состояние UID и вернуть код возврата;
• server_uid show – сделать то же самое и вывести состояние в консоль.

Команды query и show возвращают 0 в случае, если UID выключен, и 1 – если включён. Это полезно для использования в пользовательских скриптах.

DBus

На 64-мегабайтных флаворах доступно выполнение команд управления платформой с помощью посылки сообщений DBus, например, командой busctl.

Например:

• busctl get-property xyz.openbmc_project.State.Host /xyz/openbmc_project/state/host0 xyz.openbmc_project.State.Host CurrentHostState – показать текущий статус питания платформы;
• busctl set-property xyz.openbmc_project.State.Host /xyz/openbmc_project/state/host0 xyz.openbmc_project.State.Host RequestedHostTransition s xyz.openbmc_project.State.Host.Transition.On – включить платформу;
• busctl set-property xyz.openbmc_project.State.Host /xyz/openbmc_project/state/host0 xyz.openbmc_project.State.Host RequestedHostTransition s xyz.openbmc_project.State.Host.Transition.HardOff – жёстко выключить платформу;
• busctl set-property xyz.openbmc_project.State.Host /xyz/openbmc_project/state/host0 xyz.openbmc_project.State.Host RequestedHostTransition s xyz.openbmc_project.State.Host.Transition.Off – мягко выключить платформу;
• busctl set-property xyz.openbmc_project.State.Host /xyz/openbmc_project/state/host0 xyz.openbmc_project.State.Host RequestedHostTransition s xyz.openbmc_project.State.Host.Transition.Reboot – перезагрузить платформу;
• busctl set-property xyz.openbmc_project.LED.GroupManager /xyz/openbmc_project/led/groups/enclosure_identify xyz.openbmc_project.Led.Group Asserted b true – включить светодиод UID;
• busctl set-property xyz.openbmc_project.LED.GroupManager /xyz/openbmc_project/led/groups/enclosure_identify xyz.openbmc_project.Led.Group Asserted b false – выключить светодиод UID;
• busctl get-property xyz.openbmc_project.LED.GroupManager /xyz/openbmc_project/led/groups/enclosure_identify xyz.openbmc_project.Led.Group Asserted – показать статус светодиода UID.

IPMI

На 64-мегабайтных флаворах доступно выполнение команд управления платформой с помощью протокола IPMI, например, командой ipmitool.

Например, возможны следующие команды:

• chassis power status – показать текущий статус питания платформы;
• chassis power on – включить платформу;
• chassis power off – жёстко выключить платформу;
• chassis power soft – мягко выключить платформу;
• chassis power reset – перезагрузить платформу;
• chassis identify force – включить светодиод UID;
• chassis identify 0 – выключить светодиод UID;
• chassis identify N – включить светодиод UID на N секунд, затем выключить.

Локально (в SSH-сессии BMC) эти команды просто передаются как аргументы команды ipmitool.

Удалённо можно выполнять эти команды с использованием протокола lanplus:

ipmitool -I lanplus -C 17 -H <хост> -U <логин> -P <пароль> <команда и параметры>.

Здесь слова <хост>, <логин> и <пароль> нужно заменить на те, на которые настроен BMC.

Redfish

На 64-мегабайтных флаворах доступно выполнение команд управления платформой с помощью протокола Redfish, например, отправляя запросы с помощью curl.

Сначала нужно аутентифицироваться и получить токен:

curl -s --insecure -X POST https://<хост>/redfish/v1/SessionService/Sessions -d '{"UserName":"<логин>", "Password":"<пароль>"}' -D - | grep 'X-Auth-Token' | sed 's/X-Auth-Token: //'

Здесь и далее слова <хост>, <логин> и <пароль> нужно заменить на те, на которые настроен BMC.

Вывод вышеприведённой команды далее будет использоваться во всех обращениях в месте, где написано <токен>.

Примеры запросов по протоколу Redfish:

• curl -s -k -H "X-Auth-Token: <токен>" -X GET https://<хост>/redfish/v1/Systems/system/ | grep PowerState – показать текущий статус питания платформы;
• curl -s -k -H "X-Auth-Token: <токен>" -X POST https://<хост>/redfish/v1/Systems/system/Actions/ComputerSystem.Reset -d '{"ResetType": "On"}' – включить платформу;
• curl -s -k -H "X-Auth-Token: <токен>" -X POST https://<хост>/redfish/v1/Systems/system/Actions/ComputerSystem.Reset -d '{"ResetType": "ForceOff"}' – жёстко выключить платформу;
• curl -s -k -H "X-Auth-Token: <токен>" -X POST https://<хост>/redfish/v1/Systems/system/Actions/ComputerSystem.Reset -d '{"ResetType": "GracefulShutdown"}' – мягко выключить платформу;
• curl -s -k -H "X-Auth-Token: <токен>" -X POST https://<хост>/redfish/v1/Systems/system/Actions/ComputerSystem.Reset -d '{"ResetType": "ForceRestart"}' – перезагрузить платформу;
• curl -s -k -H "X-Auth-Token: <токен>" -X PATCH https://<хост>/redfish/v1/Systems/system/ -d '{"IndicatorLED": "Lit"}' – включить светодиод UID;
• curl -s -k -H "X-Auth-Token: <токен>" -X PATCH https://<хост>/redfish/v1/Systems/system/ -d '{"IndicatorLED": "Off"}' – выключить светодиод UID;
• curl -s -k -H "X-Auth-Token: <токен>" -X GET https://<хост>/redfish/v1/Systems/system/ | grep IndicatorLED – показать статус светодиода UID.

После обновления прошивки, перезагрузки BMC, перенастройки сети, времени и других системных настроек BMC рекомендуется аутентифицироваться заново, получив новый токен.

Определение перегрева процессоров

По умолчанию в ПО REIMU включен демон overheatd, который использует протоколы GPIO, TinySPI (при наличии ПЛИС, реализующей этот протокол, на платформе; описание данного протокола приведено в документации на прошивку ПЛИС: http://git.lab.sun.mcst.ru/molchan_i/e8c_cpld_firmware/blob/master/docs/TinySPI_description.doc) и драйвер hwmon для определения событий перегрева процессоров. В случае допустимого перегрева процессоров (температура как минимум одного сенсора присутствующего в платформе процессора выше установленного лимита, по умолчанию плюс 85 ºC) начинает мигать светодиод перегрева на передней панели сервера (подключенный к разъёму «Overheat/Fan Fail» панелей фирмы Supermicro или к разъёму «Overheat» панелей фирмы «Депо»). В случае критического перегрева (выдачи процессором сигнала TTRIP, включая ситуацию, когда материнская плата экстренно выключила питание процессоров) данный светодиод светится постоянно.

Демон управляется стандартным образом с помощью systemctl.

Конфигурация демона осуществляется с помощью редактирования параметров в файле /etc/overheatd.conf:

Название параметра	Значение по умолчанию	Смысл параметра
OVERHEATD_ENABLED	yes	При значении «no» демон не производит никаких операций в процессе своей работы.
DEBUG	off	При значении «on» демон в процессе работы выводит отладочную информацию. Не рекомендуется изменять.
CPU_TEMP_LIMIT	85	Лимит температуры (в ºC), при нагреве выше которой процессор считается находящимся в состоянии перегрева.
WAIT_MSEC	5000	Интервал (в мс) между опросами состояния процессоров.
BLINK_MSEC	500	Полупериод мигания светодиода перегрева при превышении температурой процессора значения CPU_TEMP_LIMIT.

При наличии проблем с определением наличия процессоров можно проверить наличие термодатчиков процессоров на всех перечисленных шинах с помощью утилиты i2cdetect (см. руководство по её эксплуатации: https://linux.die.net/man/8/i2cdetect), также входящей в состав ПО REIMU. При включенной платформе на шине, на которой в device tree платформы описаны термодатчики l_pcs_i2c, в режиме -r и/или -q должны присутствовать устройства с шестнадцатеричными адресами 20-2f (для CPU0), 30-3f (для CPU1), 40-4f (для CPU2) и/или 50-5f (для CPU3).

Для проверки корректности работы светодиода можно послать сигнал SIGUSR1 процессу демона (например, командой killall -USR1 overheatd):

• После первого сигнала демон начинает безусловно считать температуру процессоров превышевшей лимит – состояние симулированного допустимого перегрева (при включённой платформе это приведёт к миганию светодиода перегрева).
• После второго сигнала демон начинает считать состояние критического перегрева активным – состояние симулированного критического перегрева (при включённой платформе это приведёт к зажиганию и постоянному горению светодиода перегрева, которое продолжится, даже если платформа будет выключена).
• После третьего сигнала демон вернётся к нормальной работе. Последующие сигналы будут приводить к повторению описанных состояний по кругу.

На материнских платах с CPLD, для того, чтобы светодиод перегрева погас после подачи третьего сигнала SIGUSR1, платформу нужно включить (если она была выключена, пока находилась в состоянии симулированного критического перегрева). Разумеется, при этом платформа не должна действительно находиться в состоянии критического перегрева.

Управление светодиодами, проверка состояния платформы

В состав ПО менеджера включена служебная утилита setled. Она предназначена для ручного управления светодиодами (например, для проверки их работоспособности или для индикации каких-либо событий в пользовательских скриптах). Справку по её использованию можно получить, запустив её с параметром --help:

setled --help

Данная утилита позволяет управлять следующими светодиодами:

• «Alarm», «Fan Fail», «Overheat» – имеются на панели фирмы «Депо» (последний в двух экземплярах).
• «Fan Fail/Overheat» – имеется на большинстве панелей индикации фирмы Supermicro.
• «Power Fail» – имеется на некоторых панелях индикации фирмы Supermicro.
• «System Fail 1», «System Fail 2» – имеются на панелях индикации стандарта SSI EEB.

Следует отметить, что панели Supermicro и панели SSI EEB подключаются к разным разъёмам на материнской плате. Также на некоторых панелях фирмы Supermicro светодиод «Fan Fail/Overheat» имеет синий цвет, а не красный.

Для флавора REIMU-4232M названия светодиодов «Alarm» и «System Fail 1» соответствуют одному и тому же светодиоду. То же самое справедливо для «Fan Fail», «Overheat» и «Fan Fail/Overheat».

С помощью команды checkalerts можно просмотреть состояния сигналов питания, сброса, целостности корпуса и особых состояний (ALERT, FAULT, TCRIT, TTRIP), специфичных для материнской платы.

Файл systemstate.xml

При работе демона overheatd в каталоге /var/volatile создаётся и постоянно обновляется файл systemstate.xml. Его содержимое можно просмотреть из последовательной консоли или ssh-сессии менеджера командой типа cat /var/volatile/systemstate.xml или открыть любым парсером xml-файлов.

Данный файл содержит блок state с параметром date, соответствующим дате последнего обновления, внутри которого находятся:

• блок alerts, содержащий текущее значение регистра статуса TinySPI (см. руководство: http://git.lab.sun.mcst.ru/molchan_i/e8c_cpld_firmware/blob/master/docs/TinySPI_description.doc; только на материнских платах с CPLD) или сигналов ALERT, TCRIT и подобных, заходящих на менеджер (только на материнских платах без CPLD) в шестнадцатеричном формате;
• блок cpus, содержащий номера обнаруженных термодатчиков процессоров (от 0 до 3; если ни один процессор не обнаружен, этот блок будет пуст; если питание выключено, этого блока, как, очевидно, и последующих блоков temperаture, не будет);
• некоторое количество (зависит от количества обнаруженных процессоров) блоков temperаture с параметрами cpu (номер процессора) и sensor (номер накристалльного датчика этого процессора), содержащих температуру, измеренную этим датчиком. Назначение датчиков следует определять из документации на процессор.

Данный файл позволяет автоматизированно удалённо определять параметры, относящиеся к работе платформы (к примеру, пользовательская система контроля может собирать эти данные с платформ и агрегировать их для дальнейшего анализа администратором).

Назначение битов значения alerts:

Бит	На платах с CPLD	На платах без CPLD
31	GPI[7]	PLT_RST#
30	GPI[6]	Всегда 0
29	GPI[5]	Всегда 0
28	GPI[4]	Всегда 0
27	GPI[3]	Всегда 0
26	GPI[2]	Всегда 0
25	GPI[1]	Всегда 0
24	GPI[0]	Всегда 0
23	APMDZ_LED#	APMDZ_LED#
22	GPIO_3V3_K9	Всегда 0
21	PWROK_MAIN	PWROK_ATX
20	APMDZ_ACTIVE#	Всегда 1
19	GPIO_1V8_H10	Всегда 0
18	GPIO_1V8_G10	Всегда 0
17	GPIO_1V8_F10	Всегда 0
16	GPIO_1V8_C8	Всегда 0
15	I2CM_TTRIP#	Всегда 1
14	I2CM_ALERT#	ALERT_CPU#
13	I2C3_TCRIT#	Всегда 1
12	I2C3_ALERT#	ALERT_CPU2#
11	I2C2_ALERT#	ALERT_PCIE#
10	I2C1_FAULT#	ALERT_FRU#
9	I2C1_TCRIT#	TCRIT_SMBUS#
8	I2C1_ALERT#	ALERT_SMBUS#
7	I2C0_TCRIT#	Всегда 1
6	I2C0_ALERT#	ALERT_MEM#
5	MNGR_ACTIVE#	Всегда 1
4	INTRUSION_SW#	INTRUSION_SW#
3	UID_LED	Всегда 0
2	PB_WAS_PRESSED	Всегда 1
1	WATCHDOG_ENABLED	Всегда 0
0	THERMAL_SHDN#	Всегда 1

Работа с I²C-устройствами материнской платы

В ПО REIMU имеется поддержка широкого спектра I²C-устройств, в их числе ADT7475, MAX31790, LM63, LM75, NCT7904, ADM1275, IR35221, LM25066, LTC2978, MAX31785, MAX34440, UCD9000, UCD9200, TMP421, W83773G, LTC4306, AT24 и другие.

Описания I²C-датчиков платформы берутся из данных device tree платформы и автоматически инстанцируются при включении основного питания платформы, и деинстанцируются при его выключении. Также возможно вручную инстанцировать/деинстанцировать любое устройство.

Ниже приведена краткая сводка нумерации шин I²C:

В ОС	На МУС-А	На AST2x00
0	IPMB A	IPMB A
1	IPMB B	IPMB B
2	I2C3	I2C3
3	I2C4	I2C4
4	–	I2C5
5	I2C0	I2C6
6	I2C1	I2C7
7	I2C2	I2C8
8	–	I2C9
9	–	I2C10
13	–	I2C14

Ручное инстанцирование I²C-устройств производится стандартным для Linux-интерфейса sysfs способом – через метафайл new_device нужной шины. Для примера, инстанцирование EEPROM-памяти типа 24с128 с адресом 0x57 на шине 3 осуществляется подобной командой:

echo 24c128 0x57 > /sys/bus/i2c/devices/i2c-3/new_device

После этого в файловой системе появляется подкаталог с названием типа /sys/bus/i2c/devices/i2c-3/3-0057/, в котором лежат метафайлы для управления выбранным устройством, а также чтения и записи данных. В частности, для рассматриваемого случая в этом каталоге будет файл eeprom с содержимым EEPROM-памяти. Для термодатчиков и контроллеров вентиляторов (например, устройство lm96163) там (внутри каталога hwmon/hwmon?) будут файлы для управления PWM-контроллерами (pwm?, pwm?_enable), а также данные с тахометров и температурных датчиков (temp?_input, fan?_input). Мультиплексоры шины типа LTC4306 просто создадут несколько дополнительных каталогов /sys/bus/i2c/devices/i2c-*, с которыми можно работать, как и с имеющимися изначально шинами.

Деинстанцирование I²C-устройств производится через метафайл delete_device нужной шины. Например, для приведённого примера EEPROM-памяти:

echo 0x57 > /sys/bus/i2c/devices/i2c-3/delete_device

После этого каталог /sys/bus/i2c/devices/i2c-3/3-0057/ пропадёт.

Дополнительное ПО

В ПО REIMU включена утилита rawi2ctool. Она может применяться при отладке и выявлении проблем с шиной I²C и позволяет работать с I²C-устройствами на низком уровне с помощью команд SEND и RECV, то есть осуществлять прямое чтение/запись в I²C slave (вместо команд WRITE и READ с адресом регистра внутри I²C slave, применяемых в утилитах i2cget и i2cset). Она поддерживает три режима работы – с помощью системных вызовов read()/write(), с помощью пакетного IOCTL I2C_RDWR и с помощью команд SMBus (включая quick-команды, т. е. без посылки данных). Справку по её использованию можно получить, запустив её без параметров.

В ПО REIMU имеется файловый менеджер Midnight Commander версии 4.8.24. Запускается командой mc. Поддерживает подключение к удалённым файловым системам по протоколам FTP и SSH.

При необходимости проверить частоты CPU, AHB и PCLK, а также (только для AST2500) памяти, DPLL, BCLK и HCLK можно командой astclkinfo, запустив её без параметров.

Также в ПО REIMU имеются стандартные диагностические утилиты и пакеты: sysstat, htop, i2c-tools; в 64-мегабайтных флаворах прошивки также присутствуют tcpdump, ethtool, perf, ipmitool, iptables и другие.

Обновление содержимого ПЗУ менеджера

Обновление прошивки в ПЗУ менеджера возможно с помощью утилиты firmware-updater. Справку по её использованию можно получить, запустив её с параметром -h или --help. Она позволяет прошивать менеджер либо уже скопированным на него файлом прошивки, либо скачиваемым из сети по протоколам HTTP, HTTPS, FTP или SCP.

Для 64-мегабайтных флаворов прошивки поставляются в двух форматах: .mtd-файл для прошивки с помощью программатора, и .mtd.tar-файл для прошивки с помощью firmware-updater. Для 32-мегабайтных флаворов прошивки поставляются только в формате .mtd-файла для прошивки с помощью как программатора, так и firmware-updater.

Пример запуска для скачки файла прошивки с файл-сервера (например, протокол HTTP):

firmware-updater http://example.org/files/fimware.mtd.tar

Пример запуска для забора файла прошивки с сервера по протоколу SCP:

firmware-updater scp://admin@example.org:/files/fimware.mtd.tar

Пример запуска для прошивки уже каким-либо образом скачанным в файловую систему менеджера файлом:

firmware-updater file:///tmp/fimware.mtd.tar

После успешной прошивки будет автоматически произведена перезагрузка менеджера (разумеется, это приведёт и к перезагрузке платформы).

При обновлении REIMU с помощью утилиты firmware-updater изменения, сделанные в файловой системе для чтения и записи, будут сохранены (если это не нужно, то нужно перед ссылкой на файл прошивки указать параметр --fullclear). При полной перепрошивке образа с помощью программатора это невозможно, если нет возможности задать перезаписываемый объём ПЗУ (в противном случае нужно перезаписывать только первые 28 МБ или 48 МБ в зависимости от размера флеш-памяти).

Пример команды, выполняющей сброс настроек в процессе перепрошивки:

firmware-updater --fullclear file:///tmp/fimware.mtd.tar

При выкачивании прошивки по сети необходимо следить за тем, чтобы менеджер имел необходимый объём свободного ОЗУ размером чуть больше файла прошивки, поскольку прошивка скачивается во временный файл на RAM-диске менеджера. В процессе прошивки этот файл удаляется. При этом исходный файл при работе по протоколу file:// не удаляется (такой файл не считается временным: раз пользователь сам скачал файл в файловую систему менеджера, то удалять его должен также он сам).

Если файл прошивки больше по размеру, чем перепрошиваемая ПЗУ (а в случае, если не указана опция --fullclear и прошивается ПЗУ менеджера, то за вычетом раздела с настройками пользователя, который имеет размер 4 МБ на ПЗУ объёмом 32 МБ, и 16 МБ на ПЗУ объёмом 64 МБ), то В ПЗУ будет записана только соответствующая часть файла прошивки с его начала. Если же файл прошивки меньше, то он будет прошит полностью с начала ПЗУ; при этом непрошитые области модифицированы не будут.

Желательно, чтобы файл имел размер, кратный размеру блока ПЗУ (512 байт); если его размер отличается, то файл (при работе по протоколу, отличному от file://, после скачивания; в противном случае прямо на месте) будет автоматически увеличен, чтобы соответствовать данному требованию.

При использовании протоколов HTTP, HTTPS и FTP утилита реагирует на переменную окружения WGET_PARAMS, с помощью которой ей можно подавать какие-либо параметры для вызова wget, например, --no-check-certificate:

WGET_PARAMS=--no-check-certificate \
firmware-updater https://untrusted.example.org/files/firmware.mtd.tar

На 64-мегабайтных флаворах прошивка обновляется с помощью OpenBMC Software Update Manager, таким образом, запуск firmware-updater возможен прямо из SSH-сессии, и ему следует передавать файл прошивки в формате .mtd.tar.

После запуска переданный файл будет скопирован в каталог Update Manager-а, и далее будет произведена перезагрузка, в течение которой (примерно 7 минут) прошивка будет автоматически обновлена. SSH-сессия будет оборвана при начале процесса прошивки, и доступ к BMC вновь появится только по её окончании. При наличии желания и возможности за ходом процесса прошивки можно наблюдать через консоль BMC на COM-порту (UART2 для флавора REIMU-4264, UART5 для всех остальных).

На 32-мегабайтных прошивках по причине отсутствия компонентов Phosphor применяется устаревший метод обновления прошивки через прямое обращение к MTD-устройству. В этом случае запуск firmware-updater возможен только из сессии на COM-порту, и ему следует передавать файл прошивки в формате .mtd.

Перед прошивкой менеджера необходимо подключиться к его последовательной консоли и перейти в однопользовательский режим командой init 1. Перед этим рекомендуется выключить настройку сети по DHCP и вручную задать настройки IP-адресов, DNS-серверов и т. п., поскольку DHCP-клиент в однопользовательском режиме останавливается.

При возникновении ошибок файловой системы после перепрошивки без сброса настроек (такое возможно при конфликте inode number-ов слоёв OverlayFS и подобных проблемах) рекомендуется перед прошивкой сохранить важные файлы настроек с менеджера, перепрошить его с опцией --fullclear, а затем заново скопировать на него эти файлы.

При данном методе иногда прошивка не доходит до фазы проверки контрольных сумм и менеджер может уйти в перезагрузку с ошибками; в небольшом числе случаев после перепрошивки он вообще оказывается неработоспособным. В таком случае остаётся только прошить .mtd-файл с помощью программатора. Из-за данной специфики использование 32-мегабайтных флаворов REIMU не рекомендуется.

В будущем планируется реализация возможности гарантированного обновления (Reliable Upgrade), которое позволит в случае неудачного обновления прошивки запустить резервную копию прошивки и попытаться повторить обновление заново или откатиться на предыдущую версию.

Обновление программы начального старта платформы

Обновление программы начального старта (ПНС) платформы возможно с помощью программы-обёртки update-host-flash для утилиты firmware-updater.

Порядок её использования аналогичен программе firmware-updater за исключением того, что перезагрузка менеджера после прошивки не производится (поскольку прошивается не менеджер), и в однопользовательский режим на 32-мегабайтных флаворах переходить не требуется, следовательно, прошивка ПНС всегда может быть осуществлена из SSH-сессии. Как и в случае с прошивкой менеджера, можно использовать файл прошивки, меньший по размеру, чем сама ПЗУ.

Следует помнить, что на время прошивки ПНС SPI-шина с ПЗУ ПНС будет отключена от платформы (т. е. не рекомендуется производить прошивку ПНС, если платформа работает – это может привести к неопределённому её поведению).

Перечень сокращений

ИС – интегральная схема

МН – машинный носитель

МУС-А – модуль управления системой на базе ИС Aspeed

ОЗУ – оперативное запоминающее устройство

ОС – операционная система

ПЗУ – постоянное запоминающее устройство

ПЛИС – программируемая логическая интегральная схема

ПНС – программа начального старта

ПО – программное обеспечение

AHB – Advanced High-Performance Bus

BCLK – Bus Clock

BMC – Baseboard Management Controller

CPLD – Complex Programmable Logic Device

CPU – Central Processing Unit

DAC – Digital-Analog Converter

DHCP – Dynamic Host Configuration Protocol

DPLL – DAC PLL

DNS – Domain Name System

EEPROM – Electrically Erasable Programmable ROM

FRU ID – Field Replaceable Unit Identifier

FS – File System

FTP – File Transfer Protocol

GNU – GNU is Not Unix

GPIO – General Purpose Input/Output

HCLK – High Speed Clock

HTTP – Hypertext Transfer Protocol

HTTPS – Hypertext Transfer Protocol, Secure

I²C – Inter-Integrated Circuit

IOCTL – Input/Output Control

IP – Internet Protocol

LAN – Local Area Network

LDAP – Lightweight Directory Access Protocol

MAC – Media Access Control

NFS – Network File System

NOR – No-Or

PCLK – Peripheral Clock

PLL – Phase Locked Loop

PWM – Pulse-Width Modulation

RAM – Random Access Memory

REIMU – Remote Intelligent Management Unit

ROM – Read-Only Memory

SCP – Secure Copy

SPI – Serial Peripheral Interface

SSH – Secure Shell

SSI EEB – Server System Infrastructure Enterprise Electronics Bay

TinySPI – Tiny Serial Peripheral Interface

UART – Universal Asynchronous Receiver-Transmitter

UID – Unit Identification

USB – Universal Serial Bus

UTF-8 – Unicode Transformation Format, 8-bit

VNC – Virtual Network Computing