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

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

GPT UEFI FAT

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

#101 kalamar

    Старійшина

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

Відправлено 18.04.2017 – 13:14

Перегляд допису_Ex (13.04.2017 – 23:25) писав:

Оптимістично, - це до нового року навигадував собі занять.) Шоб ви розуміли - під "драйверами" теж маються на увазі їхні зародки. Я може й наївний, але не настільки, шоб вважати, шо одразу вийдуть повнофункціональні весчі. :)
Вправи то звичайно добре, але з тим всім обережним треба бути, щоб вас часом не покусав Поттерінг. <_<
  • 0

#102 _Ex

    STATUS_OK

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

Відправлено 18.04.2017 – 14:48

Потеринг маладес, він не соромиться, а також вміє і хоче, перетворювати лінукс в пародію на макось. ^_^
Картинку побачив смішну: Лінукс Торвальдс зробив свій вибір. :)

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

#103 kalamar

    Старійшина

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

Відправлено 18.04.2017 – 16:48

Перегляд допису_Ex (18.04.2017 – 14:48) писав:

Потеринг маладес, він не соромиться, а також вміє і хоче, перетворювати лінукс в пародію на макось. ^_^
Картинку побачив смішну: Лінукс Торвальдс зробив свій вибір. :)
Це дуже стара картинка.
Лінукс ніколи не був і не стане пародією на вінду чи мак. Вінда і Мак це готові іграшки, запаковані в яскраві коробки, а лінукс це конструктор, це набір запчастин. Десктопні лінукси це просто різні варіанти використання того конструктора, серверні - инші варіанти, для суперкомп’ютерів - инші, для IoT пристроїв чи роботів - инші. Ніколи готова іграшка не замінить конструктор.
  • 0

#104 _Ex

    STATUS_OK

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

Відправлено 18.04.2017 – 21:11

Перегляд дописуkalamar (18.04.2017 – 16:48) писав:

Це дуже стара картинка.
Лінукс ніколи не був і не стане пародією на вінду чи мак. Вінда і Мак це готові іграшки, запаковані в яскраві коробки, а лінукс це конструктор, це набір запчастин. Десктопні лінукси це просто різні варіанти використання того конструктора, серверні - инші варіанти, для суперкомп’ютерів - инші, для IoT пристроїв чи роботів - инші. Ніколи готова іграшка не замінить конструктор.
Саме того >90% персональних компутерів бігають на Віндовс. ;)

Цитата

а лінукс це конструктор
Прихований текст

До речі, конструктору було б непагано бути модулярним - шоб справді конструювати з нього шось. А не купою г, яку щоразу треба ліпити наново. Ось у мене плата - CI20. На ній GPU - PowerVR SGX 450. Досить звична картина, читаємо лінуксових конструктороробів:

Цитата

The graphics driver for the CI20 is an out-of-tree kernel module. Kernel modules must be recompiled if the base kernel is modified. Modules are only allowed to be loaded when they have been compiled using the exact source tree and kernel configuration as that of the running kernel. (гнучкість вашого "конструктора" просто ошиломітільних висот набуває, судячи з цього абзацу. прим моя)
As the default Xorg driver also uses the GPU for running the X window system, it would seem that Debian GUI fails to load when you recompile the kernel from sources. The only thing that needs doing, is to recompile the kernel module for the GPU and then copy that module onto the filesystem.
It's also possible to disable the GPU, if you don't need it for any specific task. You will still be able to use the Debian GUI (with a tweak to your xorg.conf), but hardware 3D acceleration and OpenGL will be disabled. Instructions for disabling the GPU are available here
It is important that your kernel module and user module version match, else the SGX driver will fail to load. (якшо того мало - ось ще трохи удобств конструювання, просто сьвато випилювання лобзіком прим моя) The following table details this: Kernel Version Kernel Module Source User Module Binaries 3.0.8 1.13.3341330 1.13.3341330 3.18 1.14.3759903 1.14.3759903
Як то кажуть - hilarious, дуже по-конструкторськи. Висновок заохочення в кінці теж доставляє веселощів. "А може вам не треба те GPU? То краще виключіть його". Навіть сцилка на інструкції з вимкнення є. Ояк. Вся казка.

Цитата

Лінукс ніколи не був і не стане пародією на вінду чи мак.
А от Потеринг так видно не вважає, визнаючи, шо треба мавпуватися рівнятися на макось.
Але я б оцю фразу "не був і не стане" - зробив би лінуксовим гаслом. :lol:

Годі цього срачу, всі ми знаєм, чим є лінукс і чим він не є.)
  • 0

#105 kalamar

    Старійшина

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

Відправлено 19.04.2017 – 01:38

Перегляд допису_Ex (18.04.2017 – 21:11) писав:

До речі, конструктору було б непагано бути модулярним - шоб справді конструювати з нього шось. А не купою г, яку щоразу треба ліпити наново. Ось у мене плата - CI20. На ній GPU - PowerVR SGX 450. Досить звична картина, читаємо лінуксових конструктороробів:
Так а що, складно модуль відкомпілювати? В чому ви тут проблему бачите? Є сирці, компіляція модуля не займає багато часу, це не компіляція ядра. Не хочете, репозиторіями користуйтесь. Якщо ви промислово то використовуєте, на багатьох дивайсах, зробіть свій репозиторій, і оновлюйте весь парк, для цього є пакетні менеджери.
Напр. в Canonical вже не в пріоритеті Linux for human beings, вони закидають неприбутковий десктопний лінукс, на користь прибуткового Linux for robots. :wink2: (Це я так написав, вони так те кажуть, тільки думають) Спеціальний формат snaps для того зробили, мінімальний лінукс Ubuntu Core, добавте сюди їх реп, і на основі Ubuntu Core ви швидко можете зібрати конфігурацію, яку захочете.

Такий дивайс?

Повідомлення відредагував kalamar: 19.04.2017 – 02:00

  • 0

#106 _Ex

    STATUS_OK

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

Відправлено 19.04.2017 – 14:21

Перегляд дописуkalamar (18.04.2017 – 16:48) писав:

Це дуже стара картинка.
Вибачте, виправляюсь: він давно зробив свій вибір. :D

Перегляд дописуkalamar (19.04.2017 – 01:38) писав:

Так а що, складно модуль відкомпілювати? В чому ви тут проблему бачите? Є сирці, компіляція модуля не займає багато часу, це не компіляція ядра. Не хочете, репозиторіями користуйтесь. Якщо ви промислово то використовуєте, на багатьох дивайсах, зробіть свій репозиторій, і оновлюйте весь парк, для цього є пакетні менеджери.
Напр. в Canonical вже не в пріоритеті Linux for human beings, вони закидають неприбутковий десктопний лінукс, на користь прибуткового Linux for robots. :wink2: (Це я так написав, вони так те кажуть, тільки думають) Спеціальний формат snaps для того зробили, мінімальний лінукс Ubuntu Core, добавте сюди їх реп, і на основі Ubuntu Core ви швидко можете зібрати конфігурацію, яку захочете.
Каламаре, не клейте дурника. Мені шо знову цитату наводити? Там навіть не перекомпілювання модуля найцікавіше, хоча це теж рідкісний ідіотизм, адже нормальна система просто бере і інсталює драйвери вже скомпільовані виробником! Та найцікавіше оце, з точки зору "конструкторських можливостей" так би мовити, знову цитата для вас:

Цитата

Kernel modules must be recompiled if the base kernel is modified. Modules are only allowed to be loaded when they have been compiled using the exact source tree and kernel configuration as that of the running kernel
Уловлюєте епічність "гнучкости" - модулям дозволено бути завантаженими лише якшо вони були скоміпльовані використовуючи точно таке саме дерево ядра і його конфгурацію!111 це найпотужніше шо можна було туди втулити шоб вбити навіть натяк на "конструктор". звичайно, вони його не "вставили" спеціально, воно таке криве вийшло за його кривожопою натурою. Тобто це не баг, це фіча. :yes:
Шоб створити драйвер на Віндовс, мені не потрібно "точно таке дерево" Віндовс, мені взагалі непотрібно ніяке дерево, нафіга воно мені, адже я ж всього якийсь драйвер пишу під якийсь пристрій. Мені потрібен набір хедерів грамотно зібраний такий який дає можливість збирати не теш о на різні версії Віндовс, але й на різні архітектури, і інтерфейс з ядром - шо і як я можу і маю використовувати. І там все це є. Продумане і чітко вибудоване.
А лінпуксі, треба "точно таке дерево" з "точно такими конфігураціями". For the love of God - нашо? Чого?... :facepalm: Про негнучкість компіляторів я вже навіть не хочу починати. І ще пасталякають про "налаштовуваність". Тобто дровеняка, дрючок, а не конструктор.

Цитата

Ви знущаєтесь? Я тут і фотачки його постив, і зворушливу історію розказував, як класний чувак з Imagination мені його подарував і прислав з третього разу. І я вже накатав сторінки три в цій темі, програмуванню його присвячені. А ви мені пєдєвікію показуєте. Зараз почнете мене переконувати, шо там всьо чотко з лінуксом? :D Не треба. Ви краще поясніть чого там (а також в усіх інших платах зушених юзати лінукс) допотопне ядро 3.0.8, а не найновіше? Невже вендорам не вистачає гнучкости цього мего-"конструктора", шоб пиляти найновіші найофігенніші версії цього божественного творіння. :D

ЗІ. Ваш канонік_кал "мєчіться як юная развєдчіца", і так же нікого це не цікавлять їхні прожекти, вони як той невловимий Джо. вони класичні невдахи. з амбіційністю оберненопропорційною здатностям. Більше лулзів. Справді, нафіга їм той відсталий десктоп, скіке ж можна його покоряти :ggggg: Вони вже також "покорили" мобайл, смартфони з планшетами. Тепер хай лажають покоряють хмари, йот і роботів. Сферичні невловимі тріумфатори в вакуумі на лиці. Можливо стануть №1 хоч на несправжньому маркеті. :D

Повідомлення відредагував _Ex: 19.04.2017 – 14:27

  • 0

#107 kalamar

    Старійшина

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

Відправлено 19.04.2017 – 14:52

Перегляд допису_Ex (19.04.2017 – 14:21) писав:

Каламаре, не клейте дурника. Мені шо знову цитату наводити? Там навіть не перекомпілювання модуля найцікавіше, хоча це теж рідкісний ідіотизм, адже нормальна система просто бере і інсталює драйвери вже скомпільовані виробником! Та найцікавіше оце, з точки зору "конструкторських можливостей" так би мовити, знову цитата для вас:
Про компілювання модуля там і йдеться. Що вас там бентежить? Наскільки я зрозумів, оскільки дивайс екзотичний, в дефолтному дебіані того модуля нема, тому вам самому треба відкомпілювати модуль. Берете заголовочні файли ядра і компілюєте. Це ж конструктор.

Перегляд допису_Ex (19.04.2017 – 14:21) писав:

Ви знущаєтесь? Я тут і фотачки його постив, і зворушливу історію розказував, як класний чувак з Imagination мені його подарував і прислав з третього разу.
Це ви знущаєтесь, якщо уявляєте, що я читав, що ви тут писали. Я тільки там де ви каламара згадали відповів.

Перегляд допису_Ex (19.04.2017 – 14:21) писав:

Ваш канонік_кал "мєчіться як юная развєдчіца",
Вони розробляли ряд прожектів. В деяких є успіх (профіт), в деяких нема успіху (профіту), концентруються на тих, що дають профіт. Це логічно. Десктопний лінукс не приносить профіту, ну не виходить отримати профіт із системи, яка безкоштовно розповсюджується. Але їхнє юніті аж ніяк не фейл, для мене на сьогодні це єдине десктопне оточення, яке комфортно юзати без такого незручного для ноутів дивайсу, як миш, сподіваюсь, що хтось його і далі підтримуватиме.
  • 0

#108 _Ex

    STATUS_OK

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

Відправлено 19.04.2017 – 16:27

Цитата

Наскільки я зрозумів...
Пагано ви зрозуміли. Перечитайте цитату, я навів її двічі. І двічі пояснив, шо мене "бентежить".
Екзотичність пристрою там ні до чого. "До чого" там модель (її будь яка відсутність) як самих драйверів так і будівельної системи в широкому сенсі цього слова. Для постачальниік драйверів пристроїв, BSP (пакет підтримки плати), для конструювання - найгірше шо можна було коли небудь вигадати.
І саме того, майже всі вендори які використовують лінукс (вимушені через відсутність альтернатив), мають в своїх продуктах старезні версії ядра - за цієї моделі (її відсутности), їм би прийшлось переробляти дуже багато, шоразу як виходе нова версія ядра. Безструктурність, хаотичність, повна відсутність модулярности1 - абсолютна непридатність для конструювання. всі від індженика до гугла і ред хата використовують болісно напиляні древні версії.

Цитата

Це ви знущаєтесь, якщо уявляєте, що я читав, що ви тут писали. Я тільки там де ви каламара згадали відповів.
У блога й назва відповідна. :D
Ну фотку ж ви могли бачити хоч.
Так, це той апарат. Маленький mips PC. ^_^

1 - ще раз - лінкувати об'єктні файли "на льоту" і зрідка це використовувати для жменьки драйверів - це не модулярність. Модулярність - це можливість незалежної розробки модуля, - вам не має бути потрібно ані дерево ядра ані його всрані конфігурації. Навіть фото Столмана на стіні не має бути потрібно.
Це модель, інтерфейс і правила поведінки для цих модулів. Чому вони мають слідувати, чого не мають робити. Це має бути організовано добре, воно не може змінюватися радикально від версії до версії. Цього не можна порушувати. Не можна обходити і впаювати якісь локальні непридатні ні для чого іншого деінде костилі. Має бути можливість чітко зв'язувати модуль і всю решту, через версіонування (моделі) і забезпечення зворотної сумісности.
Є в лінуксі нормальна модель драйверів? Зрозуміла стабільна біла і пухнаста. Як у Віндовс WDM? Навіть UEFI має модель драйверів, шоб постачальники легше могли робити свій внесок. Всюди де є постачальник і споживач, має бути добре визначений програмний інтерфейс між ними. Тоді є й справжня модулярність. WinAPI такий, POSIX такий. У лінукса є нормальний API для його розширень (драйверів)? У лінукса є купа незв'язного несумісного гівна. Яке ще надодачу постійно хаотично змінюється. Саме того, писання розширення для лінукса - це ніколи не конструювання, це завсіди перепилювання самого лінукса. З усіма наслідками для ефективности цього.
Загалом, шоб модулярність була можлива, треба шоб дизайн системи забезпечув її, маючи це "вбудованим". Дуже багато чого там має бути "аваре" про модульність системи. Також там має бути присутня допоміжна функціональність спрямована полегшувати модулям життя. Будь шо від ран-тайм хелпер сервісів, до можливости рознести драйвер пристрою в порт-мініпорт пару, або клас драйвери, наприклад, де багато чого уже написано і лежить в бібліотеці, яку ти можеш використовувати. Але таке можливо, лише якшо між цими компонентами встановлені закони взаємодії. Якшо ті закони ніколи не визначені нормально і міняються постійно без потреби, звичайно тоді з'являються тексти як отой який я виділив червоним - тоді дійсно, потрібно завантажувати те саме дерево і ті самі налаштування виставляти, шоб це все заробило. Повна противність модульності і конструкторству. Весь дизайн має бути спрямований на ефективне забезпечення цього. Коли того немає, то його не має. "Пілітє, Шура, пілітє". Це "нескладно". ;)

Повідомлення відредагував _Ex: 19.04.2017 – 16:29

  • 0

#109 kalamar

    Старійшина

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

Відправлено 19.04.2017 – 16:50

Перегляд допису_Ex (19.04.2017 – 16:27) писав:

Є в лінуксі нормальна модель драйверів? Зрозуміла стабільна біла і пухнаста. Як у Віндовс WDM? Навіть UEFI має модель драйверів, шоб постачальники легше могли робити свій внесок. Всюди де є постачальник і споживач, має бути добре визначений програмний інтерфейс між ними.
Це хто так вирішив? Великий ЕХ, найбільший теоретик операційних систем всіх часів і народів. :rolleyes:
В лінуксі не так як в віндовз. В віндовз в принципі не можна так зробити, як в лінукс, бо ніхто вам сирців ядра віндовз не дасть.

Цитата

To ease the burden of companies maintaining their (proprietary) device drivers out-of-tree, stable APIs for the device drivers have been repeatedly requested. The Linux kernel developers have repeatedly denied guaranteeing stable in-kernel APIs for device drivers. Guaranteeing such would have faltered the development of the Linux kernel in the past and would still in the future and, due to the nature of free and open-source software, are not necessary. Ergo, by choice, the Linux kernel has no stable in-kernel API.
В модуль напр. може входити пропраїтарний блоб, який з умов ліцензування, не може бути в ядрі.
Тут як завнішні модулі збирати.
Але мабуть на сайті розробників є детальні інструкції саме по тому дивайсу.
А розробляти драйвера, то розробляйте, хто вам заважає.

Навіщо ви на той дивайс дебіан ставите, скачайте драйвера від розробника і поставте на той дивайс вінду. :8:
  • 0

#110 kalamar

    Старійшина

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

Відправлено 19.04.2017 – 18:25

Перегляд допису_Ex (19.04.2017 – 16:27) писав:

Це модель, інтерфейс і правила поведінки для цих модулів. Чому вони мають слідувати, чого не мають робити. Це має бути організовано добре, воно не може змінюватися радикально від версії до версії. Цього не можна порушувати. Не можна обходити і впаювати якісь локальні непридатні ні для чого іншого деінде костилі. Має бути можливість чітко зв'язувати модуль і всю решту, через версіонування (моделі) і забезпечення зворотної сумісности.

Цитата

This problem can be solved by decoupling drivers from the kernel and supplying them separately so that you could enjoy stable kernel version X with brand new drivers like it's done in most other proprietary OS'es. I've been thinking of asking Linus about this decoupling for years already but I'm hesitant 'cause I'm 99.99999% sure he will downright reject this proposal."
http://www.phoronix....s_nvidia_finger

Повідомлення відредагував kalamar: 19.04.2017 – 18:25

  • 0

#111 _Ex

    STATUS_OK

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

Відправлено 19.04.2017 – 19:56

Це добре, шо ви самі найшли їхні виправдовування чого в них нема стабільного API. Тут головне, шо його нема, а їхні мотиви то вони можуть їх собі засунути туди ж куди й той палець. ;)
Мені байдуже до питання куди цей проєкт рухається. Просто заперечив його "конструкторність". Її немає.

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

До речі, Торвальдс і його палець. Його показувальний потенціал обмежений зверху, знаєте. Адже в цитованому вами луркморі не збрехали згадуючи шо життя в сонячній Калифорнії має оплачуватися. :D Тож якшо ті хто це робе схоче якусь фінтіклюшку, вона буде там. І Лінус її замайнлайнить ніжно. :brovy:
  • 0

#112 kalamar

    Старійшина

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

Відправлено 19.04.2017 – 21:43

Перегляд допису_Ex (19.04.2017 – 19:56) писав:

Це добре, шо ви самі найшли їхні виправдовування чого в них нема стабільного API. Тут головне, шо його нема, а їхні мотиви то вони можуть їх собі засунути туди ж куди й той палець. ;)
Мені байдуже до питання куди цей проєкт рухається. Просто заперечив його "конструкторність". Її немає.
Ви так нічого і не зрозуміли. Це їм байдуже подобається вам, що у них нема стабільного in-kernel API, чи ні. Вам виходить не байдуже, коли ви ввесь час тут про то пишете. Щодо зовнішнього API, то він є і достатньо стабільний. А внутрішній стабільний API цікавить передусім тих, хто хоче писати під Лінукс закриті дрова. Він не потрібен, коли ви маєте доступ до сирців ядра, і пишете відкриті дрова, які згодом ввійдуть в ядро.
Не хочете, не юзайте, вони ж вас не примушують юзати лінукс. Лиш тільки вам доведеться чекати, поки мікрософт портує вінду на той ваш дивайс, бо розробники того дивайсу, не маючи сирців вінди, навряд чи то зроблять.
Саме тому вінда не стане конструктором, бо виробних не маючи доступу до вихідного коду ОС, не може її пристосовувати для своїх потреб, виробнику треба домовлятись з мікрософтом.

Перегляд допису_Ex (19.04.2017 – 19:56) писав:

Мені подобається NT архітектура, я її вивчаю, і свої заняття з нею пов'язую.
Це таке діло, хазяйське. :wink2: Про смаки не сперечаються. Вам подобається, а мені - ні, і все тут.
  • 0

#113 _Ex

    STATUS_OK

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

Відправлено 19.04.2017 – 22:11

Коротка нотатка про розкрій пам'яти в нашій mips машині. Це 2-га версія архітектури, і тут обов'зковими суть два регіони з особлими властивостями. kseg0 і kseg1. Вони обоє по 512 МБ і обоє без участи MMU прямо вказують на фізичну пам'ять. Але не 1:1 а з точністю до адитивної константи, як кажуть фізики.
Взагалі, терміни "віртуальна" і "фізична" адреси дуже неточні і неправильні, вони несуть на собі абсолютно хибні конотації - наче перша "несправжня", а друга "справжня". Це не так, вони обидві справжні, просто вони трохи різне. Того ми називатимемо першу "процесорною" (або "процесною"), а другу - "системною". Не те шоб супер вдало, але набагато краще передає їхню суть. Або скороченнями - перша PAS, друга SAS (process(or) address space, system address space).
Так от, ті два згаданих сегменти ПАС мають дуже пряме відбораження в САС. А саме, для kseg0 це:
kseg0: PAS = SAS + 0x80000000
для kseg1:
kseg1: PAS = SAS + 0xa0000000
І також, важливо - kseg0 може бути кешованим, а може й не бути. А kseg1 ніколи некешований.
Саме за допомогою kseg1 сегмента, ми легко адресуємо відображені в (системну) пам'ять регістри пристроїв.
як оцево:
/* reset DLL in PHY */
	la	$s0, CPM_BASE
	li	$t0, (DRCG_DLLRESET | DRCG_CFGCLKEN)	/* 3 */
	sw	$t0, CPM_DRCG($s0)
Оте CPM_BASE, база CPM модуля, - 0xb0000000. Це kseg1 сегмент. Без участи MMU, а значить без TLB, і таблиць сторінок, процесор запитує системну адресу 0x10000000. Див. формулу вище. І шо важливо у випадку писання в регістри пристроїв - цей запит обходить кеші процесора.
Отже використання для В/В вияснене, тут все чітко. Індженик забирає під це верхні 256 МБ з цього системного блоку. З яких 64МБ іде власне регістрам різних пристроїв, а решта - зарезервована або відображена на SRAM і ROM.
Нижні ж 256 МБ (з 0x00000000 по 0x10000000 не включно) системного простору, залишені для SDRAM, для звичайної оперативної пам'яти. Це не мало 256 МБ, чверть від наявного об'єму пам'яти. І от з використанням kseg0 і kseg1 (а це, нагадаю, ядерна частина ПАС, однакова для всіх процесів), ми можемо доступатися цих 256 МБ без трансляції як такої! Але з кешуванням (якшо з kseg0). Це круто, бо і захист є (процеси не можуть попсувати пам'ять інших процесів) і з ядра знімається багато волокіти. Спочатку я думав, шо блок замалий для глобальних речей, а потім до мене нарешті дійшло - та це ж 256 МБ, сюди все ядро влізе з усім блекджеком і панянками.
І це добре. Це зекономить також дуже дефіцитне TLB тут (TLB - translation lookaside buffer - це кеш, який кешує PTE, page table entry - записи таблиць сторінок, які зберігають відображення між ПАС і САС і атрибутику сторінок різну, вони потрібні для перерахунку адреси з ПАС в адресу в САС).
Лише системний кеш ми думаємо винести в kseg3 (точніше в ділянку, яка получається від об'єднання ksseg і kseg3, перша, ksseg, - це ділянка "супервізора", якшо він імплементований, він не імплементований). Бо системний кеш великий, він служить усім, і він може не влізти в 256 МБ. Вся решта ядра, як вже сказано, - сидітиме в kseg0. Круто. А спочатку я думав, шо туди підуть лише якісь спеціальні весчі, як от таблиці сторінок, обробники якісь. Ну от, треба постійно думати і візуалізувати - дуже важливо. Візуалізація дуже допомагає. Це як на папірці множити чи без нього. 2*2 - без папірця швидше, а 21765*137 на папірці швидше.

Отже наша нотатка власне про розкрій ядерної частини ПАС. Вона спільна у всіх процесів. З такою схемою, ядру не потірбне ані TLB, ані трансляція (PAS<->SAS) взагалі (для своїх сторінок). Весь менеджмент пам'яти - це саме облік місця. Вивантажуваний пул, невивантажуваний пул тощо.

Тут ще треба сказати за дві речі. Вони з одного боку полегшують писання системи, але, нажаль, вони означають відсутність важливої функціональности.
Перша спричинена відсутністю придатного для цього діла пристрою на цьому класі машин. Пристрій - це жорсткий диск. А потрібна річ - це пейджинг - сторінкування, важко вигадати термін. Це коли сторінки з ПАС мають "заднє" сховище на постійному носієві. І якшо оперативної пам'яти не вистачає, сторінки викидаються туди. Заднє сховище це або звичайні файли, якшо ці сторінки були відображенням останніх в пам'ять. Або це спеціальний "сторінковий" файл.Так так, pagefile.sys, саме він. В нього ідуть сторінки, які не мають визначеного заднього сховища. Наприклад сторінки стеку процесу. Якшо цей процес довго нічого не робе, навіть його стек з часом повністю викидається в пейдж-файл.
Існує кілька сценаріїв які впливають шо і як буде заднім сховищем для сторінки:
  • Сторінка належить до виконуваного коду чи даних образу програми. На завантаженні, ці сторінки відображаються в пам'ять з виконуваного файла. І їхній файл образу є їхнім заднім сховищем. Але лише ридонлі. Тобто він лише постачає дані в переднє сховище, але не приймає дані звідти. Подумайте, ми не перетираємо виконувані файли програм на диску. Того сторінки коду, наприклад якшо будуть викинуті з пам'яти, а потім знову знадобляться, будуть зчитані з цього файлу. Всі ридонли сторінки так. Копіювальні на писанні сторінки не так, для них цей файл - заднє сховище доки процес не спробував написати в сторінку. Щойно він спробував, йому виділяється інша приватна копія, для якої цей файл уже ясно не може бути заднім сховищем.
  • Програма явно відображає якийсь файл в пам'ять. Якшо не ридонли, то тоді цей файл буде заднім сховищем для таких сторінок. І якшо програма модифікує вміст цих сторінок, вона модифікує сам файл. Писанням в файл займається ОС. Час від часу вона пише ці "брудні" сторінки в відповідні файли, синхронізуючи тим самим вміст обидвох сховищ.
  • Програма має також приватні сторінки - стеки потоків, купи, просто виділена (закомічена) динамічна пам'ять поза купами, скопійовані на писаннях приватні сторінки згадані вище, наприклад попроцесні сторінки даних DLL, чи головного образу програми. якшо їх більше одного виконується. Такі сторінки не мають за собою файлів куди б їх можна було скинути в разі дефіциту ОЗП. Або взагалі не мають як стек чи купа, або туди писати неможна, бо то ридонли джерело (наприклад секція даних виконуваного файлу). Тоді такі сторінки ідуть в сторінковий файл, коли вилітають з оперативної пам'яти.
  • Нарешті, ОС пакращує швидкодію замість процесів, якшо ті лінуються відображати свої файлові дані в пам'ять самі, і продовжують використовувати файлові операції В/В. Тоді система за них відображає ці файли в пам'ять (в ядерну частину ПАС) з розрахунком, шо ці дані обов'язково будуть доступлені ще. Процес наче пише в файл, а насправді воно все робиться в пам'яті. Того й швидко виходить. Це називається системний кеш, згаданий вище, який у нас поки сам один піде в kseg3, - відображуваний (потребує трансляції адрес) сегмент ядерної частини ПАС. А роблять ці фокуси в ядрі разом - Кеш Менеджер, Менеджер Пам'яти і драйвери ФС (файлових систем). Цей останній варіант власне прозорий для програм (хоча всеодно вони можуть впливати і на нього), але він всеодно встановлює і використовує цю дворівневу систему пам'яти з переднім і заднім сховищами.
І от, у нас всього цього тут не може бути. Не може бути сторінкування, дворівневої системи "віртуальної" пам'яти з переднім (ОЗП) і заднім сховищами (ЖД). Бо у нас нема ЖД тут. Вони можуть бути (через USB), але їх поки нема, і на цьому класі машин, їх може часто не бути. Навідміну від ПК, де майже завсіди є ЖД. Нанд, СД і еММЦ не підходять на цю роль з двох причин - вони замалі (наприклад ПК сценарій - ОЗП 2 ГБ, ЖД 320 ГБ, співвідношення 1:160, на міні-ПК, - 1ГБ ОЗП, 8ГБ нанд, співвідношення - 1:8, надто мало). І друга, найголовніша - вони зношуються від частих писань. Сторінкування - це часті писання. Ми не хочем вбивати флеш пам'ять. Того, на цьому класі доведеться відмовитися від такої потужної функціональности. :( Зато роботи менше. :D Того наприклад хоч всеодно у нас буде увесь оцей облік і стани - stand-by, modified, modified-no-write, free, zero, active, це для пам'яти, і це для того, шо на інших це обов'язково знадобиться, але саме тут скидати нікуди. Коротко кажучи - сумарний об'єм віртуальної пам'яти всіх процесів і ядра обмежений саме об'ємом оперативної пам'яти.

І друге, неабияк дратівлива штука. Нажаль, саме на цьому процесорі (бо архітектура хоч і має ці концепції, але не зобов'язує імплементації робити їх обов'язково), немає таких речей як захист сторінок - read-only, execute-inhibit і так далі. нема і все. тож вивантажений образ програми увесь і ціляком - писабельний. :( Балуваний процес може повністю зіпсувати всю свою пам'ять. Це вина хардварі. Знову, це зрізає функціональність, але полегшує імлементацію. І оскільки TLB надзвичайно мале, всього 32 записи, ми змушені укрупнювати сторінки. Замість звичних 4 КБ, які й тут, на міпсі, суть "звичайними", нам доведеться брати шось крупніше - 16, 64, 256 КБ або й 1 і 16 МБ. Само по собі це унеможливлює розділення прав доступу, бо воно ж посторінкове, уявіть, якшо ви грузите виконуваний файл у якого є execute-only секція коду, read-only секція з константами, і read-write секція з даними, ви, вигружаєте це все в одну велику сторінку, і атрибути в неї звичайно одні. Усі ті захисти, над якими ви і компілятор з лінкувальником благоговійно тряслись, ідуть коту під хвіст. Але, знову, на цьому процесорі цього захисту всеодно нема! Того так.
Укрупнюючи ж сторінки, ми зменшуємо частоту промахів TLB.

На підсумок. Ці платформні обмеження трохи засмучують, і також трохи полегшують роботу. Наприклад нам не треба парити мізки таблицями сторінок аж до створення першого користувацього процесу чи роботи системного кешу, яка теж пов'язана переважно з користувацькими процесами. Наше ядро ціляком піде в kseg0 сегмент, десь між адресами 0x80000000 і 0xa0000000. Це ПАС. Не те, шо це буде одна сторінка, але це вже навіть неважливо - цей сегмент процесор адресує напряму. Єдине шо треба - це наявна за ним фізична SDRAM і облік використання простору внутрі ядра. Шо зайнято, шо вільно. Також нема пейджинга. Система буде налаштована відловлювати появу USB жд, якшо такі з'являтимуться, тіке тоді буде пейджинг.

Цитата

А внутрішній стабільний API цікавить передусім тих, хто хоче писати під Лінукс закриті дрова. Він не потрібен, коли ви маєте доступ до сирців ядра, і пишете відкриті дрова, які згодом ввійдуть в ядро.
Це дуже наївна казка, в яку можна повірити лише не маючи з цим ніякого практичного перетину. Треба бути дуже амбіційним, якшо не вживати образливих епітетів шоб думати, шо вихідний код та ще й такий який в лінуксі, - є документацією на апі. і є "правильним" рецептом для навчання як шось робити. Це майже те саме шо сказати - ви хочете летіти на літаку? Ок, ось вам купа глинозему, ідіть виплавте з нього алюмінь, побудуйте з нього літак, навчиться дивлячись на літаки, які пролітають над вашою головою літати, і гайда - більш нічого не потрібне.
Драйверописцю не потрібні сирці ядра. йому потрібна чітка система інтеграції в нього. закони і інструменти. перше - це створене і добре задокументоване стабільне ясне діло АПІ. Друге - це хедери і набір утиліт. Все. Лише кривожопим лінуксоїдам потрібні 10 млн рядків "сирців" ядра, які вони збираються (язиком) читати шоб створити якийсь драйвер. Нюню.

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

  • 0

#114 kalamar

    Старійшина

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

Відправлено 20.04.2017 – 13:01

Перегляд допису_Ex (19.04.2017 – 22:11) писав:

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

Треба бути вкрай наївним, щоб не розуміти принципів стратегії vendor lock.
Ніяка документація вам не допоможе, якщо потрібні суттєві зміни в системі.

Цитата

Драйверописцю не потрібні сирці ядра. йому потрібна чітка система інтеграції в нього. закони і інструменти. перше - це створене і добре задокументоване стабільне ясне діло АПІ. Друге - це хедери і набір утиліт. Все. Лише кривожопим лінуксоїдам потрібні 10 млн рядків "сирців" ядра, які вони збираються (язиком) читати шоб створити якийсь драйвер. Нюню.
Ви вже багато драйверів написали? В вінді так, без стабільного API ні кроку, бо система закрита. В лінуксі драйвера просто стають згодом частиною ядра. Кінцевий звичайний користувач лінукса не ставить драйвера. Це в вінді вам драйвера з інтернетів треба качати, в лінуксі - ні. В Ubuntu 14.04 з якого пишу, є два ліві для ядра драйвера. nvidia, яка автоматично поставилась при інсталяції убунти і автоматично оновлюється (це модуль який включає пропраїтарний блоб, і при оновлені він справді компілюється відносно заголовків ядра, просто все те автоматично відбувається при черговому оновлені системи, користувач про то не знає) :wink2: , і модуль для дуже старого таблету для малювання easypen, підключеного до com порту, який я сам зібрав, знайщовши сирці в git. Шо цікаво, коли я спробував запустити той таблет під віндою, я поставив драйвер який йщов на диску до дивайсу, перезагрузився і ... отримав чорний екран. Прийшлось загружати вінду в безпечному режимі і деінсталювати той старий драйвер, отака фігня. :8:
Ви ж, намагаєтесь запустити дивайс спеціально призначений для навчання, пару років тому, і жалієтесь, що з коробки система не стає на вашу екзотику.

Повідомлення відредагував kalamar: 20.04.2017 – 13:08

  • 0

#115 _Ex

    STATUS_OK

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

Відправлено 20.04.2017 – 15:07

:D Каламаре, це переливання з пустого в порожнє. Для мене той факт, шо в лінукс уже запхнули (шо там - "все в ядрі"), все шо вони там всі понаписували - це великий недолік. Це ознака пурлі девелопед медіокріті. А для вас це вав. Тож всім все ясно.

Ваша оповідь про те як ви за допомогою гіта зробили модуль мені нагадав знову з цитованого вами луркмору (переклад мій):

Цитата

Лінус Торвальдс не натискає кнопку унітаза в туалеті. Він просто каже make mrproper;
:D
Все ж, ви мабуть розумієте різницю між найти репозиторій з вихідними кодами, стягти їх і скомпілювати і написати ті коди і зробити, шоб вони робили?
До речі, за наявности нормального механізму, вам би в тій ситуації з планшетом, було треба просто піти на сайт виробника планшету, скачати драйвер і встановити його. От як я недавно робив з USB-TTL адаптером. Це якшо мета - зробити пристрій функціональним.
Просто для лінуксоїдів скачати модуль з сайта виробника - це не православно. Треба №№№-тися з "сирцями" і конпілірувати, краще за все ядро теж. Бо ж хз, чи те саме "дерево" ядра було в того драйвера чи не те саме. Тобто на яке саме нестабільне апі його створили, шоб жеж пропрієтарники не пролізли. А там - і компілятор теж треба закачати і сконпілірувати, ще один. Версія ж не та! Ото щастя. це ж як причастя, це релігійний досвід, - стати частиною того дивного світу напівбожевільних хіппі гіків. Шо неясно.

Ще раз коротко - відсутність "стабільного" АПІ, робить завдання створення (тестування, ськання :D) драйверів, набагато складнішим, ніж воно могло б бути за наявности справжньої модулярности. В світі, де лише по одному екземпляру Чака Нориса, Лінуса і каламара, такий підхід працює пагано.

Спорю, шо головною справжньою причиною їхнього небажання спробувати так робити - це їхнє внутрішнє відчуття, шо вони з цим змавпують Віндовс. Адже і коню відомо, хто з самого початку так робе, шо драйвери - справді окремі модулі, і в кого є "стабільне апі". Лол. Це так весело.
Бачите, я не сказав, шо вони просто не вміють так зробити. :D

Цитата

Ви вже багато драйверів написали?
Боже упасі, я б не став нічого писати під лінукс, навіть якби й умів. Їхня атмосфера безповоротно відштовхнула мене, такого генія, від їхньої спільноти.
  • 0

#116 kalamar

    Старійшина

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

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

Перегляд допису_Ex (20.04.2017 – 15:07) писав:

Боже упасі, я б не став нічого писати під лінукс, навіть якби й умів. Їхня атмосфера безповоротно відштовхнула мене, такого генія, від їхньої спільноти.
Я не про специфічно лінукс питав. Під вінду ви дока по драйверам?
  • 0

#117 _Ex

    STATUS_OK

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

Відправлено 20.04.2017 – 15:48

Перегляд дописуkalamar (20.04.2017 – 15:15) писав:

Я не про специфічно лінукс питав. Під вінду ви дока по драйверам?
Хочете мені роботу підкинути? :D Це дорого.)))

Ну як я можу про себе казати шо я по драйверах. Ну я вмію дещо.
Ви ж не читали цей блог, я тут описую, шо я роблю, в чому набуваю досвіду, шо вмію.
Короткий опис для вас - от пишу ФВ для згаданої плати. Виставили тактові сигнали, - налаштували PLL тобто. Таймер зробили шоб він тікав. Написали послідовність ініціалізації SDRAM. Але це останнє ще не ганяли. Зараз треба рухатися далі - таки запускати SDRAM ініціалізацію. Якшо робитиме, - читати SD картку. Спочатку сирі перші сектори, трохи далі - FAT, принаймні кореневу папку, шоб завантажити кілька файлів - зародок нашого ядра, HAL, SYSTEM вулик реєстру - шоб звідти витягти список бут драйверів, які теж треба завантажити.
Це як? Драйвери? І так і ні. Шось з цього вже є, початки, чогось ще нема. Я слідую NT підходу, тобто грубо кажучи, воно робе "так як в Вінді". Ну це дуууже нескромно звичайно. Власне зараз, я створюю завантажувальну послідовність для майбутнього ядра. Тобто пишу "голий" бутлодарь (незалежний від UEFI сервісів, які хоч частково й написані, але ще неінтеґровані . А заодно SEC фазу ФВ пишу, зараз вона тягне на 1.08 КБ гологу коду (~256 інструкцій), з додаванням ініціалізації SDRAM, - подвоїться. виявилось, шо саме так - розпаралеливши треба робити. І ФВ, і ОС. Шоб же не забути оці всі щойно вияснені тонкощі. От наприклад таймер - він чогось не оновлював лічильник, хоча все було зроблено по мануалу. Потім я додав окремою операцією виставляння одного флажка, який власне в нашому випадку покишо і не потрібен. Але таймер почав рахувати! Тож треба це вписати і в HAL, а не лише в фірмварну SEC фазу, поки не забув. :D Спочатку я думав, шо треба написати ФВ, і лише потім братися за ОС. Тепер це робиться паралельно. HAL - це теж драйвер - таймерів, RTC, контроллера переривань, також це енумератор всіх основних контроллерів, багато всяких. Ну ті ж UART'и, USB (OHCI, EHCI), SD, NAND, LCD, HDMI. і тд. Нема PCIe, нема нормальної перелічуваности - HAL має робити важку роботу конструювання дерева пристроїв, перелічувати всіх цих непутьових своїх дітей. Я працюю над цим прямо зараз. Ну "працюю", мені за це ніхто не плате, того - займаюсь. :) Робочого коду, а не просто надуманого та/або написаного - покишо лише отой бінарник SEC фази. Його мало, але він робе! Це BIOS якшо хочете. Тож покишо мої практичні набутки - я написав примітивний BIOS на mips-машину. :)
Але це та ділянка в системному програмуванні, в якій я шось роблю, шось получається, значить шось вмію.
Тобто якшо ви хочете замовити мені драйвер під Віндовс чогось там, давайте, я не проти підзаробити. :D Заодно тренування для проєкту.

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

  • 0

#118 _Ex

    STATUS_OK

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

Відправлено 26.04.2017 – 16:49

Оскільки для нашого проєкту будуть потрібні в різних місцях AVL-дерева, червоно-чорні дерева і сплей лерева, засіли ми посилювати наші програміздські вміння в галузі структур даних і алгоритмів. :D
Ось треба пригадувати те недоучене про двійкові дерева пошуку, зокрема ітеративні варіанти операцій на них (які швидші за значно зрозуміліші рекусривні). Цілий день намагався вигадати ітеративний алгоритм обходу ДДП, без використання допоміжного стеку. Всьо за завданням!
Ну нарешті шось вигадав, не підглядаючи нікуди, звичайно. :D Не знаю чи робе воно чи нє, ще не перевіряв. Зацініть, це C-подібний псевдокод
L(x) - вертає ліву дитину, R(x) - праву, P(x) - батька, K(x) - ключ, NIL - це пустий елемент.
void Traversal(x){
		while(L(x) != NIL)x=L(x);//find first element, the smallest one
		while(x != NIL){
				print(K(x));	//element is found, payload
									//find next routine
				if(R(x) != NIL){	   //we either have a right subtree, then move to it and there - find its smallest element
						x=R(x);
						while(L(x) != NIL)x = L(x);
			}else{		//or, there is no right subtree below, then move upwards until the node y is a left child or the root
				do{
					y=x;
					x=P(x);
				}while(x && y==R(x));
							//here, x either is the next in order element found or NIL which is an end of the loop
			}
}
		return;
}
Ось рекурсивний варіант цього ж обходу (по порядку):
void RecTraversal(x){
		if(x != NIL){
				RecTraversal(L(x));
				print(K(x));
				RecTraversal(R(x));
		}

		return;
}

Боже, цей веб ніколи не навчиться працювати з відступами. Навіть пробільними, шо там вже казати за табуляцію.

Яка ідея нашого обходу? Обхід це лінійна операція по числу елементів. В найшвидшому варіанті масиву чи списку, ви просто проходите від початку до кінця, легко знаходячи наступний елемент. Він або фізично наступний (масив), або ви маєте на руках вказівник на нього (список). В дереві не так. Якшо звичайно ви не зробите його threaded - тобто не додасте ще два поля (і трохи роботи), які робитимуть точно так як в списках - вказуватимуть на наступний (і попередній) (за величиною) елементи. От наша ідея була відтворити цей прохід для дерев. Тобто розбити алгоритм на корисну роботу (друк) і пошук наступного елемента. Щоітерації, на кожному вузлі, після друку його ключа, нам треба знайти його наступний елемент. Оточенням кожного вузла є - його ліве піддерево, праве піддерево і батько. Також елемент може бути або лівою дитиною, або правою (термінологія в деревах психоделічна). Для висхідного обходу, ну тобто від найменшого до найбільшого, ліве піддерево ніколи не може бути наступним для елемента, так само як і батько, якшо наш вузол - права дитина. Тобто для кожного вузла наступним має бути праве піддерево. Якшо воно є. Хай воно є. Тоді, це ще не все. Все дерево - точно наступне, але який саме елемент в ньому - наступний? Саме з точністю до елемента треба визначитись. От, очевидно, шо тут те саме, шо й на початку для всього дерева, - наступним в (під)дереві є його найменший елемент. Найшовши його, ми найшли, шо шукали, - ідемо в наступну ітерацію, на початок циклу. Якшо правого піддерева нема, то тоді, алгоритму пошуку наступного елемента треба підніматися вгору по предках, пропускаючи всі випадки, коли поточний елемент є правою дитиною. Чого? Та того шо якшо батько є зліва, його елемент є небільшим ніж дитячого, і точно є попереднім в порядку, і він уже надрукований. А якшо син є лівим нащадком, значить, його батько є наступним за величною елементом (якшо праве піддерево елемента вже враховане, а воно враховане, бо ми зайшли сюди, в піднімання по предках, лише після обходу правого піддерева, лише наштовхнувшись там на листя, на край). От так ми підніматимемось вгору аж допоки не знайдемо предка який зліва. Або, якшо нарешті доходимо краю обходу, - ми не знайдемо наступного елемента взагалі, але наштовхнемось на нульового предка - у кореня і лише в нього, предок - нуль, нема предка, на те він і корінь. І це - чиста як роса ознака, шо роботу зроблено. І шо алгоритм ніколи не зациклиться до речі.
Цілий день думав. :lol:

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

  • 0

#119 _Ex

    STATUS_OK

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

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

Все ж ми вирішили повернутися до ідеї ввімкнути обробку переривань перед ініціалізацію пам'яти.
Практично це б давало нам можливість робити правильний необтяжливий для машини процес чекання, довгого чекання на етапах, коли DDR PHY робе всі свої внутрішні речі - тренування і різну ініціалізацію - існує принаймні два місця в його послідовності, де треба чекати. І два, раніше, в послідовності для DDRC, по 400 мс кожна. убут робе busy wait. В 400 мс-них зупинках, він активно крутиться читаючи таймер, доки той не натікає потрібний інтервал, а в випадку з DDR PHY, він взагалі круте лічильник в циклі, 20000 разів наче в першому випадку, щоразу читаючи потрібний регістр PHY, а другий раз взагалі - 500000 (п'ятсот тисяч!11); і завісює систему, якшо так потрібні флажки не виставились. От побачивши цю цифру 500000 холостих ітерацій, я таки рішив повернутися до ідеї ввімкнути обробку переривань до ініціалізації пам'яти, і чекати в idle'і. Нам же всеодно треба ця обробка далі, чого ж не вставити її тут, де вона теж потрібна?
Покишо в наших планах є включити interrupt-driven модель взаємодії з периферійними пристроями і в UEFI, хоча остання і декларує, шо треба опитувати пристрої, робити polling. Але це тупо і дуже неефективно. Хоча й простіше. І шо найголовніше, думається нам, такі речі не мали б диктуватися стандартом, це внутрішня імплементація, якшо я можу й хочу обслуговувати перериваннями, чого ні? Головне - надати функціональність, а як, - то вже питання внутрішнє, чи не так? Невідомо як ця модель впишеться в UEFI, але хай там як, саме ця і лише ця модель має бути розгорнута в ОС; тож ми всеодно не робимо намарно. До речі, аналізуючи UEFI в ділянці TPL - task priority levels - рівнів пріоритету завдань, неважко помітити, шо там існує така собі ляга, залишена для обробки переривань - є діапазон TPL, невизначений, зарезервований для самої ФВ, який є вище, ніж звичайні рівні, і специфікація так пространно балакає, шо наче як да, тут хтось колись думав це використовувати для переривань. Просто очевидно спростили, задекларувавши polling. Хоча і переривання ввімкнути не заборонили. Коротше, ми намагатимемося робити взаємодію з пристроями за допомогою керованої перериваннями моделі.

Як воно робе на міпсі?
Існують винятки й переривання. Якісь з них можуть бути синхронними, якісь асинхронними. Перші виникають як наслідок виконання якоїсь інструкції, і підчас його, виконання. Другі або взагалі не пов'язані з виконанням поточної інструкції, або виявляються вже після завершення виконання інструкції, яка їх викликала. Ділення на нуль, TLB промах - типові синхронні винятки. Залізні переривання - типові асинхронні події. Є також архітектурно кілька винятків, які ми не можемо обробляти - їхні вектори вшиті вендором в ROM ділянку. Це Reset, Soft Reset, NMI, і якась невідома фігня, пов'язана з EJTAG. Ресет, м'який ресет і нонмаскабле інтеррупт - ми не впливаємо на це. На ресетах, ром-код робе свою роботу, робе він там мало, навіть нічого не пише в послідовний порт і одразу грузе нас і передає нам керування - це старт машини. За NMI я ще нічого толком сказати не можу. Вони тут згадані для повноти картини, вони суть поза механізмом ОВ (обробки винятків).
Власне винятки - це туман туман. :otruta: Їх багато і за них розкажу пізніше. Є ясні як день хоча :summer:- пов'язані з TLB наприклад, це міпсівські page-fault пов'язані речі.
Якшо іде запит на маповану ділянку ПАП (це не те, шо ви подумали, це мій пакращений термін для віртуального адресного простору - процес(ор)ний адресний простір, казав уже за це), то процесор завсіди дивиться в TLB чи є там інфа за трансляцію цієї адреси. На міпсі так - на міпсах, на яких імплементоване TLB MMU, трансляція існує завсіди, не треба і не можливо нічого вмикати чи запускати, ніякого identity mapping'а, ніякої сегментної адресації без пейджинга, одразу ПАП-САП трансляція. Але, як уже казано, існують немаповані або ще й некешовані сегменти, неймлі - kseg1 є такий (ділянка ПАП від 0xa0000000 до 0xc0000000 не включно). kseg0 теж немапований, але кешований. kuseg (юзерський простір 0-0x80000000 не включно) теж може бути немапованонекешованим в спеціальних випадках, а саме - на винятках кешу. Тож, якшо запису трансляції нема в TLB, процесор ґенерує TLB промах. Менеджер пам'яти нашої ОС має надати обробник цього і інших споріднених винятків, в якому він має "принести" цю сторінку в пам'ять, і залити TLB відповідним записом. Процесор потім ретрає (retry) впалу інструкцію, яка тепер щасливо отримує свої дані. Це може бути твердий, м'який пейдж фолт, або просто в TLB не було запису - воно дуже мале і вмістити всі PTE (запис таблиці сторінок, який держе інфу за ПАП-САП трансляцію) не може, тож навіть гожа сторінка може спричинити такий виняток. Шоб ви мали уявлення - в нашому процесорі, TLB має 32 записи. Пам'яти в нас 1ГБ. Якшо взяти такий звичний для x86 варіант 4 КБ-них сторінок, то кількість PTE потрібна, шоб описати всі ці сторінки, дорівнюватиме - 262 144 штук. А в нас тіке 32 записи. І навіть якшо впасти в іншу крайність і використовувати найбільшу сторінку (це зменшить кількість сторінок, а значить - кількість PTE), яка на нашому процесорі є 16 МБ, всеодно вийде 64 сторінки. Але такий сценарій практично неможливий, подумайте, 16 МБ-ні сторінки не дадуть нічого зробити іншого корисного. Марнування дорогоцінної оперативної пам'яти зашкалює. Наш внутрішній цензор негодує.
Але ми використовуватимемо ці й інші сторінки, там де це дає вигоду. Загалом через такий значний брак в ємності TLB, наш менеджер пам'яти має возитися з сторінками багатьох розмірів.

Інші винятки звучать устрашаюшшє, і толком ще не ясно шо там робити. Наприклад є таке machine check виняток. Бобік здох виняток. Раніше, наявність ідентичиних трансляцій в TLB могла викликати фізичне пошкодження TLB, :o тепер такого ужаснаха нема, але якшо якимсь дивом в TLB опиниться колізія, процесор викидає machine check виняток. Це аналог Віндового bug check'а, який в простолюдді називають тупувато BSOD. Всередині, він називається bug check, і робе його функція KeBugCheckEx() якшо я не помиляюсь.
Існують винятки пов'язані з арифметичним переповненням, з діленням на нуль, з плаваючими числами. Винятки кеша, аборти на даних, аборти на префетчах - витяганнях наступних інструкцій. Ськальні винятки, xD їх так багато, так багато всіх. Покишо ми переважно ігноруємо їх, ото й уся обробка. :D
Наша ціль - переривання.
Тут міпс має 3 варіації - режим сумісности - це для сумісности з релізом 1. У нас - реліз 2. Цей режим робе на старті, ми його можемо використовувати, але не будемо. Просто того, шо маємо інший, молодьожніший. Це другий режим - векторизовані переривання. Наш проц його вміє. Третій - найкрутіший, EIC - external interrupt controller режим, там багато "опцій", і він покладає завдання на пріоритетизацію переривань на зовнішній контроллер переривань. Найпросунутіша модель, і в нашому SoC'у є такий сякий контроллер переривань, але, чогось, цей режим неімплементований на нашому процесорі. Того за це колись, не зараз. Зараз за VInt - режим векторизованих переривань.
Взагалі, існує купа рівнів ієрархії, де переривання мають своє місце і мають бути керовані. Наприклад - це рівень пристрою, який ґенерує переривання. Там ви можете замаскувати переривання, там ви їх оброблятимете. Функціональний драйвер оброблятиме. Далі, є системний рівень - контроллер переривань, спеціальний пристрій, який керує перериваннями на системному рівні, робе багато чого з ними, збирає їх на себе, і, зрештою, направляє якомусь процесору. І нарешті є рівень процесора - він має свої механізми, як його можна переривати ззовні. Саме сюди контроллер переривань направляє свої запити. Може бути ще шось між цим головним. Наприклад пари IOAPIC-LAPIC (SAPIC), на x86 чи Itanium'ах. Або у нас, є ще якийсь незадокументований :angry: "арбітр", який сидить між контроллером переривань (INTC) і процесорами і керує IPI (міжпроцесорні переривання) і направлянням переривань від таймера чи всієї решти від INTC.
Так от ми зараз за процесорний рівень. В випадку ВП (векторизованих переривань), які ми збираємося імплементувати, схема така.
Процесор має 8 ліній, виділених для переривань (арм наприклад має 2). 6 іде для хардварних переривань, 2 для софтварних. Яка приємна несподіванка - адже NT якраз має два софтварних IRQL'а, APC і DPC. :cool2: Це той максимум який архітектура надає. Кожній лінії відповідає пара бітів в двох регістрах, а саме - в STATUS і CAUSE регістрах. Одна група репрезентує стан лінії (asserted чи ні, тобто є переривання чи нема), друга - маскує відповідне переривання, якшо біт виставлений. Одразу скажемо, в разі EIC режиму, ці ж поля трактуються як RIPL - requested interrupt priority level. Оцей RIPL - це повний аналог NT-шного IRQL. В цьому режимі його підтримкою займається КП (контроллер переривань). А у нас, в ВП режимі, цим займається процесор. В режимі сумісности, а також в певних ситуаціях в усіх режимах, цим займається диспетчер переривань і винятків нашої ОС. Навідміну від EIC режиму, де разом з двома полями для софтварних переривань, виходе аж 256 рівнів, тут ці біти не трактуються як одне число (яке одночасно каже рівень пріоритету, шо означає, шо якісь переривання замасковані, а якісь, які вищі за пріоритетом ні, і задає зміщення на обробник), а ідуть самі по собі як окремі сигнали для своєї групи. І отже 8 переривань. 6 хардварних. От, базуючись на тому, який саме біт виставлений, враховуючи пріоритет IP[n] > IP[n-1], ці поля називаються IP в цьому режимі, декодер векторизації ґенерує зміщення куди треба стрибнути для обробки, вектор ґенерує тобто. А там, ми надаємо наших диспетчерів. Їх кілька саме чере векторизацію. У випадку EIC, диспетчери б були непотрібні, і в потрібне місце треба було вже писати сам обробник. В ідеалі. Але тепер кожен диспетчер має робити менше переборів виясняючи, хто саме викликав переривання, отже робота робиться швидше. Плюс цей режим іде з таким смаколиком як тіньові набори регістрів, шо знімає потребу в збергіанні "простих" регістрів, - регістрів, якими користувався перерваний код, в диспетчері - це неабияке пришвидчення. Треба правда ще взнати чи індженик розщедрився на це - опція не обов'язкова. Офсет на вектор рахується просто - кожен IP біт представляє число від нуля до семи, отже це й номер вектора. Потім, ми задаємо VS, spacing, - прогалину між векторами, вона не може бути нуль в векторизованому випадку. І офсет тоді вираховується за формулою:
offset = 0x200 + VecNum * VS;
Потім це нарешті додається до EBase - базова адреса (база) обробників винятків, і виходить Дід Денис адреса обробника.
Векторизована вона того, шо теоретично є 8 груп переривань, які матимуть кожен свій диспетчер. Навідміну від режиму сумнісности, де обробка всх переривань починається на офсеті 0x200 і диспетчер один на всіх. А якшо CAUSE.IV поле невиставлене - то на 0x180, разом з винятками. (Окрім TLB Refill, який має свій окремий офсет 0). Знову - в EIC диспетчерів нема взагалі, самі обробники.
Нажаль, схоже Індженик не скористався на повну потужність цим, не розбив усі 64 максимум переривання на 6 груп пріоритетів і не розніс це на ці лінії. Він виніс усі хардварні переривання від INTC, всі крім ОС таймера, в одну лінію. Більше того, він взагалі вирішив використовувати лише три з шести. Одну як ми вже сказали - для всіх переривань, іншу для ОС таймера, і ще одну для IPI, для взаємодії між процесорами. Гірше, він нашось продублював сигнал від таймера змішавши його з "загальним" сигналом від INTC. Тепер переривання від таймера приходитиме і на лінію IP[2] і на лінію IP[4]. :wacko: Цікаво і те, шо воно ж може бути рапортоване і через INTC, той точно має поля для цього. Хех, це зрізає потужність векторизації. Але принаймні в нас, хоч і з кашою, рознесені три групи переривань за допмогою цього рівня - переривання від таймера - має свою лінію, міжпроцесорні переривання (IPI) - мають свою, і нарешті, всі інші - свою. Це відповідно IP[4], IP[3] і IP[2]. І це ж порядок за пріоритетом. Цікаво шо тут ПТ (переривання від таймера) має вищий пріоритет, ніж IPI. Наскільки я пам'ятаю, на x86 навпаки. Ну хз, навряд це так принципово.

Тобто ми як наслідок матимемо 3 різні диспетчери. Точніше 2 обробники (для ТП і IPI), і одного диспетчера для всіх інших. Диспетчер ще має вияснити якому саме обробнику треба передати. Джерел у нього максимум 64, але не всі використані. Це власне вже рівень INTC. За нього пізніше. Єдине тут треба одразу згадати, у нас нема ланцюжків обробників. Це вимушена міра, коли ліній від КП мало і деякі пристрої змушені розділяти їх між собою. Тут джерел всім вистачило, тож ланцюгування немає. Є ще така штука як пристрої, які мають більше одного переривання. І хоча ланцюгування могло б обслуговувати це, воно невиправдане. Бо на відміну від розділення лінії, де різні пристрої вимушені ділити лінію, тут лінію ділять переривання від того самого пристрою, це дуже принципова різниця - обробники для всіх цих переривань має постачити той самий драйвер (або та сама група драйверів) і лише вони знають внутрішню семантику і значить мають робити внутрішню маршрутизацію. Це просто буде найшвидше. Ніж вертати диспетчеру, шоб той знову викликав якусь іншу функцію, яку всеодно надає той самий драйвер. Це вже рівень пристрою в ієрархії обробки переривань. Там у кожного пристрою - свої закони. І свої обробники - функціоанльні драйвери пристроїв.

Ось це ми маємо налаштувати на роботу якшо хочемо робити пасивне чекання. З одного боку - це забагато, а з іншого, нам треба лише повнофункціональна обробка переривання від таймера. Винятки покишо просто ігноруватимемо, надіючись, шо їх просто не ставатиметься, xD міжпроцесні переривання покишо спатимуть, - у нас ще не запущений другий процесор, а вся решта переривань - вони просто замасковані.
Тут є ще один нюанс. Процесор або має архітектурно визначену базу для винятків і у нас вона іде в ROM ділянку і ми не можемо її контролювати, або програміст задає її пишучи в EBase регістр. Але тут і є нюанс, шоб не було ситуацій, коли обробник опиняється в faulted ділянці пам'яти, коли спроба виконати обробник ґенеруватиме нові винятки, архітектура форсує позицію бази так, шоб вона завсіди була в некешованонмапованому регіоні, тобто в kseg1 (або в kseg0). Робиться це форсуванням двох старших бітів в EBase в 1 і 0 відповідно. Шо дає адресу, яка починається з 0x8 і закінчуюється 0xb, тобто не може бути ані в kuseg, ані в kseg3. Бо обидва маповані. Логічно. Але у нас лише недоступна РОМ ділянка попадає в 0xb1c00000 точно число не пам'ятаю, це неважливо. Вся решта kseg1 хоч і доступна без мапування, але вказує вона на ... правильно - SDRAM. Яку ми ще не ініціалізували. Упсі. Тож,вся ця красива пісня була б неможлива, і ініціалізація пам'яти мусила б, крутити бізі вейти там, де ми хочемо idle. Ми ж сидимо поки не SDRAM, а в TCSM. Індженик зробив нам халепу не відобразивши її на kseg0/kseg1. Сам зробив і сам же її виправив. Він вигадав dirty hack у горішній частині kseg3, і додав туди (в діапазоні від 0xf4000000 по 0xf5000000 не включно) свій невідомоякмапований регіон. Він просто працює. Ніхто не знає як. Бо ніде ненаписано. Нема ані відповідних TLB записів, нічого, просто ПА працює в обидва напрямки - і як процесорна адреса, і як системна. Але от бачите, наша база обробників в TCSM не може бути записана в EBase, через нульовий біт 30 (у адреси f4000000 цей біт одиниця). І от, Індженик, дав нам вихід - в регістрі Config7, одному з тих, залишених архітектурою на розсуд вендорів, є таке 1-бітне поле CFG_E30; його промовиста назва натякає, шо його виставляння дозволяє, виставити біт 30 в EBase. То ж це - спонсор нашої задумки. :D Цікаво відзначити, шо архітектура дозволяє втілити т.зв. write gate, в біті 11, інакше зарезервованому, виставляння якого має той самий ефект. Але Індженик не шукає легких шляхів. :D
Пізніше я розкажу, як за допомогою переривання, ми робимо очікування в idle. Бо вже сили нема писати. :D

Повідомлення відредагував _Ex: 27.04.2017 – 23:33

  • 0

#120 _Ex

    STATUS_OK

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

Відправлено 10.05.2017 – 20:23

Хвилинка гумору, цитата з Індженикового мануалу:

Цитата

The Clock & Power management block consists of three parts: Clock control, PLL control, and Power control, Reset control.
:D
  • 0



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

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


Магазин кубиков Рубика Cubes.in.ua