Перейти до вмісту

"Мій нікому нецікавий блоґ" або записки за UEFI.

GPT UEFI FAT

Повідомлень в темі: 24

#21 серпиня

    Генеральний писар

  • Користувачі
  • PipPipPipPipPipPipPipPipPip
  • 935 повідомлень
  • Стать:Жінка
  • Місто:Пуп Землі

Відправлено 23.10.2016 – 15:26

Перегляд дописуtaraBooka (18.10.2016 – 13:23) писав:

Касю, ти мене вразила :) - ти це все прочитала!!
_Ех дбайливо найголовніше виділив жирним, мабуть щоб легше було вловити суть)
  • 0

#22 серпиня

    Генеральний писар

  • Користувачі
  • PipPipPipPipPipPipPipPipPip
  • 935 повідомлень
  • Стать:Жінка
  • Місто:Пуп Землі

Відправлено 23.10.2016 – 16:00

Тобто можна було й не читати усе, а лише найголовніше)
  • 0

#23 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1312 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 25.10.2016 – 23:55

Коротка нотатка про вирівнювання різних сутностей в контексті XIP сценарію. На дисках і пам'яті. На дисках - це коли ідеться про вирівнюваність відносно початку тому, який в свою чергу лежить з початку якогось сектору - є вирівняним в LBA просторі сховища тобто. В пам'яті - це коли йдеться, шо сутність може бути вивантажена в пам'ять, і її адреса має бути вирівняна.
Раніше ми думали, шо якшо нема якихсь додаткових вимог на вирівнювання, виконувані модулі на армі, в цьому дефіцитному на місце середовищі, мають бути вирівняними всього на слово (армівське) - 4 байти. Чого? Шоб не попсути вирівнювання інструкцій, які мають лежати по вирівняних на слово адресах (в пам'яті). Але, з подальшою роботою стало ясно, шо зустрічаються блоки, які вимагають крупнішого вирівнювання. Це наприклад таблиця векторів обробки винятків. Вона має бути вирівняна на 32, бо регістр VBAR (Vector Base Address Register), хоче шоб п'ять його нижніх бітів були нулями - вирівняність на 32 хоче. Тож ми посилюємо вимогу на вирівнювання виконуваних файлів в XIP ФТ до 32. Бо хто зна, де ще ця таблиця може бути - обробка переривань може вдосконалюватися з новими фазами і PEIM'ами, тож багато модулів можуть постачати свої таблиці векторів. Покишо це лише SEC модуль і PCR.SYS PEIM.
Стосовно вирівнювання на рівні сутностей ФТ (фірмварний том), тобто - файла разом з його файловим заголовком і секційними заголовками, то тут, було б вигідно вирівнювати на розмір сектора (на диску), для полегшення і оптимізації дискових операцій, але, нажаль, архітектура ФТ диктує таку будову, шо файловий заголовок наступного файла має лежати на першому вирівняному на 8 вгору місці за попереднім файлом. Пам'ятаєте я писав, шо це така собі розподілена таблиця директорії, ці файлові заголовки? Їхня позиція отак знаходиться, вона ніде не прописана. Сумістити це з вирівнюванням на 512 можна лише за допомогою вставляння PAD файлів. І це на додачу до марнування місця, ще й марнування часу процесора. Саме вирівнювання на 512 - це неабияке марнування місця в дефіцитних умовах старту ФВ. Тож виходить, шо жертва певного ускладнення дискових операцій - це найменша жертва. Тобто на рівні ФТ, файлові заголовки мають архітектурно обумовлене вирівнювання (8 байтів), секційні заголовки також (4 байти), а файлові сутности - мають вирівнювання на 1 байт, тобто кладуться довільно - найефективніше по місцю. І лише в XIP сценарії, як вже було сказано, для виконуваних файлів, ітиме немарнотне вирівнювання на 32 байти для файлових сутностей. Для не XIP сценаріїв, виконувані образи діставатимуть потрібне їм вирівнювання підчас завантаження в пам'ять - секції матимуть вирівнювання на секційне вирівнювання - яке зазвичай є на архітектурну сторінку - переважно 4096 байтів, шо ґарантуватиме задоволення всіх внутрішніх вимог вирівнювання (які звичайно менші за 4096).
На прикладі.
APRIORI файл в BFV, який задає порядок виконання PEIM'ів для Pei диспетчера - це маленький невиконуваний файл, який перелічує GUID'и PEIM'ів (чи PPI Зображення). Отже він лежить в XIP томі, але не є виконуваним файлом. Його розмір для мурана навряд переважить 128 байтів, тож його вміст буде покладено довільно прямо за його, вирівняним на 8, файловим заголовком, і, вирівняним на 4, секційним заголовком. Тож як бонус, його вміст теж опиниться вирівняним на 4 до речі.
PEI.EXE файл в BFV. Pei фундація. Виконуваний файл в XIP томі. Підчас будування цього тому, утиліта має знайти найкраще місце для цього файла і, зробити відповідну базову релокацію - підправити кожну адресу в коді так, шоб це справді були адреси за якими сутності, на які йде посилання, лежатимуть в пам'яті. Знову, ми визначили, шо мінімальна вимога покишо є 32, тож ImageBase має бути вирівняним на 32, і оскільки це XIP - execute in place, позиція внутрі тому - теж має бути вирівняна на 32. За умови шо початок тому теж вирівняний в пам'яті принаймні на 32. Він вирівняний на 1024 там. Згадайте карти, які ми малювали, на мурані, база BFV тому є 0x402f0c00 - вирівняність на 1024 на лиці. Ця вимога означає, шо утиліта має розмістити файловий заголовок, секційний заголовок, потім зсунутися вгору на найближчу вирівняну на 32 позицію, і саме туди писати в том цей PE файл. Погодьтесь 31 байт максимуму зсування - це не 511 як у випадку вирівнювання на 512. Насправді ще менше, бо там уже іде ґарантовано вирівнюваність на 4, але тут це не суттєво.
І наостанок виконуваний файл в не XIP томі, хай буде якийсь FV.SYS в CFV - модуль драйвера ФТ Dxe фази, той який один уміє писати ці фірмварні томи і на який лягає уся складність робіння цього. Навіть для більшого CFV ми не можемо марнувати місце з 512 вирівнюванням, тож в томі (на диску) він лежить за тим же приницпом 8, 4, 1 - відповідно вирівнювання для заголовку файлу, секції і самих файлових даних (PE32 образ тут). Коли ж він завантажуватиметься в пам'ять як образ, він сам і його секції кластимуться вирівняними на сторінку, 4096 байтів. Тобто завантажувальник образу, розсовуватиме вміст файла як треба. PE заголовок в сторінку, далі секція коду в нову сторінку, дані починаючи з якоїсь іншої сторінки. Все як у людей, як роблять ОСі коли вантажать свої модулі і компоненти користувацьких програм.
  • 0

#24 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1312 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 22.11.2016 – 15:21

Вперше в історії людства, з'явився ОПК з NOR флешом на борту, ну, - SPI флешом, якшо бути конкретнішим, але всеодно - це так, як у всієї решти світу для збергіання ФВ, а не як у ОПК - через жопу eMMC чи SD. Називається оранж пі пі сі ту. Стоє 20 доларів! Такий гладкий клон распбері пі за дуже помірну ціну. Китай як не як. Думав купити. І передумав покишо. :D Обійдуся без SPI флешу поки.
Дивимся корцінку з офіційного сайту. Бачимо чип ін квесчин. Круто. Ну це на майбутнє. Я про завєтний нор флеш. Є шо робити і без нього.
Прихований текст

  • 0

#25 Фабрегас

    Т Фабрегас 2013

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 5092 повідомлень
  • Стать:Чоловік
  • Місто:найкраще на планеті

Відправлено 22.11.2016 – 17:51

оце тебе тримає
  • 0



Кількість користувачів, що читають цю тему: 1

0 користувачів, 1 гостей, 0 анонімних