Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Sep 21, 2019 6:46 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 167 posts ]  Go to page Previous 13 4 5 6 712 Next
Author Message
 Post subject: Re: APIC
PostPosted: Tue Jun 14, 2011 2:48 pm 
Offline
Public Relations
User avatar

Joined: Mon Jun 07, 2010 12:01 pm
Posts: 1879
Serge wrote:
Это надо смотреть в Win или Линукс. Биос всегда стартует в PIC режиме для совместимости с DOS. Номер линии в конфигурационном пространстве записывается Биос (кстати не всегда) и на работу оборудования не влияет, только чтобы программисту было проще. Линукс после загрузки патчит эти номера в зависимости от режима PIC/APIC.
Извини, ниасилил :oops:
Serge wrote:
А APIC в eBox есть ?
Судя по всему, нет. Linux пишет:
Code:
No local APIC present or hardware disabled
Local APIC not detected. Using dummy APIC emulation.


Top
   
 Post subject: Re: APIC
PostPosted: Tue Jun 14, 2011 3:20 pm 
Offline
User avatar

Joined: Tue Aug 25, 2009 4:45 pm
Posts: 794
Точно нет - в бутблоке ни слова об APIC, сейчас посмотрел


Top
   
 Post subject: Re: APIC
PostPosted: Tue Jun 14, 2011 3:56 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
yogev_ezra

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

Моя идея: запускаем специальную утилиту и создаём файл с данными pci устройств. Ядро при инициализации грузит этот файл и по нему патчит 0x3Ch. В худшем случае создаём файл ручками. Заодно используем этот файл как диспетчер устройств для бедных, чтобы не сканировать каждый раз шину при поиске устройств.


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 11:12 am 
Offline
Just Flooding
User avatar

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

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

К стати по сабжу вещица подумать неплохая


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 12:16 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
У меня более реалистичное предложение: использовать 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.

Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 12:22 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1620
yogev_ezra, тебя жестоко развели. APIC - вещь полезная, но полезная в основном для многопроцессорности, а к USB не имеет ни малейшего отношения. Драйверу USB совершенно безразлично, есть APIC или нет, ему важно только правильно установить обработчик прерывания - сама по себе эта установка может зависеть от используемого контроллера прерываний, но это дело совсем другой части ядра. Без APIC драйвер будет замечательно работать как минимум на 99% систем - я, собственно, сильно сомневаюсь в существовании оставшегося 1%.

_________________
Сделаем мир лучше!


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 12:39 pm 
art_zh
Я использую Linux и дома и на работе - так что мое мнение не предвзято, однако если уж брать Linux, но нафиг Колибри вообще? Это еще один шаг к какому-нибудь Puppy Linux. А так к костылям Колибри приставим костыли Linux и по мнению отдельных людей все будет зашибись, а по мнению других нет. Я понимаю желание побыстрей и попроще сделать, чтобы не париться (я и сам тот еще лентяй), но никак не могу равнодушно соглашаться с подобным "развитием".

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

З.Ы. У меня были ситуации когда приходилось переустанавливать Виндовс, потому что APIC был отключен в BIOS и устройства никак не развешивались все.


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 12:49 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1620
Mario, у меня появились два вопроса.
1. Ты в курсе, что прерывания PCI разделяемые? На одном прерывании могут нормально работать несколько устройств.
2. Когда ты говорил, что существуют системы, где APIC необходим, потому что контроллер USB висит на прерывании выше 15-го, ты имел в виду, что так настроила BIOS или это результат перенастройки Linux/Windows? Я начинаю подозревать, что второе, а тогда я снимаю своё замечание про 1% - работать будет везде. Зачем они перенастраивают, это отдельный вопрос, я хочу сначала услышать ответы на эти два.

_________________
Сделаем мир лучше!


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 12:56 pm 
CleverMouse
1. Да, в курсе. Однако есть устройства которые не позволяют так работать и почему-то в больших системах стараются не вешать два устройства на одно прерывание.
2. Я не видел ни один BIOS который настраивает выше 16-го прерывания, зато видел много раз как BIOS оставляет USB контроллеры без прерывания (если судить по табличке которую сам же BIOS выводит). Еще я могу работать только с информацией которая мне доступна - так что да, мое замечание относиться к распределению прерываний в больших и устоявшихся системах. Ни разу не наблюдал, что имея APIC его не использовали.


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 1:11 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1620
Хорошо.
1. Разделяемость прерываний прописана в стандарте PCI. К legacy-устройствам, типа того же таймера и PS/2, это не относится, но таких фиксированное число и больше не делают. Большие системы стараются разбивать прерывания от разных устройств на разные вектора по следующей причине. Когда два устройства висят на одном прерывании, то обработчик прерывания вынужден опрашивать оба устройства на предмет, кто из них сгенерировал прерывание, и в результате получаются лишние дёргания шины и мирно работающего без прерываний устройства - это довольно малый вклад, но логика здесь "если можно избавиться, то почему бы не избавиться". У нас ситуация другая - квалифицированных рабочих рук мало, так что лучше делать то, что даёт заметный результат, а не примочками.
2. Ненастроенное прерывание - это более реально, да. Но тут уже APIC ни при чём.

Информацию о том, что настроила BIOS - а не Windows/Linux - можно спокойно почерпнуть из pcidev в Kolibri.

_________________
Сделаем мир лучше!


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 1:14 pm 
Вот статья очень хорошо и понятно описывающая ситуацию - на русском языке.
Страдания по IRQ

Нашел первым же результатом в Гугле по запросу "два устройства на одном прерывании".


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 1:22 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1620
Mario, ты действительно считаешь слова "Если два устройства находятся на одной линии прерываний, то драйвер может их спутать и переслать исполняемый кусок программы не той «железке», при этом заставляя ее исполнить этот кусок кода." - это цитата из документа по приведённой тобой ссылке - разумными?
Я ещё раз повторю: Разделяемость прерываний прописана в стандарте PCI. К legacy-устройствам, типа того же таймера и PS/2, это не относится, но таких фиксированное число и больше не делают. USB-контроллеры вообще-то располагаются на шине PCI.

_________________
Сделаем мир лучше!


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 1:24 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1342
Mario,
Ты не понял, я не предлагаю "брать Линукс", я хочу сделать удобный и универсальный инсталлятор для Колибри.
Такую же мысль высказал VaStaNi чуть раньше, но он имел в виду разработку собственного инсталлятора с нуля - это нереально сложная задача.
Но почему бы не воспользоваться чужими инструментами, чтобы сконфигурировать свои?
На "территориальной целостности и суверенитете" Колибри это никак не скажется, зато позволит проводить автоматическую тонкую настройку тех систем, для которых сейчас надо все допиливать вручную.

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

Напомню, что полноценная ОС вовсе не обязана уметь сама себя инсталлировать - винда вплоть до 2000-х годов не могла устанавливаться без помощи MS-DOS


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 1:30 pm 
Offline
User avatar

Joined: Tue Aug 25, 2009 4:45 pm
Posts: 794
Я гентушник. Могу собрать такой образ. Да, это действительно имеет смысл. Много специфичного софта грузиться с лайв линукса. Во всяком случае, пока нет другой альтернативы. Попробую заняться на выходных.


Top
   
 Post subject: Re: APIC
PostPosted: Wed Jun 15, 2011 1:31 pm 
CleverMouse
Тем не менее проблема существует. Если ты уверена что твое решение будет работать - ну не мне указывать, но выразить свое мнение - я считаю имел право. В общем как всегда "Мнение пишущего код более авторитетно мнения всех остальных" (смахивает на то как работают прерывания).

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

Не показатель - они не влияют на режимы работы.
Quote:
Напомню, что полноценная ОС вовсе не обязана уметь сама себя инсталлировать - винда вплоть до 2000-х годов не могла устанавливаться без помощи MS-DOS

Это как раз показатель неполноценности. Винда и была надстройкой.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 167 posts ]  Go to page Previous 13 4 5 6 712 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited