E, підготувати і передати в фазу DXE дані про виявлені пристроях, щоб драйвери DXE змогли їх правильно ініціалізувати.
Код PEI складається з ядра PEI Foundation, яке є спільним для процесорів з однаковою архітектурою і модулів PEIM. Модулі виконують початкову ініціалізацію конкретних пристроїв і розроблені виробниками цих пристроїв.
Архітектура PEI дозволяє незалежну розробку і налагодження модулів.
У PEIM може бути присутнім список залежностей від інших модулів, тому порядок їх запуску не випадковий і вибирається диспетчером PEI.
Фактично відбувається так:
перенесення даних з тимчасової ОП в ранню (тимчасову) ОП, тобто в кеш;
запуск модулів PEIM в порядку залежностей між ними. Це цикл, який закінчується в момент, коли НЕ запущених модулів не залишається;
ініціалізація ЦП;
ініціалізація основний ОП і перенесення до неї даних з тимчасової ОП.
У фазі PEI з постійної пам'яті потрібні будуть як мінімум PEIFoundation і модулі для всього обладнання, що потребує ранньої ініціалізації.
Формат модулів PEI може, як збігатися з форматом драйверів DXE (PE32 +), так і відрізнятися від нього заголовком, тому заголовок PE32 + містить безліч невикористовуваних у фазі PEI полів, а місце в кеші процесора обмежена. Тому для PEIM був розроблений спеціальний формат TE, заголовок якого містить тільки необхідні поля. Також зустрічаються гібридні DXE/PEI-модулі з двома точками входу, але вони зобов'язані бути у форматі PE32 +, оскільки інакше драйвер DXE такий модуль не запуститься.
Остання фаза ініціалізації DXE, під час неї виконується основна і остаточна ініціалізація. Код DXE складається з ядра, воно ж DXE Foundation, диспетчера і драйверів. Ядро ініціалізує і запускає різні служби UEFI: Boot Services, Runtime Services і DXE Services. Диспетчер відповідає за пошук і запуск DXE-драйверів, які також мають залежності. Драйвери проводять остаточну ініціалізацію апаратури та надають апаратну абстракцію для служб. Весь код DXE, крім Runtime-частин Foundation і Runtime DXE драйверів вивантажується з пам'яті по закінченню фази BDS.
Процес запуску DXE можна коротко описати таким чином: завантажується ядро, створює потрібні структури даних, потім запускається диспетчер і завантажує всі доступні драйвери з усіх доступних носіїв, потім запускається завантажувач, який намагається знайти на цих носіях завантажувач ОС і передати йому управління. Якщо завантажувач не здобувся, то виконується код модуля Platform Policy, який написав виробник материнської плати, що повідомляє про НЕ можливості подальшої завантаження.
У постійній пам'яті для цієї фази потрібні DXE-драйвери і все, що їм може знадобитися.
Під час фази DXE настає момент, коли диспетчер завантажує драйвер SMMInit, з якого і починається підфази SMM. Підфази SMM - це спеціальний режим процесора, в який він переходить при отриманні спеціального переривання - SMI, яке може бути як програмним, так і апаратним. Більшу частину (або взагалі все) джерел SMI можна відключити, якщо перехід в SMM не потрібно. Код SMM виконується в пам'яті SMRAM, яка стає недоступною для ОС після закінчення фази DXE, оскільки драйвер SMM навмисно закриває до неї доступ. Код SMM виконується і після закінчення фази DXE, до самого виключення ПК.
Драйвер SMMInit відкриває пам'ять SMRAM, створює карту і структури даних, необхідні для запуску інших драйверів SMM, а перед закінченням фази DXE повністю закриває доступ до SMRAM. Драйвери SMM залежать від обладнання і не мають доступу до інтерпретатора байт-коду, тому написання драйверів SMM на EBC не підтримується. Бувають ці самі драйвери двох видів: чисті SMM, які завантажуються по перериванню безпосередньо в SMRAM, і SMM/DXE-гібриди, які спочатку запускаються диспетчером DXE, а потім вже копіюють частину себе в SMRAM. Драйвер SMMInit - саме такий гібрид. Для цієї підфази з постійної пам'яті потрібні драйвери SMM.
Для розробки додатків для платформи UEFI BIOS важливіше вивчення процесу завантаження є вивчення UEFI Shell, так як ця оболонка дозволяє запускати додатки, отримувати інформацію про систему і необхідна при розробці ПЗ.
1.3 Огляд аналогів і вибір прототипу
Оскільки UEFI BIOS з'явився недавно, має специфічне призначення і обмеження в можливостях, в порівнянні з ОС, то розробкою ПЗ на даній платформі займається невелика кількість розробників. У зв'язку з цим, прямих аналогів файлового менеджера для цієї платформи немає.
Серед можливостей безпосередньо деяких реалізацій UEFI BIOS можливо за допомогою вбудованих утиліт переглянути доступні структури...
