APIC

Internal structure and you change requests/suggestions
  • Точно нет - в бутблоке ни слова об APIC, сейчас посмотрел
  • yogev_ezra

    Другими словами биос назначает линии irq по своему разумению в расчёте на старый добрый 8259A и записывает номера в конфигурационное пространство PCI, регистр 0x3C. Для перехода в режим APIC диспетчер устройств по таблицам ACPI или MP определяет как там всё на самом деле припаяно/сконфигурировано и переписывает значения в регистрах 0x3Ch. С точки зрения драйверописателя ничего не меняется. Он как брал номер irq из 0x3Ch, так и дальше это делает.

    Моя идея: запускаем специальную утилиту и создаём файл с данными pci устройств. Ядро при инициализации грузит этот файл и по нему патчит 0x3Ch. В худшем случае создаём файл ручками. Заодно используем этот файл как диспетчер устройств для бедных, чтобы не сканировать каждый раз шину при поиске устройств.
  • Serge wrote:Моя идея: запускаем специальную утилиту и создаём файл с данными pci устройств. Ядро при инициализации грузит этот файл и по нему патчит 0x3Ch. В худшем случае создаём файл ручками. Заодно используем этот файл как диспетчер устройств для бедных, чтобы не сканировать каждый раз шину при поиске устройств.
    где то так думал, но не совсем...
    В моей концепции типа это сидит в "ступень 1" разворота и инита ядра ОС.
    Т.е. "ступень 1" тест и анализ железа в RM.
    Слово boot тут ни причем. Ядро уже в памяти.
    Юзается все что по BIOSу можно вынюхать + прямые методы работы с портами и... типа патчинг всякого добра. Не исключен unreal в этом этапе, как временная мера, дабы в РМ скажем, не схлопотать "вилы в бок".
    Наличие файла или доп утилиты - не вижу смысла. Железо все равно у всех разное. А вот механизм патчинга или развешивания важных вещех перед тем как сигануть в PM, весьма необходим, как предстартовая подготовка ракеты. Типа, чтобы не было "поздно пить Баржоми!"
    Интеллектуально продернуть ВСЕ IRQ, которые собираешься юзать в системе, перед тем , как "навесить" нужный драйвер на них в "ступени 2" (или запретить это), на уже проверенный IRQ известного устройства, это считаю верным подходом.
    Сканировать шину - мизер. Страха не вижу тут или опасения.

    Я так понимаю твоя основная фича пропатчить "правильно" PCI cfg offset 0x3Ch нужными номерами свыше 16, так?

    К стати по сабжу вещица подумать неплохая
  • У меня более реалистичное предложение: использовать live-версию Линукса как базовый инсталлятор Колибри.
    Помимо всяких прочих штучек, таких как
    - конфигурирование загрузчика,
    - установка системы на выбранный раздел диска,
    - установка подходящих драйверов,
    - условная компиляция ядра в соответствии с платформой,
    - и многое другое,
    мы сможем
    - использовать мощный линуксовский энумератор, и
    - не париться с собственной конфигурацией устройств, а просто записать нужную информацию из /sys/bus/pci/devices в файл kolibri.ini.

    А потом при старте Колибри каждый раз тупо грузить конфиг-регистры прямо из этого файла.
    Все лучше чем вручную, и собственный велосипед изобретать не надо. И код инициализации получается очень компактный.

    Я никогда не пробовал собирать собственные live-Linux системы, но слышал, что это не очень сложно.
    У кого-нибудь есть опыт в этом деле?
    Last edited by art_zh on Wed Jun 15, 2011 12:23 pm, edited 1 time in total.
  • yogev_ezra, тебя жестоко развели. APIC - вещь полезная, но полезная в основном для многопроцессорности, а к USB не имеет ни малейшего отношения. Драйверу USB совершенно безразлично, есть APIC или нет, ему важно только правильно установить обработчик прерывания - сама по себе эта установка может зависеть от используемого контроллера прерываний, но это дело совсем другой части ядра. Без APIC драйвер будет замечательно работать как минимум на 99% систем - я, собственно, сильно сомневаюсь в существовании оставшегося 1%.
    Сделаем мир лучше!
  • art_zh
    Я использую Linux и дома и на работе - так что мое мнение не предвзято, однако если уж брать Linux, но нафиг Колибри вообще? Это еще один шаг к какому-нибудь Puppy Linux. А так к костылям Колибри приставим костыли Linux и по мнению отдельных людей все будет зашибись, а по мнению других нет. Я понимаю желание побыстрей и попроще сделать, чтобы не париться (я и сам тот еще лентяй), но никак не могу равнодушно соглашаться с подобным "развитием".

    CleverMouse
    Интересная у тебя позиция. (Википедия рулит?) А то что на большинстве современных систем USB контроллеры посажены на прерывание выше 16-го получается ненормальным явлением? А повешены они туда отнюдь не просто так, а чтобы было место куда посадить другие устройства, которые выше 16-го садиться не хотят.

    З.Ы. У меня были ситуации когда приходилось переустанавливать Виндовс, потому что APIC был отключен в BIOS и устройства никак не развешивались все.
  • Mario, у меня появились два вопроса.
    1. Ты в курсе, что прерывания PCI разделяемые? На одном прерывании могут нормально работать несколько устройств.
    2. Когда ты говорил, что существуют системы, где APIC необходим, потому что контроллер USB висит на прерывании выше 15-го, ты имел в виду, что так настроила BIOS или это результат перенастройки Linux/Windows? Я начинаю подозревать, что второе, а тогда я снимаю своё замечание про 1% - работать будет везде. Зачем они перенастраивают, это отдельный вопрос, я хочу сначала услышать ответы на эти два.
    Сделаем мир лучше!
  • CleverMouse
    1. Да, в курсе. Однако есть устройства которые не позволяют так работать и почему-то в больших системах стараются не вешать два устройства на одно прерывание.
    2. Я не видел ни один BIOS который настраивает выше 16-го прерывания, зато видел много раз как BIOS оставляет USB контроллеры без прерывания (если судить по табличке которую сам же BIOS выводит). Еще я могу работать только с информацией которая мне доступна - так что да, мое замечание относиться к распределению прерываний в больших и устоявшихся системах. Ни разу не наблюдал, что имея APIC его не использовали.
  • Хорошо.
    1. Разделяемость прерываний прописана в стандарте PCI. К legacy-устройствам, типа того же таймера и PS/2, это не относится, но таких фиксированное число и больше не делают. Большие системы стараются разбивать прерывания от разных устройств на разные вектора по следующей причине. Когда два устройства висят на одном прерывании, то обработчик прерывания вынужден опрашивать оба устройства на предмет, кто из них сгенерировал прерывание, и в результате получаются лишние дёргания шины и мирно работающего без прерываний устройства - это довольно малый вклад, но логика здесь "если можно избавиться, то почему бы не избавиться". У нас ситуация другая - квалифицированных рабочих рук мало, так что лучше делать то, что даёт заметный результат, а не примочками.
    2. Ненастроенное прерывание - это более реально, да. Но тут уже APIC ни при чём.

    Информацию о том, что настроила BIOS - а не Windows/Linux - можно спокойно почерпнуть из pcidev в Kolibri.
    Сделаем мир лучше!
  • Вот статья очень хорошо и понятно описывающая ситуацию - на русском языке.
    Страдания по IRQ

    Нашел первым же результатом в Гугле по запросу "два устройства на одном прерывании".
  • Mario, ты действительно считаешь слова "Если два устройства находятся на одной линии прерываний, то драйвер может их спутать и переслать исполняемый кусок программы не той «железке», при этом заставляя ее исполнить этот кусок кода." - это цитата из документа по приведённой тобой ссылке - разумными?
    Я ещё раз повторю: Разделяемость прерываний прописана в стандарте PCI. К legacy-устройствам, типа того же таймера и PS/2, это не относится, но таких фиксированное число и больше не делают. USB-контроллеры вообще-то располагаются на шине PCI.
    Сделаем мир лучше!
  • Mario,
    Ты не понял, я не предлагаю "брать Линукс", я хочу сделать удобный и универсальный инсталлятор для Колибри.
    Такую же мысль высказал VaStaNi чуть раньше, но он имел в виду разработку собственного инсталлятора с нуля - это нереально сложная задача.
    Но почему бы не воспользоваться чужими инструментами, чтобы сконфигурировать свои?
    На "территориальной целостности и суверенитете" Колибри это никак не скажется, зато позволит проводить автоматическую тонкую настройку тех систем, для которых сейчас надо все допиливать вручную.

    Мы же пользуемся некошерным mtldr? или GRUB? А это - совершенно чужеродные средства, без которых КОС не может даже нормально стартовать.
    А инсталлятор и энумератор нужны только один раз. Потом система будет спокойно обходиться без них. Так почему бы их не объединить, пусть даже и на чужой платформе?

    Напомню, что полноценная ОС вовсе не обязана уметь сама себя инсталлировать - винда вплоть до 2000-х годов не могла устанавливаться без помощи MS-DOS
  • Я гентушник. Могу собрать такой образ. Да, это действительно имеет смысл. Много специфичного софта грузиться с лайв линукса. Во всяком случае, пока нет другой альтернативы. Попробую заняться на выходных.
  • CleverMouse
    Тем не менее проблема существует. Если ты уверена что твое решение будет работать - ну не мне указывать, но выразить свое мнение - я считаю имел право. В общем как всегда "Мнение пишущего код более авторитетно мнения всех остальных" (смахивает на то как работают прерывания).

    art_zh
    А случай когда вставляется новая плата в слот системной шины - я понимаю что сейчас не самый актуальный пример, но оперативность теряется.
    Мы же пользуемся некошерным mtldr? или GRUB? А это - совершенно чужеродные средства, без которых КОС не может даже нормально загрузиться.
    Не показатель - они не влияют на режимы работы.
    Напомню, что полноценная ОС вовсе не обязана уметь сама себя инсталлировать - винда вплоть до 2000-х годов не могла устанавливаться без помощи MS-DOS
    Это как раз показатель неполноценности. Винда и была надстройкой.
  • Who is online

    Users browsing this forum: No registered users and 10 guests