LinuxBIOS – фундамент для Linux?

АНТОН БОРИСОВ

LinuxBIOS – фундамент для Linux?

Будучи спроектированной для работы в многоузловых кластерных системах, технология LinuxBIOS за 5 лет оказалась настолько универсальной, что может быть сегодня использована не только в серверах, но и в рабочих станциях. Так что же это – еще одна Basic Input/Output System или что-то большее?

LinuxBIOS является альтернативой обычным BIOS [1], выполняет те же самые функции, что и выпускаемые фирмами AMI (American Megatrends), Phoenix (Phoenix Technologies), IBM, DELL и некоторыми другими, только на порядок быстрее, т.е. в 10-20 раз. LinuxBIOS производит инициализацию оборудования, проверку на исправность модулей памяти и собственно начинает загрузку операционной системы уже после 3 секунд (!) после включения питания. Многие коммерческие изделия затрачивают на эту же процедуру от 30 до 60 секунд. В дополнение ко всему, LinuxBIOS может быть сконфигурирован уже из-под самого Linux во время работы.

Структура LinuxBIOS

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

Шина – это набор одного или нескольких проводников, которые соединяют между собой два или более чипа. Некоторые шины используют два провода – сигнальный и «землю», другие используют десятки или сотни проводников.

Сильно упрощенная схема PC-архитектуры представлена на рис. 1. Разные типы шин не могут быть напрямую соединены между собой, поэтому используют промежуточные чипы, известные как мосты. Первая шина – это FSB (Front Side Bus) – системная шина, на большинстве персоналок она соединяет процессоры между собой и между северным мостом. Серверный мост в свою очередь соединяет процессор с шиной памяти и PCI-шиной. На диаграмме показан только один северный мост, хотя их может быть и несколько. На платформах с процессорами AMD Opteron, например, используется свой северный мост к каждому процессору, и системная шина соединяет только конкретный процессор к своему северному мосту. Другими словами, не существует общей системной шины для Opteron.

Южный мост, который почти всегда расположен на 0-й PCI-шине, является следующим мостом в схеме. Задача южного моста – соединять PCI-шину с устройствами с набором более медленных устройств и отвечать за функции записи/чтения BIOS Flash (рис. 1).

Рисунок 1. Упрощенная схема классической PC-архитектуры. Мосты – это логика, которая соединяет одну шину с другой

Когда ПЭВМ включается или же идет на перезагрузку, процессор передает управление на адрес, который традиционно располагается на самой вершине памяти (TOM – Top Of Memory) за вычетом 16 байт. То есть на архитектурах 8086 это был адрес 0xffff0, на платформах с современными процессорами этот адрес – 0xfffffff0. На первоначальном этапе единственным языком, который понимает машина – это машинный код (Ассемблер). Машина активируется в несколько этапов. В результате, LinuxBIOS переходит из одной фазы в другую последовательно, по мере инициализации определенных ресурсов.

Фазы запуска LinuxBIOS (рис. 2):

• Обрабатываются инструкции, которые инициализируют процессор, лишнюю виртуальную память в минимальной конфигурации (32-битную адресацию), а также другие ресурсы, необходимые для включения памяти (например, I2C-шину). Затем производится сброс кеша процессора.
• Происходит старт кода, отвечающий за дальнейшую настройку процессора и установку параметров памяти.
• Загружается объектный «C»-код из Flash-памяти в оперативную память. Объектный код может быть сжатом виде (заархивирован).
• Выполняется код, который функционирует только при настроенной памяти. Происходит сканирование и инициализация всех аппаратных ресурсов.
• Дополнительная фаза, в ходе которой происходят финальная настройка и затем старт операционной системы.

Рисунок 2. Фазы запуска LinuxBIOS

LinuxBIOS содержит опциональную возможность старта при наличии проблем с обычным BIOS. Такая поддержка добавляется при компиляции проекта. Дополнительный код проверяет сохранность CMOS-памяти и определяет, был ли удачным старт ПЭВМ в предыдущей попытке. Если нет, то используется альтернативная загрузка. В таком случае используется LinuxBIOS-образ, который позволяет загрузиться с другого, гарантированного источника, например, по сети.

Корни и эволюция LinuxBIOS

Проект LinuxBIOS был начат в Национальной Лаборатории Лос Аламос (Los Alamos National Lab – LANL) в сентябре 1999 года под руководством Рона Минниха (Ron Minnich). В предыдущие восемь лет он занимался построением кластеров всех видов, в частности в 1994 году он подготовил свой первый кластер на базе PC. Всё это время BIOS был краеугольным камнем в создании больших кластеров.

Так получилось, что некоторые технологические разработки 1999 года послужили толчком для начала проекта. В какой-то степени это и появление 1 Мб модулей FLASH-памяти на системных платах и широкое использование PCI-шины, которая заменила устаревшую ISA-шину. Также показательно, что Linux начал работать на таких машинах, как SGI Visual Workstation, на которых использовался свой вариант BIOS.

Что казалось ясным на том этапе, так это то, что если бы удалось скрестить Linux с кодом в BIOS, то цели были бы достигнуты. Linux настраивает аппаратные средства намного лучше, нежели варианты BIOS того дня. Требовалось написать простейший загрузчик BIOS, который бы в свою очередь пускал ядро Linux. Дальнейшая инициализация была бы прерогативой Linux. Таким образом, возникло выражение – «Пусть этим займется Linux!»

Прежде чем начался полномасштабный LinuxBIOS проект, в декабре 1999 года была продемонстрирована работа под названием «LOBOS», в ходе которой ядро Linux грузилось из Flash-памяти и дальше передавало управление опять Linux-ядру, но находящемуся на жестком диске.

Проще и быстрее

Самый простой способ достичь результата в Open Source-среде – это найти решения, которые уже работают. Поэтому следующим логическим шагом в развитии проекта стал поиск программного обеспечения схожей тематики. Джеймс Хендрикс (James Hendricks) вместе с Дейлом Вебстером (Dale Webster) нашли нечто похожее в проекте OpenBIOS. После ознакомления с проектом за пять дней удалось создать тестовый вариант на платформе Intel L440GX+. Она загружалась, правда, не с холодной загрузки (когда система первоначально выключена и затем включается), а с горячего старта. Чтобы добавить эту функциональность (возможность холодного старта) пришлось затратить пять месяцев.

Выяснилось, что ассемблерный код не сможет стать языком LinuxBIOS-проекта. Проект OpenBIOS почти полностью состоял из ассемблерных вставок, и было проблематично добавить что-то новое, свое. Неудивительно, что следующим шагом было удачное открытие Джефом Гарзиком (Jeff Garzik) следующего факта – автор проекта STPC BIOS предоставляет в общественный доступ свой труд. Так, STPC BIOS становится фундаментом новой структуры LinuxBIOS. Дальнейшая работа над кодом потребовала постоянной реорганизации, чтобы проект смог поддерживать многие системные платы и логику, таким образом был заложен хороший фундамент для дальнейшего развития.

Следующие шесть месяцев были посвящены запуску LinuxBIOS на новых платформах. Первой платформой без использования графических средств настройки (как в классических программах BIOS Setup) стала системная плата Intel L440GX+, за которой последовала SiS 630. Именно с этого момента, т.е. с приходом фирмы SiS в проект, началась новая эра. Компания предоставляла схемотехнику, техническую поддержку, ассемблерный код, т.е. действительно серьезно подошла к тому, чтобы запустить LinuxBIOS на своем продукте.

Вскоре выяснилось, что Linux может делать, а чего нет. Выяснилось, что ядро 2.2, с которым тогда работали в проекте, не способно с нуля произвести инициализацию PCI-шины. Этим пришлось заниматься LinuxBIOS. Пришлось вытащить код из Linux и с небольшими изменениями использовать непосредственно в LinuxBIOS, добавляя по мере необходимости расширения. Также вскоре выяснилось, что загрузка происходит настолько быстро, что IDE-диски не успевают стартовать. Но вскоре и эта проблема была успешно решена.

По истечении следующих девяти месяцев LinuxBIOS успешно работал на двух платформах, будучи написанным почти полностью на C. Корпорации стали проявлять интерес к разрабатываемому продукту. Так, VIA и Acer предоставили спецификации на свои новые продукты, таким образом также была включена поддержка для их плат. Джеймс Хендрикс начал работу над SMP-поддержкой тем же летом. Патчи стали включаться в разработку Linux-ядра, а не как расширения в LinuxBIOS. С этой стороны Linux-ядро стало походить на унипроцессорное – добавление поддержки новых процессоров стало занимать меньше времени.

Летом того же года к проекту присоединился Linux NetworX, и Эрик Бьедерман (Eric Biederman) стал ключевой фигурой при добавлении поддержки Alpha-архитектуры. Он также произвел реорганизацию стартового кода управления памятью. Сотрудничество с Linux NetworX продолжается и по сей день – фирма является самым крупным продавцом систем на основе LinuxBIOS. Также немаловажной заслугой Эрика является создание архитектуры LinuxBIOS следующей, второй версии.

В конце года участники проекта выступали на Atlanta Linux Showcase 2000 и там познакомились со Стивом Джеймсом (Steve James) из Linux Labs. Это партнерство позволило менее чем за месяц построить 13-узловой кластер на базе LinuxBIOS для Supercomputing 2000.

К следующему, 2001 году Linux NetworX завершила портирование под Alpha-платформу для машин DS10. Был построен кластер из 104 машин класса DS10, все под управлением LinuxBIOS. Машины грузились значительно медленнее, нежели системы на Pentium, поэтому для выхода в рабочий режим требовалось примерно 50 секунд, но все-таки скорость была достаточно высокой. По сравнению с тем немодифицированные машины за то же время успевали выполнить лишь тест памяти.

Портирование под Alpha-машины продемонстрировало, что проект можно перенести и на другие платформы. Для того чтобы LinuxBIOS заработал на 64-битных системах, пришлось немного переработать программный код – раньше он ориентировался в основном на 32-битные системы.

С 2001 года пришли новые разработчики (всего их сейчас 11 человек) и продолжился перенос на другие платформы. Одна из них – это AMD Opteron. Оказалось, что все-таки некоторые процедуры лучше выполнять именно в LinuxBIOS, нежели в Linux, например, SMP-инициализацию. На примере SMP-инициализации для платформы AMD K7 SMP стало ясно, что некоторые процедуры лучше выполнять именно в LinuxBIOS, нежели в Linux.

Ожидалось, что производители поддержат начинание. Но прошло четыре года развития, и вот только в начале пятого начинает проявляться заинтересованность крупных фирм в данном проекте. Так, в 2003 г. было продано продуктов, основанных на LinuxBIOS, на сумму 30 миллионов долларов. По сравнению с 2000 г., когда продаж таких продуктов не было. Неплохое начало, не правда ли?

Аппаратные платформы

LinuxBIOS работает на многих платформах. Официально поддерживаются более 50 системных плат. Многие платы похожи друг на друга и компании используют код от одной системной платы, запускают на другой. Поэтому шансы, что LinuxBIOS заработает на «неподдерживаемой» модели, достаточно высоки. Это возможно в том случае, когда системные платы собраны на одной аппаратной основе, т.е. северный и южный мосты, а также схема инициализации совпадают как для заявленной системной платы, так и для «неподдерживаемой».

LinuxBIOS работает на 64- и 32-битных процессорах. Среди них: Alpha, K8, K7, PowerPC, P4, PIII, PII, Cyrix (VIA), Geode (сейчас AMD) и SC520 (AMD). Список системной логики слишком обширный, чтобы упоминать. Форм-факторы: от малых систем (PC/104), до самых больших K8. Портирование под IBM PPC 970 сейчас находится в развитии.

Секреты успеха развития LinuxBIOS

Исторически сложилось, что производители аппаратного обеспечения очень рьяно хранили в секрете спецификации выпускаемых процессоров, чипсетов, системных плат. Как получилось, что разработчики свободного проекта получили столь секретные сведения? Очень просто – если компании не видят выгоды, то они и не выпустят эту информацию. С другой стороны, как только появляется интерес, то развитие происходит с удивительной скоростью.

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

Успех в LANL показателен. В требованиях министерства по энергетике США (а именно оно в конечном итоге является заказчиком LinuxBIOS) для постройки 2 последних кластеров значилось – «необходимо построить на основе LinuxBIOS». Всего же на данную работу предназначалось освоить около 19 миллионов долларов. Те компании, которые не захотели участвовать в движении проекта LinuxBIOS, не смогли отреагировать на данный заказ. Те же, которые предвидели нечто подобное, были подготовлены. Предвидение в данном случае сыграло значительную роль.

Выводы

LinuxBIOS прошел длинный путь за четыре года – от стадии «Это возможно» до «Сделано!». LinuxBIOS используется везде – от огромных кластеров до встраиваемых (embedded) систем, в MP3-плейерах, портативных кластерах и т. п.

LinuxBIOS позволяет построить системы без громадного PC-багажа. Их можно оптимизировать под Linux и сделать еще более компактными и простыми. Для таких систем находится применение.

Проект сейчас находится в своей второй стадии, LinuxBIOS V2. За четыре года 6 видов процессоров, более 50 системных плат и огромный багаж опыта. Сейчас для переноса на новую систему требуются дни, по сравнению с месяцами, как было раньше. Влияние проекта на мир вычислений только начинается!

Когда готовилась эта статья, главный идеолог проекта Ron Minnich выпустил статью об использовании Linux-BIOS в разработке учебной мини-ракеты. Подробности смотрите в [3, 4].

На этой оптимистичной волне разрешите с вами распрощаться до следующего выпуска, в котором мы непосредственно займемся настройкой LinuxBIOS для аппаратной системы VIA EPIA-M.

Ссылки:

1. http://en.wikipedia.org/wiki/BIOS.
2. http://www.linuxbios.org.
3. http://www.linuxjournal.com/article/8120.
4. http://www.linuxjournal.com/article/8310.