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

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

GPT UEFI FAT

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

#141 _Ex

    STATUS_OK

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

Відправлено 03.12.2017 – 01:08

нарешті приїхала з далекого Китаю моя плата, Banana PI M2 Ultra. :)
Тепер у мене шість цільових машин з яких 5 - ОПК (SBC) і 1 відроїдний сет топ бокс. останній нелегко включити в розробницький цикл навіть теоретично (не напаяно UART, не напаяно документації, навіть вихідні коди такого гмд як убут ще напаяно). це на потім. там 64 бітний армівський вісьмиядерник.
Тож зараз маємо:
  • 32 бітний ARM
    • Beagle Bone Black - TI Sitara AM3358 - 1x Cortex-A8, муран
    • Cubieboard 2 - Allwinner A20 - 2x Cortex-A7, аргон
    • Banana PI M2 Ultra - Allwinner R40 - 4x Cortex-A7, неон
  • 64 бітний ARM
    • Pine64+ 2GB - Allwinner A64 - 4x Cortex-A53, сосна
    • CSA90 - Rockchip RK3368 - 8x Cortex-A53, чортик
  • 32 бітний MIPS
    • Mips Creator CI20 - Ingenic JZ4780 - 2x XBurst (mips32r2), йод
Найслабшою за швидкостями і накачаністю платою є муран, найсильнішою є неон, за яким з невеликим відривом іде сосна і чортик. йод і аргон - посередині. всі машини за винятком мурана є багатопроцесорними, а чортик на додачу скаладється з двох чотириядерних кластерів. це для можливості втілювати багатопроцесорну ОС (SMP).
Після того як ми ось розворушимось з менеджментом памяти на йоді, підключатимемо 32-бітні армівські цілі. особливо заманливими виглядають обидві Allwinner'івські цілі, вони мають SATA контроллер, який начебто дотримується AHCI специфікації, було б так цікаво спробувати програмувати те чудо. Я, по сікрєту, від доброї людини, отримав кід ініціалізації SDRAM для сосни, це нам має помогти - Allwinner'івських машин у нас аж 3.
Коротко, нам треба імплементувати UEFI Boot Services, в Dxe, і сервіси керування памяттю - в першу чергу. а далі - т. зв. архітектуні протоколи, останні - якшо ми дотримуватимемось суворо Dxe, в уефі цього нема, ми можемо організувати внутрішню роботу по-своєму. наприклад як я вже казав, планується обробка переривань, це вносить цілком конкретні вимоги до системи. зрештою, в опшіх чіртах, наша система експонуватиме наружу уефі речі як і положено уефі ФВ, а внутрі ми тренуватимемось писати ОС. Тож після керування памяттю, нам треба подумати над 1) обєктним менеджером, і 2) менеджером В/В, це для драйверів! От тоді коли ці речі робитимуть, можна починати прикурчувати керування периферійними пристроями. Принаймні найважливішою їхньою підмножиною. контроллер переривань, таймери, сховище, дисплей, уарт, усб, мережа. сховище на ОПК - це переважно SD/MMC/NAND. рідкісні випадки - така звичайна для ПК SATA. Це високошвидкісний інтерфейс, так широковживаний, не дивно, чого ми накупували аж 2 плати з ним. Мається на увазі ... в той час коли вони так рідко зустрічаються на ОПК, у нас їх аж в 33% плат.)
Звичайно, це величезна робота, але ми просто побалакали за плани, навіяно надходженням нової плати в парк, (того він і неон, шо "новий").
Конкретніше, і приземленіше, ми працюємо над AllocatePages(), FreePages(), AllocatePool(), FreePool() та GetMemoryMap() уефі БС (бут сервіси), і підлеглими алгоритмами, структурами, ініціалізацією і розкроєм. Алогритми ми учимо по книзі Кнута. First Fit алгоритм з "in place" розміщенням інфи за вільні блоки, з тегуванням на краях, які звязані в двонаправлені списки. для алокацій в цьому середовищі - саме те, шо треба.

Повідомлення відредагував _Ex: 03.12.2017 – 01:22

  • 0

#142 antip

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

  • Користувачі
  • PipPipPipPipPipPipPipPipPip
  • 537 повідомлень
  • Стать:Чоловік

Відправлено 03.12.2017 – 12:53

Пищь.
  • 0

#143 _Ex

    STATUS_OK

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

Відправлено 08.12.2017 – 00:39

Ото так прикол, два місяці тому качав компілятори для CI20 з офіційного сайту, все було ок, ну як - закинуте все, але як і було з власне 15-го року. А це приходю, а Creator CI20 просто зник з сайта Imagination, шо там - увесь MIPS зник, з конпіляторами. Я знав, шо саме Imagination купує хтось, і шось чув за їхній міпсівський підрозділ, але не звернув особливої уваги. А виявляється, в рамках оцього викупу, якимись китайцями, вони відкрутили MIPS підрозділ і продали його якомусь Tallwood там шось. Почитав в bloomberg шось там за трампа, шось він там знову заборонив продавати китайцям ... а при чому тут трамп, якшо Imagination англійська компанія? вопшім тепер MIPS знову MIPS і вернувся в сонячну Калифорнію. Не знаю, як це вплине на саму архітектуру, її розвиток, на сайті хрєн шо найдеш, ну ясно, дуже рано, не встигли ще нічого обставити. І міпс криейтор, ця маленька пурпурова плата, шо з нею буде? будуть ще продавати? чи може навіть випустять наступника? нічого не ясно. але принаймні Imagination давно забив на нього, це було ясно. А мені шо робити? :lol: Я ж uefi під неї пишу, шоб люди користувалися, не просто так. без розвитку (з подальшим розкручуванням, продаванням самої плати і випуском її наступних версій), у CI20 є всі шанси остаточно впасти в забуття. разом з моїм уефі під нього. я то ще маю тєлєгу армівських цілей, їм точно нічого не загрожує, але все ж, міпс такий прикольний, хотілось би і далі його підтримувати. міпсівські маршрутизатори то фігня, ця плата є труЬ міні ПК, з HDMI і SD-картками, а то таке, один етернет (нє, етернет це рулєз, я люблю етернет, я мав на увазі інше - маршрутизатори занадто обмежені (в памяті, процесорі)) і не дуже девелопер френдли, як і будь який консумерський пристрій). та й ядра там древні, навіть древніші за йодове. ех.

Повідомлення відредагував _Ex: 08.12.2017 – 00:49

  • 0

#144 _Ex

    STATUS_OK

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

Відправлено 16.12.2017 – 01:27

Про керування памяттю (КП).
Якби нам лише треба було виділяти та звільняти блоки памяти, все б було б значно простіше. Але UEFI вимагає дуже дурні речі в цій частині. А саме - вона типізувала память, ввела з десяток тих типів - EfiBootServicesData, EfiBootServicesCode, EfiRuntimeservicesData, EfiRuntimeservicesCode, EfiLoaderData, EfiLoaderCode, EfiUnusableMemory, EfiReservedMemory, EfiConventionalMemory і ще купку. Я не стану тут описувати наскільки оце все беззмістовне і непотрібне, це довго, вам залишається мені повірити або піти і повчити UEFI специфікацію, подумати над тим, як воно робе і, - переконатися самим. Шо тут це зайва непотрібна фігня. Але ще гірше, - UEFI дозволила використати значення від 80000000h аж до FFFFFFFFh включно для кустарних типів, які "можуть використовуватися лодарями"... Шо робить кількість типів майже безмежною. який жах. Гаразд, грець з ним, ми імплементуємо специфікацію і хочемо бути сумісними з нею, для своїх очевидних цілей, тож доведеться включати і це в розгляд, навіть якшо це himno повне. А воно саме таке, того шо ускладнює КП, робе його повільнішим, схильнішим до помилок і відмов. А головне - не служе нічому доброму. нідлячого. От намагаючись впоратися з цим, ми й хочемо підсумувати, шо нам потрібно, шоб не лише просто зробити КП, а ще й так як це хоче UEFI.

Наше Dxe отримує керування і починає ініціалізуватися. Перш за все ініціалізуються сервіси памяти. У нас в памяті на початку лежить CFV, за ним HOB список, на краю виділено стек. А в середині - ділянка, якою треба правильно керувати - саме там лежатимуть дані ФВ і сторонніх драйверів/застосунків/лодарів. Саме туди навіть вантажитиметься ОС.
UEFI хоче дворівневу алокацію памяти - на рівні сторінок (AllocatePages(), FreePages(), сторінки на UEFI завсіди 4 КБ), і на рівні пулу (Pool, ставок коротше :D AllocatePool(), FreePool()). Перші алокації мають бути посторінкові і мають, відповідно, бути вирівняними на сторінку, другі на 8 байтів, і, значить, є 8-мультиплами.

Якби була потрібна нормальна алокація, ми б робили так:
Виділяли б якийсь шмат сторінок для пулу (а потім, якшо б його не вистачало, намагались би додати ще). Тут би працювали пулові функції. На решті ж, - сторінкові. Алгоритми виділення/звільнення, були б однаковими з певними нюансами.
Ось їхній базис:
В обох випадках память розбита на блоки. Суть вільні блоки і зайняті. Обліковуються лише вільні - це все, шо потрібно для алокації памяти здорової людини. Ми використовуємо сам блок для зберігання інфи за нього і звязування його з іншими блоками в двонаправлений список. Перевіка на злиття блоків досягається тегуванням блоків по краях. Якшо при звільненні блока (а значить - додаванні його в список вільних блоків), якийсь з суміжних блоків або обидва вільні теж, відбувається злиття блоків в один (саме це запобігає такому шкідливому для КП фрагментуванню памяти). Ця перевірка досягається тегуванням країв блока - ми позначаємо блок або вільною міткою або зайнятою. Згадані вище нюанси розбіжності між сторінковим і пуловим варіантами полягають в тому, шо в сторінковому випадку ми не можемо (без жахливого марнування простору, згадайте за вирівняність на сторінку) позначити зайняті блоки. Того ми замість цього відрізняємо зайнятий блок від вільного по нерівності на вільність. Кнут в книзі робить перевірку на зайнятість. Але якшо пул непошкоджено (нормальний сценарій) різниці між перевірянням на рівність зайнятості чи нерівність вільності немає. А у випадку пошкодження пулу, обидва підходу впадуть, шо й недивно. Також, через побоювання, шо наша мітка може збігтися з користувацькими даними, ми ввели їх дві, кожна в різних місцях (на початку і на кінці блоку) і кожна по 4 байти. Це робить збіг майже неймовірним. В пуловому випадку мітка одна. Але там через значно меншу грануляцію (8 проти 4096), ми легко можемо "обгортати" кожен блок даних метаданими (як у Кнута), і власне мітка - одна з них, вона не пересікається з користувацькими даними. Звичайно, для вільних блоків це не має особливого значення (увесь блок не містить нічого користувацького), але для перевірки злиття блоків - має.
Алгоритм, як я вже казав - First Fit. Майже. Виділяється перший придатний (за розміром) блок. "Майже" того, шо на виділеннях використовується Rover вказівник, який скаче туди сюди, і пошук власне не починається завсіди з того самого місця (з початку зазвичай), а має, до певної міри, випадковий характер. Але в решті - Перший Придатний. Чого не buddy алокація, описана там же, в книзі Кнута? Та того шо вона марнує ~44% місця. Це занадто багато.
Оце все шо нам би було треба.
Але оскільки нам потрібно втілити уефішну алокацію (алокацію курця), нам доведеться робити так:
Нам треба вести облік і виділених блоків теж. А це не можна зробити в самих блоках як з вільними блоками. Хібашо ви готові виділяти по дві сторінки (одна на початку, друга на краю) на кожну алокацію. Ми неготові, це багато.
Того нам треба поза алокаційною ділянкою виділити (без використання самих сервісів - проблема піднімання себе за шкірку) якусь "контрольну" ділянку. В якій ми складатимемо інфу за кожен виділений блок. Разом з бісовими типами. Очевидно це має бути список. Але кластися він буде в масив, який служитиме йому як контейнер. Чого так, бо голий масив потребував би в середньому n/2 обходів (а фрагментований - n, n - це кількість клітинок в масиві), а з списком є надія отримати константний доступ (це завдяки LIFO характеру більшости алокацій, крім тих початкових, які робе ФВ, і які спеціально кластимуться з краю масиву).
Цей список ABDL - Allocated Blocks Descriptor List, Абдулла, :D його наявність - перший вислід вимог UEFI, згаданих вище. І він - перший кандидат на хибнопозитивну "нестачу ресурсів" - нам треба вгадати з його розміром, він не може сидіти в самій ділянці, де відбуаються алокації, не може бути по-справжньому "динамічним". Якшо ми не вгадаємо з розміром - ФВ волатиме про нестачу ресурсів.
Тепер на додачу до алгоритмів алокацій/звільнень на вільних блоках, нам ще треба мусолитися в цьому списку.
Це лише для сторінкових ф-цій, пулові мають свій геморой, повірте.
Отже ф-ція виділення шукає придатний вільний блок і виділяє його, роблячи потрібні зміни в списку вільних блоків (СВБ, FBL). Ця операція - лінійна по кількості вільних блоків, але через використання Rover вказівника, все ж, знайти блок потрібної довжини вдається набагато швидше, ніж обійшовши увесь список. Насправді, з книжки Кнута, цей алгоритм не набагато повільніший за buddy аллокацію. Далі ф-ція іде в ABDL, і шукає там вільну клітину, шоб додати цей блок туди. Це лінійна операція, але є надія, шо насправді, майже константна (через той самий LIFO характер алокацій - попросту блок, який нещодавно виділений, скоріш за все швидко буде звільнений, і для ABDL це має означати наявність вільних клітин на початку масиву).

Ф-ція звільнення робить шось навпаки. Вона має адресу блоку, тож знаходити нічого не треба. Додавання в список навіть з злиттям блоків (а там 4 варіанти) всеодно константне по часу. Супир. Далі, вона іде і шукає в ABDL цей блок, і найшовши - помічає його як вільний - клітина тепер може бути перевикористана. Про час доступу - в прикладі вище ф-ція обходить масив і шукає на масиві. А тут обходиться список, який лежить в масиві. Ось тут і прикол з LIFO характером алокацій на який я кілька разів послався. Шо ми оце робимо? Звільняємо блок. Через LIFO патерн (останнім прийшов, першим пішов) динаміки на блоках, існує велика імовірність, шо наш блок лежить десь дуже близько до початку в списку (ми додаємо блоки в перед списку). Уявіть, драйвер виділив собі буфер, пропрацював на ньому і звільняє. Це ж "однопрохідна" штука, ФВ. Нема многопотоковости, нема многопроцесорности. Все робиться "в один прохід". Ну майже. Тож, свіжий блок майже 100% лежить десь на початку списку. Саме того, ми знайдемо його дуже швидко. Але й для контейнера (масива) цей патерн має позитивні впливи, - ми переважно використовуємо перші клітини масиву відтак висока локальність швидкий доступ, дивись вище.

Ну а про складнощі, які тупі вимоги уефі зробили пуловим ф-ціям, я розкажу пізніше.
  • 0

#145 _Ex

    STATUS_OK

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

Відправлено 16.12.2017 – 02:50

То які ж складнощі з пуловими ф-ціями?
UEFI хоче, шоб оті типи використовувалися в дескрипторах памяти, список яких вертає ф-ція GetMemoryMap(), яку ОС лодарь викликає безпосередньо перед тим, як перехопити на себе контроль над системою. Типу він так знатиме все, шо потрібно, шоб діло йшло. І дескриптори ті описують память посторінковими блоками. Але ж ми наче вже врахували це з ABDL, чи не так? Він, Абдулла, і є наш прообраз карти памяти з якого ми, щоразу як нас просять, ліпитимемо карту памяти в сервісі GetMemoryMap(). Так. Але UEFI і пули теж типізувала - сказала: запити в пулах теж вказують тип памяти, який їм треба. Алокації для пулів, як я вже сказав отже робитимуться через виділення сторінок для пулів, і таким чином пулові сторінки уже в ABDL. Але чого там нема, так це інформації для пулових функцій, де саме їм іти шукати нові блоки чи звільняти старі. Уявіть, викликається ф-ція AllocatePool() з типом напр. EfiLoaderData. Куди йти шукати ту ділянку, де лежить цей пул? І це ж не все. Ця сторінкова ділянка для пулу, вона не може бути суцільна. Бо неможливо виділити багато сторінок одразу всім пулам, особливо якшо взяти до уваги, шо їхня кількість майже необмежена (див. вище). А ще ж є проблема звільнення - без неї наші сторінокві запити для пулів лише виділяють память, але не звільняють - не молодьожно. Отже треба ще якісь структури для порядкування цим нонсенсом, який від нас вимагає УЕФІ. Тобто зявляється дворівнева система - кожен пул живе в несуцільному наборі сторінок. Цей набір сторінок вимагає додаткового керування, просто шоб не погубити всю память в пулах, які розширившись, "забули" повернути непотрібну память. Їм треба знати де саме вона та непотрібна память лежить, і чи вона справді непотрібна. А також, звичайно, існує керування самим пулом, це коли він уже задовільняє запити від корисувачів.
Ми маємо "стандартні" пули, обявлені специфікацією. І маємо ще тупішу фігню - безмежну кількість кустарних пулів "для потреб" лодарів. Вдумайтесь, яка безглузда ідея зробити міліон непотрібних типів пулів, коли можна було обійтися двома трьома! Того, в "контрольній ділянці" ми виділяємо (на ініціалізації ФВ, коли точно не може зявитися ніяких кустарних пулів) масив заголовків списків для цих стандартних пулів. Кожен з яких вказує на перший блок сторінок, виділений під пул цього типу, і також, - на перший вільний пуловий блок (нижче докладніше). :wacko: А для пулів нестандартних типів, коли і якшо запити на такі зявляться, ми виділятимемо, вже в алокаційній ділянці (в пулі напр EfiLoaderData типу) список заголовків, кожний елемент якого вказуватиме на список сторінкових блоків, виділених для пулу цього типу і на перший вільний пуловий блок (нижче докладніше). :wacko: :wacko:
Далі. Кожен блок сторінок, виділений під пул певного типу, матиме заголовок на початку блоку, в якому принаймні треба тримати лічильник посилань на нього, reference counter. Для того, шоб могти звільняти цей блок, в разі якшо він більше не використовується. На додаванні в цей блок, лічильник піднімається, на звільненні - опускається, якшо стає нулем - блок (сторінок) звільняється. Якшо список блоків стає пустим - видаляється відповідний елемент списку заголовків (для нестандартних типів, для стандартних - заголовки лежать в масиві в контрольній ділянці, вона не підлягає КП).
В підсумку, ми маємо такі структури:
  • Сторінковий список вільних блоків - Free Page Block List, двонаправлений список.
  • Список дескрипторів виділених блоків (сторінок) - Allocated Block Descriptor List, однонаправлений список, поміщений в масив наперед заданої довжини (в контрольній ділянці).
  • Масив заголовків списків сторінкових блоків для пулів (стандартні типи) - важко й назвати, сидить в контрольній ділянці, грає подвійну роль - обслуговує керування сторінковими блоками для пулів, і також грає роль голови на пул цього типу - важлива відмінність від першої ролі, перше то контейнер для пулу, їх може (і буде) більше одного, для пулу кожного типу, але сам пул (кожного типу) розглядається як одне. Тобто це дві структури, просто згруповані. Перша голова вказує на перший блок сторінок, виділений для пулу цього типу, друга голова вказує на перший вільний пуловий блок для пулу цього типу. Тобто це масив, кожен елемент якого, тримає інформацію для пулу конкретного типу, і кожен елемент цього масиву - це дві голови на списки - на список виділених сторінкових блоків, і на список вільних пулових блоків, цей останній - це якраз те, шо треба для виділення блоків в пулах, повний аналог сторінкового варіанту з п. 1.
  • Також, в контрольній ділянці, треба мати голову на список голів для пулів нестандартних типів.
  • Нарешті, список голів для пулів нестандартних типів, десь в стандартному пулі (ФВ взагалі використовуватиме лише один якийсь), це не на ініціалізації, а лише коли і якшо такі запити надходитимуть.

І оце все, шоб вдовольнити забаганку специфікації, забаганку, плоди якої ніхто не використовуватиме. Та й забаганка та скоріше за все не забаганка. а наслідок похабного ставлення до архітектурування стандарту.
  • 0

#146 _Ex

    STATUS_OK

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

Відправлено 16.12.2017 – 22:57

Ще одне зауваження стосовно керування сторінковими блоками для пулів. Хай вони називатимуться регіонами, бо слово "блок" в нас вже надто перевантажене тут. Отже, маємо певний конфлікт між економією памяти і оптимальною швидкодією. З одного боку якшо регіон стає повністю вільним, ми мали б його повертати в список вільних сторінкових блоків. А з іншого, а шо якшо дуже скоро знову клієнт запитає пул цього типу, і знадобиться наново виділяти такий чи схожий за розміром регіон? Якось це треба збалансувати. Поки шо вигадалось таке. При звільненні пулового блоку, якшо виникає ситуація, шо регіон, який містив цей блок стає повінстю пустим (лічильник посилань стає нулем), ми ідемо і дивимося на лічильник повністю пустих регіонів для пулу цього типу в заголовку списка регіонів. І якшо там ця кількість нуль, тобто це перший пустий регіон в цьому пулі, ми не звільняємо його сторінки, а тримаємо для подальших можливих пулових алокацій. А от якшо вже є такі вільні регіони, тоді звільняємо. Це не супер розумна схема, вона наприклад нехтує розмірами регіонів, це ж теж важить, але з іншого боку, система не ясновидець і вона не може знати наперед, запити на які розміри в пулі прийдуть наступними. Тож це нормальний компромісний вихід.
І також, хоча є начебто сторінковоорієнтована алокація і пулова, ніхто не забороняє не дуже розумному клієнтові робити запити розміром в сторінки через пулові алокації. Тут, ми "караємо" такі бестолокові спроби через додавання додаткового рівня перенаправлення, - ми перекидатимемо цей запит в сторінокву алокацію, і вони не попадуть в пул взагалі. Правда ще треба вирішити, шо робити з "великими" пуловими запитами більшими сторінки але не мультиплами до неї. З одного боку, може виникнути марнування схоже на buddy алокаційне кількісно, а з іншого, маючи такий підхід, ми гарантуємо шо пули возитимуться лише з блоками меншими за сторінку, і, значить, розширятимуться по одній сторінці, шо робить їх ефективнішими по простору і робить ефективншіим згаданий вище метод звільнення регіону за кількістю наявних пустих регіонів (адже тепер усі додаткові регіони будуть розміром в 1 сторінку).
Тобто пулові запити з розміром більшим або рівним до сторінки, закруглюються вгору на сторінку і передаються сторінковим ф-ціям. Це поведінка аналогічна до Windows'івських пулових ф-цій в ядрі.
  • 0

#147 _Ex

    STATUS_OK

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

Відправлено 17.12.2017 – 23:45

Млинець, ці пули зведуть мене з розуму. Виявляється, шо таке роздвоєння для масиву пулових заголовків (один елемент - голова на список сторінкових регіонів, один на пулові вільні блоки), а це для того, шоб мати для кожного типу один пул (поміщений в набір регіонів), дається занадто дорого.
Наприклад алокаційна пулова ф-ція робить такі дії:
Читає заголовок пулових блоків і шукає по списку придатний вільний блок
Знайшовши вона має тепер піти і збільшити лічильник посилань в заголовку сторінкового регіону
Але де він? До якого регіону належить знайдений блок?
Треба іти і читати з масиву голову списку регіонів, і, проходячи, один за одним, робити подвійну перевірку, шо адреса виділеного блоку є внутрі саме цього регіону.
...
Фігня повна.
Який вихід. Робити 1:1, замість 1:n тобто 1 пул, 1 регіон.
Так, в кожному регіоні, буде свій окремий підпул цього типу, а в масиві в контрольній ділянці - лише голови на списки регіонів.
Тепер алокаційна ф-ція іде в масив, знаходить перший регіон, і там працює, шукає потрібний блок. І лише якшо не знаходить, переходе в інший регіон.
Так вона завсіди знає, в якому регіоні вона працює.
Начебто нормально. Але шось не подобається. Але мабуть на цьому зупинимося. Всеодно ж не розумію, шо саме не подобається. :lol:
До речі, є й одне прискорення з цим розділенням на підпули. А саме, в разі якшо у нас "загоряється" подія звільнення усього регіону (памятаєте - це коли його лічильник посилань стає нулем (увесь регіон - де факто один вільний блок), а в наборі регіонів - уже є такий повністю пустий регіон), з таким підходом, нам всього навсього треба викликати сторінкову ф-цію звільнення цього регіону. А з однопуловим варіантом, ще, перед цим викликом, треба було б видалити пуловий блок зі списку.

Ще одне. Про сторінкове перенаправлення, тобто якшо розмір пулового запиту >= розміру сторінки, ми закруглюємо вгору на сторінку і передаємо запит сторінковій ф-ції... Ні, я вирішив відмовитися від цього. Марнування, велике марнування. Візьмімо запит на 4100 байтів. Шо зробе наш алгоритм? Закруглить до 8192 і виділить це. Марнування майже 50%. В середньому - не набагато краще за марнування buddy аллокації, але та швидша принаймні. Була ідея зробити на пуловому рівні алокації bin'ами, напр по 128 байтів, і закругулювати на цю величину - марнування майже нема. Але й сторіноквій ф-ції запит вже не прокинеш. Просто не ясно які вигоди з цього.

Того, просто всі пулові запити оброблятимуться як пулові. Так принаймні буде трохи меншу перевірок.

Шо паганого власне в многопуловому варіанті. Наприклад нехай існує 2 регіони, 2 пули. У нас є запит на блок розміром n. і от уявімо шо в регіоні 1 нема такого придатного блоку розміром m >= n, шоб задовольнити цей запит. а в регіоні 2 є. Якби ці пули були звязані в один список, то ми мали б шанс надибати придатний блок з регіону 2 швидше. Так, і в разі однопулового варіанту, список несортований за розміром (вставляння, шоб робити його сортованим має свою ціну), але все ж, імвірність наштовхнутися на придатний блок швидше в одном списку більша, ніж обійшовши увесь список 1, а потім шукаючи в списку 2. І хз, наскільки насправді довжина пошуку відрізняється.
Але чорт із ним, це вже занадто багато ускладнень. Зрештою, кількість регіонів майже увесь час буде 1. І лише для певних "вироджених" сценаріїв доведеться виділяти другий.
Отже, з урахуванням уточнень вище, ми готові піти і дописати ці бісові алокаційні ф-ції.
  • 0

#148 _Ex

    STATUS_OK

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

Відправлено 21.12.2017 – 23:05

Провозився з першим ввімкненням банани, а було з чим возитися, тепер ось доведеться переробляти SD картки під сосну, ну нема в мене багато карток, а тут вендор такого нагородив, ох, вам же всеодно нецікаво, та й довго це. просто возився і сфотографував їх своїм відроїдним планшетом, вийшло, шо вони всі лежать на столі - цільовий парк в повному зборі, крім чортика, до роботи на якому, як я вже багато разів казав, ще далеко. Це ж правильно - показати парк про який я тут розказую. Показую. Спонсор якости фото - андроїдний планшет від самсунга! :D
Зображення
  • 0

#149 _Ex

    STATUS_OK

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

Відправлено 24.12.2017 – 10:55

А чи знали ви, шо в тех мост супир секуритест протоколі ева, SSH, ->нема<- бісової можливости передавати файли (через бісове SCP - секуре опєть жеж копі) без шифрування? я теж не знав. От узяв образ для банани, який вони вибрали зробити 8 ГБ розміром (всі образи, вони просто добили нулями той блоат до 8-ми гектраів, подякуємо ж, шо не до 16-ти!). Взяв і почав передавати. Гляну думаю на загрузку ЦП. Ну 100% звичайно, лінукс же. Неважно шо там 4 ядра, ну нашо таким просунутим чувакам як униксоїди та всрана многопроцесорність, вони суворо все ганятимуть в одному процесі, це уних дух! Але потім придивися - "лишилось 40 там шось хивлин..." Шо??77 Скільки хвилин? Думаю, стривайте, панове, навіть для калолінукса - це занадто. І потім мене осінило - це гуано SSH шифрує/дешифрує ті нулі на обох краях, ось чого воно буде смажити нашу бідну плату 40 там з хвостом хвилин... Пошукав у гуглі - так, нема опції задати нешифрувати. Нема! Кому це треба, правда ж! Дійсно, от сидю я в своїй локальні мережі, переганяю з машини на машину цей кал, це ж така примана для хацкерів - взламати і вкасти це все! І передати в НСА. О, нема межі мої лічної неприязні до цього лінуксового світу. Шоб ви знали, SSH - це винахід з тієї божевільні.

Так, тепер я інсталюю ftpd і шлю все через ftp. Правда вже нічого слати. :lol: мені просто треба було попропалювати крепекс на пару моїх плат, шоб могти на місці флешити мою ФВ. І навіть для цього крепекс би був у нагоді тіке на парі - мурані і йоді. На сосні нема напаяного сховища. На неоні через послідовність ром-коду, мені всеодно доведеться витягати SD-картку.
А от на аргоні, хоча там і є нанд, виявляється, попри наявність цієї плати з 12-го року і її популярности, крепексоїди так і не впиляли нормальну підтримку нанду (на відміну від йоду), і там просто і виробником і армбіаном, і до нині тупо пишеться ext4, шо інакше називається "вбий нанд за пару місяців". його тут всього 4 ГБ між іншим, можна лише уявити який там wear був би з униксовою мастурбацією текстовими фалами. :facepalm: Ну а оскільки це гімнолінукс і тут неможливо просто "знайти, завантажити і інсталювати драйвер", - то нанд відпочиває. Мені кажу ж лінукс тут був потрібен лише шоб прописувати на картку на місці свою ФВ. Але, ще раз, через капризи ром-коду і через вище зазначені речі, це в більшості неможливо і з крепексом на місці. Тож, добре, шо їхній ламерський скрипт sata-install.sh, який, зважаючи на назву, інсталює на нанд, :lol: впав. Якби він спрацював, нанд би був апаснастє. А так, я вияснив, і тепер аргон як і сосна перетоврюється на SD онлі. Ну для вантаження точно. Наявна САТА там не допоможе - ромкод не вміє з сати вантажити. Це ми зможемо звідти вантажити ОС. Нанд хай відпочиває, аж до тих часів, коли я зумію сам постачити для нього нормальну захисну і френдли ФС.

Підсумуємо можливості, де б я зміг писати на місці ФВ (це мені потрібно).
  • муран - тут лінукс стоїть на eMMC і я можу вставивши SD картку, оновлювати її на місці, але коли я кажу "на місці" я ще до цього маю на увазі, шо картку не треба витягати (всі ці частини зношуються, от чого не хочеться їх постійно смикати). І я чесно вже не памятаю, як там ром-код себе веде і чи можна там натискаючи якісь кнопки чи перемикачи (джампери), впливати на порядок вантаження. Останнього разу я займався мураном рік тому. Тож і тут навіть не ясно. Я тільки памятаю, шо TI-шний ром-код хоче, шоб його навантаження називалося MLO. :lol:
  • йод - тут все як у людей: крепекс на нанді (на якому UBIFS, тобто принаймні є надія, шо вони там хоч намагаються боротися зі зношенням), моя ФВ на SD-картці, і порядок вантаження перемикається джампером, який майже вічний і не зносюється. :)
  • аргон - через описану недолугість підтримки нанду з боку виробника, лінукс може бути лише на SD картці, а значить ніякого оновлення "на місці" не може бути.
  • сосна - те саме, але через відсутність напаяних сховищ 2-го рівня взагалі.
  • неон - тут крепекс на eMMC, але порядок вантаження Allwinner-івським ром-кодом такий, шо якшо SD-картка вставлена, то він намагається вантажити спочатку з неї. Тобто треба увесь час витягати картку енівей.
  • чортик - тут рокчипівський чип, і темний ліс. Ясно лише те, шо на платі стоїть eMMC з відром, а рокчипові камінці мають спецільну лінію, таку, шо кнопочка підведена до неї, може направляти ром-код вантажити через USB, посрєцтвом якогось мутного самопального протоколу. Це хоч і може бути зачіпкою в наших спробах пробратися в плату, :brovy: але це точно не зараз - все дуже туманно. Є там і SD слот. Може місцевий ром-код теж як і Allwinner-івський спочатку вантажить звідти. Тоді б то було просто чудово! Ще прицтаїть виясняти.

Повідомлення відредагував _Ex: 24.12.2017 – 11:19

  • 0

#150 _Ex

    STATUS_OK

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

Відправлено 24.12.2017 – 18:14

Невеличка нотатка, їх насправді не важче робити на компутері, ніж на папірці.
Рокчипові камінці, нажаль не вантажать спочатку з СД картки. Вони пробують вантажити в такому порядку:
наплатний eMMC
SPI NOR флеш
SPI NAND флеш
SD/MMC картка
після неуспіху тут, входять в згаданий вище USB режим з самопальним протоколом для завантаження.

Тож, у нас є дві опції - руйнівна для eMMC-шної відроіїдної інсталяції і неруйнівна.
Перша полягає в псуванні даних на кількох секторах eMMC, за допомогою їхніх утиліт, які дозволяють доволі небезпечним методом увійти в той USB режим і понаписувати шось. Якшо утиліта тупа і ніц не перевіряє, ми напишемо туди нулів, і далі, ром-код буде вантажити наші кодеси з SD-картки. Якшо перевіряє, то нема такого метода, девайс не заручений, і рутити я його не хочу, не хочу з цим возитися. Чого метод небезпечний? Того шо OTG порт на коробку, до якого треба приєднати хост, зроблений типу A. Через це й кобель нестандартний A-A. Я хоч в електриці й не розбираюсь, але оскільки USB - це шина, і вона дає живлення своїм дітям, уявіть шо буде, якшо та бадяга не надумає ввійти в режим девайса. Ну от шо буде якшо кобелем типу A-A зєднати два USB порти на компі? Або на двух сусідніх компах? Не робіть цього ніколи!!11 Коротке замкнення буде. Проблема в тому, шо там треба під час підключення коробка, одночасно давити на кнопку, шоб все вийшло, і ніхто дідько не каже, увесь час треба її тримати, чи лише трохи для пуску? Насправді дуже мутний спосіб, навіть якшо страхи зайві, уявіть яке воно всовувати вилку і сірником штрикати в дірку одночасно, а потім же треба шось в кансолі набивати, і знову вони не сказали скільки воно чекатиме...
Друга опція, просто щоразу використовувати цей сірниковий метод, тоді ром-код грузитиме нас в SRAM, і ми можемо починати наші справи - ініціалізація памяти, памятаєте по йоду. І знову ж, якшо документації досить, то далі ми самі можемо вже зчитувати свою ФВ (DXE) з SD-картки.
Але це на потім. З arm64 цілей, першою за всією логікою має бути сосна. Вона ж ОПК, девелопер френдли, з нею не треба збочуватись так як з цим відроїдним коробком (який зато 8-ми ядерний!).
Зображення
  • 0

#151 _Ex

    STATUS_OK

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

Відправлено 01.01.2018 – 16:46

Ну от я виявив (нарешті :D), шо на йоді, HDMI контроллер - це зовсім не та фігня, яка я думав описана в секціях про LCD контроллери. Виявилось, шо хоча, скоріше за все, ці останні теж потрібні, та все ж, HDMI трансміттер - це окрема річ. І вона незадокументована! :angry: Та не все так пагано в цьому світі - існують і компанії, які піклуються, шоб їхні продукти отримали добру підтримку і того випускають дебелу, я б сказав дебелезну документацію на свої продукти. Як от колишня Вільнадрабина (Freescale), а тепер NXP, а в майбутньому - скоріш за все Qualcomm. Оказуєцця, цей трансміттер, зроблений Synopsys і обізваний Synopsys Designware HDMI 1.4 Transmitter, використовується в iMX6 процесорах, і там - все задокументовано. Закачав. Дійсно. 5891 сторінка. Сльози радости прям течуть. Така ліхкотня! :lol: До речі, в цьому бісовому трансміттері більше регістрів, ніж в усіх інших контроллерах перифірійних пристроїв на йоді разом узятих!1
Малювання на HDMI дисплей впевнено крокує на південь в добре визначену позицію (стан), коли модель драйверів визначена і спроєктована і усі підлеглі сервіси надані. От тільки тоді і буде свято писання lcd-hdmi-whatever-yet драйвера заради естетики й візуалізації. А дьорті хак з малюванням зараз, не вийде. Ця фігня здатна розчавити своєю колосальністю найнаївнішого напеолена. :)

1 - Їх 341 штука. :) А контроллерів два насправді - Link Layer і PHY. Це мабуть найскладніша фігня, з якою я покишо тут зіштовхувався.

Повідомлення відредагував _Ex: 01.01.2018 – 17:11

  • 0

#152 _Ex

    STATUS_OK

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

Відправлено 07.01.2018 – 17:49

Вирішив я тут менше писати, всеодно ніхто не читає. Якшо вже й писати, то шось в практичнішому напрямку - робити вікі на сорсфорге і робити її юзабельною. Там хоч толк буде якийсь. Тут просто коротко звітуватиму.

І як завершальний штрих до цієї обємної писанини, і як перевірка, чи я взагалі вмію лаконічно висловлюватися, згадаю про ще одну ціль в парку. яку я хоч і згадував. але мало, і вона завсіди була на задньому плані.

Наш проєкт, хоббіїстичний, - це переважно т.зв. OSDev проєкт - тобто безнадійно дурна спроба написати свою ОС. Фірмваря повстала як підпроєкт, казав уже за це. Мріялося мати багато архітектур для проєкту. Це того шо, так цікаво, того шо, так система виходить краще. Саме того я купив еплівський iMac g5, моноблочний компутер з ppc архітектурою, як тільки виявив таку можливість. Було це восени 14-го року. Так і стоїть він ось біля мене. Нашо робити ОС під закинуту платформу? Архітектура не закинута, і хоча доступу до ібеімеївських серверів нема, це не так страшно, там просто новіші версії того самого ppc. А ще є NXP, який теж не закинув свої ppc серії. Тож сенс є. А зважаючи на той ахтунг, який спричили Meltdown і Spectre баги в інтелівських процесорах, може так статится, шо цікавість до альтернатив підскоче. PPC - один з таких. Тож проблема не скільки в нерелевантності цієї цілі, скільки в різниці між мріями і реаліями щодо можливостей. Коли це уявлялося тоді, то, звичайно, деталі і розуміння складности опускалися, ігнорувалися. А тепер, коли шось зроблено, ти розумієш - понабирано забагато роботи, шоб її осилити... Згадайте допис вище - один єдиний hdmi контроллер якого всеодно недостатньо самого навіть для виведення на дисплей, має таку складну програму модель. З 341-м бісовим регістром! Тобто чи старатися підключати ppc чи ні, це питання складности через одні лише обєми.
Все ж, покишо цю ціль не скинуто. Продовжуємо копирсатися з mips-ом, далі arm-и, а там видно буде.

Про саму машину - це нормальний компутер, з 2004-го року. Звичайно його специфікація не така вже й солідна на ті роки, особливо в співставленні до його ціни. Так це ж апле, там завсіди так, фонати, купують понти. Ну годі з ними. Нам була потрібна ppc машина. Маємо її. Там одноядерний ppc процесор, я забув його точну модель 900 там шось, неважливо зараз, це POWER4 версія архітектура. він 64-бітний, але, сподіваюсь, там можна ввімкнути дурника 32-бітний режим, бо памяти тут 512 МБ :facepalm: (це як на мурані - найслабшій армівськиій цілі). А на RISC процесорах завантаження в регістр адреси при переході з 32 на 64 біти перетворюється на "holy guacamole". Бо всі створювачі цих архітектур чогось рішили тримати довжину інстуркції тією самою - 32 біти. Місце вони економлять. З цим блоатом як відроїд, жаба, сісярп і подібне, шо ви там наекономите! І от заванатження адреси на 32-бітних RISC-ах бере дві інтсрукції, шось накшталт
lui $r0, %hi(label)
ori $r0, $r0, %lo(label)

а вже на 64-ох бітах, 4. в кращому випадку! От на ppc, випадок не "кращий", там, як я зрозумів, 5 інструкцій треба. Шоб лише мати адресу якоїсь ділянки в регістрі. Звичайно потім ще треба з тією адресою шось робити - читати її, писати в неї, передавати на неї керування...

А тут 512МБ памяти. І можливий максимум - 2ГБ. Нашо тоді ці 64 байти? Кількість регістрів та сама. Ніякого виграша, самі програші. Тож, якшо є 32-бітний моде, саме так і використовуватимемо.
Память до речі суворо DDR. Так, в 2004 році, коли на в десяток разів дешевших пісюках стояла вже DDR2, тут просто DDR, першої версії. Частота треба розуімти - 200МГц.
Процесор бігає на 1.8 ГГц. Теж не густо в порівнянні з наприклад моїм 4-м пеньком з 2002-го, який я лише недавно зняв з плати і поклав в шафу відпочивати. На ньому 2.8ГГц.
Графічна картка Nvidia, але судячи з системної інфи, яку показує blondeOS, це AGP картка. Тобто ще один релікт. Тоді як 2004-му, PCIe вже ж наче рулив на пісюках по повній. Знову, на моїй старій асусовій платі рулив. На моїй моделі виходить взагалі нема PCIe шини. Ну або ж нема пристроїв на неї причеплених.
ОпинФірмварю треба інспектувати, там все буде ясно. Я ще не інспектував. Ввімкнув, а там вентилятор ФВ регулувати не вміє, різниця між слабкими обертами і на всю - колосальна, він перетворюється на гелікоптер, ось ось і злетить... Плюс, жартівники з епла, мабуть, шоб їхні пользуни не призвичаювалися шось там рихтувати в фірмварі, виставили ультрадрібний розмір шрифту. І БІЛЕ ТЛО!!1 Уявляєте кансоль з БІЛИМ ТЛОМ? :lol:
А я не знаю ще як там кольори міняти.
Диск 80 ГБ. WD.
Є мережна картка, є усб, яке помойму усб 1.1 онли, :( буду радий якшо помиляюсь. Ну і є ще еплівське улуюблене фіревіре. Всяка інша дрібна фігня, якийсь модем там. то таке, на потім. А, CD/DVD є!
ОС майже неюзабельна. Сафаря зависає на другому посиланні стабільно. Просто припиняє всяку роботу. Висить і все. Підтримки ніякої. Ніяких програм нема. Краще туди ставити убогу але все ж таку, шо підтримується open bsd. або ж крепекс.

А от фірмваря там - карасо. Називається Опин Фірмваря. Це саме та, звідки лінуксоїди шо пишуть під арм, кривокосо зідрали девайсні дерева. :yes:
Завдяки можливостям які вона надає, тут ми можемо починати наш проєкт з писання лодаря під неї, і - це просто фантастика - вантажитися з USB! Це ще треба перевірити, але майже 100%. От просто береш флешку, кладеш туди свого лодаря, і ядро, і все інше, і кажеш ОФ вантажити звідти. І вона це робе. Саме так має робити справжня ФВ. Не "конпіліруйте свою версію убута, шоб змінити роздільну здатність екрану"... а саме от так.
Є мануали й специфікації і на процесор і на ФВ, реально дістати й інструменти. Просто, як вже казано, - набрано занадто багато завдань. Але, бачимо - тут все готово до спроб - бери й роби. Я ж так само починав на міпсі в лютому вже минулого року.
Одне слово - пізніше. Пробуватимемо це пізніше.

ЗІ. Висновки - ну вопшім лаконічно я таки не вмію. :lol:

Повідомлення відредагував _Ex: 07.01.2018 – 17:50

  • 0

#153 _Ex

    STATUS_OK

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

Відправлено 16.01.2018 – 21:36

Писати то тут я вирішив менше. Але постити Гаврилівну менше не вирішив! Яка всьотакі красива дівчина. :wub:
Зображення
  • 0

#154 artemko

    Чайник

  • Користувачі
  • Pip
  • 6 повідомлень

Відправлено 16.01.2018 – 23:15

:otruta:
  • 0

#155 _Ex

    STATUS_OK

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

Відправлено 09.04.2018 – 20:30

Ну шо, писати поки шо ніпрошо, працюємо. :)
Запостю ось цю лялечку просто. Дайте мені таку пограцця! :ura: :lol:
Зображення

Повідомлення відредагував _Ex: 09.04.2018 – 20:37

  • 0

#156 _Ex

    STATUS_OK

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

Відправлено 17.04.2018 – 13:04

Боже.
Зображення
  • 0

#157 _Ex

    STATUS_OK

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

Відправлено 18.04.2018 – 13:22

Зображення
  • 0

#158 Уповноважений

    Козак - перевертень

  • Модератори
  • PipPipPipPipPipPipPipPipPipPip
  • 7175 повідомлень
  • Стать:Чоловік
  • Місто:пекельне болото

Відправлено 18.04.2018 – 17:03

Дітей ще й досі не має? Буде як Ангеліна Джолі підбирати чужих дітей по світу?
  • 0

#159 _Ex

    STATUS_OK

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

Відправлено 18.04.2018 – 19:45

Не має. Вона робе новий альбум. А взагалі, їй жениться - як з гори котиться, вже двічі там побувала. :D
  • 0

#160 _Ex

    STATUS_OK

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

Відправлено 19.04.2018 – 20:36

Не знаю шо ця корцінко справді має означати, по кінах не прохаваний, а ак, звідки корцінко, - прохаваний (тицяйте імиджь, він тицябельний), але вигляд чувака на фотці заставив подумати і відзначити - точно мій вираз, коли хочеш почитати шо нібудь асобіннаво на форумах про плати, а бачиш одне лінуксове дрочилово, або на форумі з оздеву хочеш подивицця нові скриншоти від умільців, а там - одні теми типу "в мене не робе qemu!11", "моя GDT дає трипл фолт"... #нудно коротше, треба занурюватися в свій власний прожект. :)
Зображення

Повідомлення відредагував _Ex: 19.04.2018 – 20:37

  • 0



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

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