 |
|
|
|
Sun OpenBoot Prom. Между железом и софтом
Sun OpenBoot Prom Что может скрываться за буквами «ок» на белом экране? OpenBoot Prom (OBP) – одна из айтишных «вкусностей», рожденная в лабораториях Sun Microsystems и широко используемая в настоящее время разными производителями аппаратного обеспечения. Можно сказать, что OBP – это аналог BIOS на платформах, отличных от x86, таких как sparc, powerpc и, возможно, других [1]. Основное предназначение данной программы – firmware[1] – загрузка и запуск других, более сложных программ и передача этим программам управления системой. «Другими» программами могут являться ОС, средства диагностики, отладки и т.п. В процессе работы мне практически не приходилось сталкиваться с оборудованием, отличным от sparc и x86-подобных архитектур. OpenBoot на PC-совместимых компьютерах не встречал, все примеры в статье работают на архитектуре sparc sun4u. В то же время одной из особенностей OBP является кроссплатформенность[2] – на разном аппаратном обеспечении ожидается похожее поведение системы. Чем-то напоминает «написано раз – используешь везде» – лозунг Java. Дело в том, что в компании всегда производились машины нескольких архитектур, отличных от x86. Сейчас это – sun4u (ultrasparc), sun4v (niagara), раньше были и другие. Загружать операционную систему приходилось с целого ряда устройств: дисков различных типов, по сети через разные адаптеры и т.п. Вместо того чтобы писать свой загрузчик для каждого устройства ввода-вывода (см. пример BIOS), инженеры Sun пошли другим путем. Поставщикам оборудования была предоставлена возможность размещать загрузчики на самих устройствах – так называемые plug-in-драйверы устройств. Драйверы должны быть написаны на языке Forth – OBP включает в себя интерпретатор этого языка. Храниться драйверы могут как на самих устройствах, так и на свободном месте в OBP. То есть любой сторонний производитель может выпустить свое абсолютно новое устройство и «подружить» его с остальной системой, не перекраивая firmware. Но OBP – это не только загрузчик ОС. Он может еще использоваться для диагностики и отладки как железа, так и ядра операционной системы. Что является еще одним отличием OBP от BIOS для x86. Средства диагностики еще можно встретить на некоторых материнских платах, но вот с возможностями отладки мне сталкиваться не приходилось. Наличие интерпретатора forth предоставляет возможность для составления сложных программ из простых, доступных изначально команд. Вообще работа с ОВР происходит в оболочке интерпретатора forth, что напоминает привычный shell. Приглашение для ввода команд обычно выглядит так:
Далее по тексту это приглашение используется в примерах команд. Внимание – если приглашение выглядит так:
значит, управление передано не OBP, а сервисному контроллеру. Как работать с сервисным контроллером – отдельная тема [9]. Обычно достаточно помнить, что передать управление к OBP можно командой console. Попасть обратно в sc – сочетанием #., как показано в примере: sc> console
Интерфейс командной строки мне хотелось бы выделить отдельно – это свойство может быть очень полезно в работе для «убийства рутины» – путем программирования часто повторяющихся действий. Например, при отладке. В случае же удаленного управления кучей серверов никакая графика не заменит возможностей expect и интерфейса командной строки OBP. Пользовательский интерфейс основан на командном интерпретаторе, который предоставляет доступ к обширному набору команд для управления аппаратными средствами, программирования, изоляции проблемных мест и отладки. Набор доступных команд зависит от реализации – версий систем, используемых в ОВР. Эта информация доступна по команде: ok .version
Далее набираем в поиске [2], к примеру, «OBP 4» и смотрим доступные документы. Также может быть полезен поиск по названию сервера. Начало работы Начать работать с OBP очень просто – нужно лишь послать сигнал break системе. Как – зависит от настроек консоли. Часть систем управляется через COM-порт, часть – с помощью монитора и клавиатуры и т.п. В OBP можно переназначить console – управляющее устройство – об этом далее. Самое популярное средство управления, конечно же, удаленная консоль. В таком случае процедура отправки сигнала break системе зависит от консольного клиента и от всей цепочки устройств до требуемого. Нередко доступ к консоли можно получить, лишь подключившись через цепочку серверов. Некоторые машины в цепочке также могут реагировать на сигнал break – т.е. прерывать свою работу. Следует быть аккуратным – бывают случаи, когда по невнимательности выключаются транзитные серверы. Внимательно смотрим документацию на свой терминальный клиент (ssh, telnet – нужное подчеркнуть) и жмем соотвествующие клавиши или кнопки мыши. Например, подключившись через стандартный telnet-клиент, можно нажать <Ctrl>+<]>». После чего ввести два слова: «send break» и нажать <Enter>. Кроме удаленного управления рабочие станции Sun на платформе sparc могут управляться с клавиатуры. В таком случае сигнал break системе можно послать, нажав одновременно <Stop>+<a> или <Stop>+<q> – в зависимости от типа клавиатуры: qwerty или azerty. На последних USB-клавиатурах порядок действий может отличаться – я с этим не сталкивался, но в документации так написано. Также в ОВР можно попасть из ОС, например, по команде: # halt Отличие от сигнала break в том, что halt прекращает работу ОС и передает управление в OBP, тогда как break прерывает работу ОС или других программ. Во многих случаях после «прерывания» можно опять запустить ОС в том же месте командой go. После команды halt (из ОС) будет работать только команда boot – загрузка ОС заново. Кроме двух относительно нормальных способов, существует еще парочка. Первый – отключение и включение питания сервера. Если система не сконфигурирована на автоматическую загрузку, после пропадания питания управление будет передано OBP. Еще один нестандартный способ – когда OBP в момент загрузки ОС обнаруживает ошибки, которые разрешить не может. Например, часто встречающаяся ошибка – неправильно назначенно загрузочное устройство. Дерево устройств – адресация Для понимания работы ОВР стоит разобрать понятие Device Tree – дерево устройств. Устройства могут подключаться к системе разными способами – используя различные шины, контроллеры, протоколы. ОВР представляет все устройства в виде иерархической структуры типа «дерево», что очень похоже на файловую систему. У каждого устройства может быть родительское и ряд дочерних устройств – соответственно к чему подключено устройство и что подключено через него. В основном родительскими являются шины, контроллеры и т.п. Полный путь к каждому устройству обозначается как перечень родительских, разделенных прямой косой чертой – совсем как в UNIX-подобных файловых системах. Первая черта обозначает саму машину, «корень» всех устройств. В Solaris тоже можно получить доступ к Device Tree через специальный каталог /devices. Внешний вид дерева устройств будет выглядеть так же, как в OBP. Вывод команды ls в ОС Solaris на Netra210: # uname –sir
# pwd
# ls -1
Начало ввывода show-devs на Netra210: ok show-devs
Имя каждого устройства представлено в следующем виде: device-name@unit-address:device-arguments, где: device-name – имя (название) устройства. В официальной документации сказано «для людей» – human-readable. Я бы подчеркнул, что понятны эти названия будут лишь подготовленным читателям; unit-address – адрес устройства, текстовая строка, обозначающая физический адрес устройства в родительском пуле адресов. Формат написания зависит от шины (родительского устройства); device-arguments – аргументы, зависящие уже от конкретного устройства данные, которые могут быть полезны при дальнейшей работе. Хороший пример адресации устройства:
Эта строчка говорит о том, что шина SBus подключена непосредственно к основной системной шине, адрес 1f,0. 0,40000 – слот в Sbus (в нашем случае – 0), и смещение 40000. Далее можно понять, что подключен SCSI Disk (sd) по адресу 3,0, партиция «а». В документации именование устройств расписано довольно подробно. Псевдонимы Все это выглядит очень интересно, но, мягко говоря, нечитабельно, если, конечно, читатель не имеет отношения к поддержке оборудования или разработке драйверов устройств. Для более простого восприятия ОВР предоставляет систему алиасов – псевдонимов устройств. Так что всем привычное net из команды: ok boot net обычно раскладывается во что-нибудь вроде:
Управлять псевдонимами устройств можно:
Команда devalias по своему синтаксису похожа на alias оболочки bash (или подобных интерпретаторов) и имеет три формы: devalias – показывает список определенных алиасов устройств; devalias ALIAS – показывает полный путь к устройству, доступному по указанному псевдониму; devalias ALIAS ПУТЬ_К_УСТРОЙСТВУ – определяет новый псевдоним для указанного устройства. Поведение команды nvramrc очень напоминает файл .bash_rc или другой подобный, выполняемый при старте системы или пользовательской сессии. Все команды, хранимые в nvramrc, записываются в текстовой форме. Причем может быть использован почти весь набор команд, доступный из командной оболочки. Исключений немного, это команды: banner, boot, nvedit, password, reset, setenv security-mode. Для создания псевдонима устройства, доступного после перезагрузки, можно воспользоваться командой: nvalias ALIAS ПУТЬ_К_УСТРОЙСТВУ Действие команды аналогично devalias, что легко проверить. Набрав nvedit, мы увидим: devalias ALIAS ПУТЬ_К_УСТРОЙСТВУ Как нетрудно догадаться, nvedit – встроенный редактор, с помощью которого можно управлять nvramrc. Синтаксис немного похож на синтаксис Emacs. Подробное описание смотрите в документации, отмечу лишь, что выйти из редактора можно по <Ctrl>+<C>. Нужно помнить, что nvedit работает только с временным буфером. Чтобы изменения вступили в силу, после редактирования нужно выполнить команду nvstore. Проверить работу команд в буфере можно, выполнив nvrun. В nvramrc можно также определять свои программы, как показано в примере: ok nvedit 0: : hello ( -- ) 1: ." Hello, world. " cr 2: ; 3: ^-C ok nvstore ok setenv use-nvramrc? true ok reset .... ok hello
Понятно, что напрограммировать в nvramrc можно многое, но я в своей работе ни разу этот функционал не использовал. Похоже, он бывает больше полезен разработчикам и сервисным инженерам, которым приходится диагностировать проблемы в работе оборудования. От себя добавлю лишь, что отключить использование nvramrc можно командой: ok setenv use-nvramrc? false Теперь мы знаем, что такое адресация и псевдонимы устройств, но не знаем, что с ними делать. Все просто. Работа с устройствами В терминологии ОВР все устройства называются нодами. Конечные устройства (которые не имеют «потомков») называются «листьями» – leaf. Обычно это и есть «настоящие устройства», а не контроллеры, шины и другие связующие звенья. Каждая нода может предоставлять о себе следующую информацию: свойства – структура данных, описывающая устройство; методы – набор команд, доступных при работе с этим устройством; данные – значения, используемые при инициализации и дальнейшей работе с устройством. Существуют стандарты на название и наличие свойств и методов в драйверах устройств. Некоторые свойства и методы должны обязательно поддерживаться драйвером устройства, поддержка других – рекомендована. Что-то производители «железа» добавляют самостоятельно. При работе с ОВР в каждый момент времени у нас есть так называемое текущее устройство – current node. Мы можем выбирать текущее устройство командой dev c параметром, где параметром может быть:
Чтобы интерфейс стал совсем узнаваемым – используются команды ls и pwd, поведение которых такое же, как в любой UNIX-подобной файловой системе. Они показывают, соответственно, «список потомков» и «текущее устройство». Более того, во многих реализациях OBP для команды dev используется алиас cd – наверно, чтобы системные администраторы чувствовали себя «совсем как дома». Вот еще полезные команды для работы с устройствами: ok device-end – показывает список всех «листьев» «дерева»; оk show-devs – показывает список всех устройств «дерева»; ok .properties – показывает различные свойства устройства. Например, производитель, модель и текущие параметры сетевой карты; ok words – показывает имена методов, применимые к указанному устройству; ok see WORDNAME – показывает, что означает слово FORTH. Например, из каких команд состоит указанная программа; ok unselect-dev – делает текущим предыдущее устройство или корень. Подобно cd $OLDPWD в bash. Каждому устройству рекомендуется иметь работающий метод selftest. Он вызывается командой test и используется для диагностики. Как несложно догадаться, метод должен возвращать сообщение об обнаруженных проблемах в устройстве или не выводить ничего в случае корректной работы. Некоторые несознательные драйверы все же выводят сообщение об успешно проведенных тестах. Славятся подобным поведением драйверы сетевых карт. Если метод selftest не описан – система выведет сообщение об ошибке. Команда test-all вызовет test для всех устройств в системе. Кроме команды test, применимой, в принципе, ко всем устройствам, пользователю доступны еще несколько команд диагностики. Они различаются по типам проверяемых устройств и по типу предоставляемой информации. Все команды простые, не вижу смысла заострять внимание на их описании – смотрите документацию к своей версии ОВР. Если в процессе работы вы забыли название или синтаксис команд – всегда на помощь придет help: ok help – выдаст список категорий помощи; ok help КАТЕГОРИЯ – покажет краткое описание всех команд указанной категории. Категория определяется только по первому слову в названии; ok help КОМАНДА – покажет справочную информацию о конкретной команде. К сожалению, help доступен не для всех команд. Официальная причина – команд слишком много, и справка доступна лишь для самых популярных. Похоже на правду, если учесть ограниченный объем NVRAM. Для получения помощи в OBP также можно использовать команду sifting: ok sifting ARG – выведет все команды, которые содержат последовательность ARG. ok sifting boot
Конфигурация системы Кроме набора команд и дерева устройств, каждая система имеет ряд настраиваемых параметров конфигурации. На один из них мы уже обращали внимание – use-nvramrc?. Вопросительный знак в конце имени переменной значит, что значений может быть два: false или true. Значения остальных переменных – текстовые. Пожалуй, исключение составляет oem-logo – логотип, отображаемый командой banner (часто – при загрузке системы). Логотип – это массив пикселей 64х64, поменять его проще всего командой eeprom из ОС. Можно и средствами ОВР, немного попрограммировав на FORTH или вбивая массив пикселей руками. В документации есть пример. В основном вся работа с переменными производится с помощью 5 команд: printenv [VARIABLE] – показывает значение одной переменной, если указана, или весь список имен и значений – в противном случае; setenv [VARIABLE] [VALUE] – присваивает указанной переменной заданное значение. Часто вступления изменений в силу потребуется reset системы; set-default [VARIABLE] – сбрасывает переменную в значение по умолчанию; set-defaults – присваивает всем переменным значения по умолчанию; password – присваивает пароль на управление системой. В Solaris присутствует команда eeprom, которая позволяет менять некоторые переменные OBP. Самые ленивые администраторы переставляют ОС, не подключаясь к консоли – лишь используя eeprom и reboot с аргументами. Уделим немного внимания встроенным средствам безопасности. ОВР может работать в трех режимах безопасности (значения переменной security-mode): full – все команды, кроме go, будут требовать ввода пароля; command – все команды, кроме boot и go, будут требовать ввода пароля. Причем команда boot с аргументами (попытка загрузиться с устройства не по умолчанию) тоже запросит пароль; none – значение по умолчанию – пароль не будет требоваться в любом случае. Не удержусь от напоминания, что следует быть внимательным при назначении режима безопасности и при смене пароля – сбросить его своими силами вряд ли получится – придется вызывать сервис-инженера. Ряд переменных отвечает за параметры ввода-вывода ОВР – их конфигурацию называют еще «управление консолью»:
За что отвечают эти настройки – понятно из названия. Изменять их следует внимательно – можно «потерять консоль», что не светит ничем хорошим. В случае недоступности ввода или вывода после перезагрузки по питанию придется искать консоль на fall-back устройствах. Основная задача системного администратора в ОВР – загрузить систему. За поведение ОВР в момент загрузки отвечают несколько переменных. Во-первых, значение переменной auto-boot? говорит нам о том, будет ли система пытаться загрузиться при включении. Если да, то будет проверяться переменная boot-command, значение по умолчанию которой – boot. Далее проверяется переменная diagnostic-mode?. Если значение равно false, система будет пытаться загрузиться с устройств, перечисленных в переменной boot-device и искать там файл boot-file для запуска. В противном случае процедура загрузки системы усложнится. Сначала будет запущен selftest в порядке, зависящем от переменной diag-level. Далее может последовать вывод дополнительной информации о статусе системы – зависит от реализации. Последнее отличие – для загрузки будут использованы другие переменные: diag-device и diag-file. Нетрудно догадаться, что переменная boot-file – не что иное, как ядро операционной системы. По умолчанию система будет пытаться загрузить Solaris из файла kernel/unix, которому также можно передать параметры. Подробное рассмотрение процесса загрузки и запуска программ в различных режимах выходит за рамки данной статьи наряду с возможностями отладки (debugging) и программирования на FORTH. В повседневной работе системный администратор обычно сталкивается с задачами определения и конфигурации устройств, инсталляции и загрузки ОС. После чего ОВР на настроенной машине используется редко. Работа с ОВР хорошо документирована, информацию найти легко для всех, даже не самых простых, задач.
[1] Firmware - «микрокод» - говорит StarDict, или «ППЗУ» - подсказывают на сайте gentoo [7]. [2] Для ряда платформ драйверы могут работать одинаково, но гарантировать полную идентичность поведения ОВР на этих платформах не могу - не проверял. |
ВЛАДИМИР ВАСИЛЬКИН, инженер, занимается администрированием информационных систем и сервисовКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
