Board.KolibriOS.org

Mario wrote:А случай когда вставляется новая плата в слот системной шины - я понимаю что сейчас не самый актуальный пример, но оперативность теряется.

Если у тебя уже работает мышка и клавиатура - всегда можно подправить .ini-файл и в tinypad.

Это все равно лучше чем

Serge wrote:В худшем случае создаём файл ручками. Заодно используем этот файл как диспетчер устройств для бедных, чтобы не сканировать каждый раз шину при поиске устройств.

Mario
CleverMouse

Это могут быть ошибки биос. Сам столкнулся с такой когда занимался звуком. Контроллер AC97 на ICH0. БИОС выполнила настройку роутера но не записала номер линии в 0x3C. В результате там был дефолтный 0.
В теории БИОС должна назначать прерывания всем устройствам, но не факт, что она всегда это делает. Тем более никто не застрахован от ошибок.
Прерывания PCI расшариваются, но
-ядро не поддерживает цепочки обработчиков на одной линии. Кто последний вызвал AttachIntHandler, того и тапки.
- такая цепочка увеличивает латентность обработчика. По этой причине Линукс высчитывает пенальти для расшаренных линий и при необходимости перераспеделяет линии. Современные платформы позволяют это делать, хотя не самым интуитивно понятным образом.
В идеале каждое устройство должно иметь персональную линию irq.

art_zh, Колибри можно загрузить с FAT32-тома, не используя загрузчики других систем.
Mario, существует проблема - насколько я понимаю, не очень распространённая, - с тем, что BIOS может не сконфигурировать устройство. Насколько я представляю себе APIC, он не имеет к этой проблеме никакого отношения - с его помощью можно превратить входные сигналы контроллера в различные прерывания, но чтобы узнать, какой входной сигнал соответствует какому устройству/функции, нужны другие средства, типа Routing Table или ACPI.

art_zh wrote:У меня более реалистичное предложение: использовать live-версию Линукса как базовый инсталлятор Колибри.

это начало пипецА аскетически-ассемблерного проекта.
Тогда могу еще более просто и более народно предложить. У всех есть винда, она стандарт, она крута, на нее куча прог написана, за два дна пишется инсталлятор-конфигуратор КолибриОС из под винды. Винда "крута", она все знает, все умеет, давайте ей доверимся и пропишем и настроим Колибри с ее помощью.
Это будет работать у всех!
Инсталляция (типа каталог создать и налить его + загрузчик в boot.ini прописать), это еще терпимо, а вот ресурсы (IRQ, DMA...) настраивать для КолибриОС из любых сторонних ОСей - кризис проекта и начало его п.....

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

А не выродится это в аналог виндового реестра, по сути.

Я сторонник работы с устройствами автоматически, динамически, интеллектуально.
И понятное дело это основной вопрос таланта дровосеков и архитектруры и дровного апи.
Пока в драйвере не будет тест-инита, например, то будет постоянная боязнь и прерываний и глюков и конфигураций и железа... причем судя по постам любого, даже мыши!
Жуть.
РебятЫ!!!
Есть дефлотустройства заюзанные донельзя: мишь, клавка, COMы, LPTшники, саундкарты, сетевухи(может не все) - имеют либо команды и квитирующий ответ, либо (или помимо того) команды принудительно инициализирующие личные IRQ этой дровишки. За ними давно жестко все прописано! Это же РС архитектура! Кто на них что может развесить? Корявый биос? Нахер его выбор, нам виднее!
Да немного повозится надо, запретить все кроме тестируемой линии, поднастроить кое что с регистрами и послать команду (тест-блок данных), выждать и проверить есть ли его IRQ + ответ(или адакватная реакция).

art_zh wrote:А потом при старте Колибри каждый раз тупо грузить конфиг-регистры прямо из этого файла.

при слове тупо, а хватаюсь за пистолет
ничего личного, просто у меня тут начальник, который типа главный в конторе по созданию интеллекта для устройств, т.е. над кодерами "хазяин"...
Его ГЛАВНОЕ козырное предложение всегда одинаково: "... а че тут думать, а давайте тут и тут вот втупую захерячим и все! Че париться?"

CleverMouse wrote:но чтобы узнать, какой входной сигнал соответствует какому устройству/функции, нужны другие средства, типа Routing Table или ACPI.

а можно ВСЕ зепретить и выключить и перебирать в цикле n по одному IRQn, предварительно "спровоцировав" дровину надавить на линию и тогда механизм работает без всяких новомодных ACPI! И если проба пера успешна, занчит с болшьшой долей верояности дровина на этой линии педалить умеет. Да линий может быть несколько, но это и хорошо, мы все их протестируем и линии и дрова их. Получаем массивчик. Остается его развесить, хотя бы то что можно, что более лояльно...

Здравая идея! Опять-таки это обеспечит отсутствие "ненужных" закидонов со стороны BIOS/SMM

Не, ну если речь идет о целомудренности аскетически-ассеблерного проекта, тогда конечно я лучше помолчу.

Мне-то что - я на своей отдельно взятой платформе сам себе хозяин, чего надо разведу без всяких линуксов.
Тем более, что весь POST для AMD Fusion теперь полностью открыт.

Блин, как будто что-то не то сказал, - мы-то ACPI в coreboot используем.

Предложение такое:
Есть работающий бранч c APIC. Есть работающий нумератор устройств на базе ACPICA+pci код из Линукс. Я планирую заменить оригинальную ACPICA на порт из Линукс, он меньше. Нумератор будет генерировать файл /rd/1/drivers/devices.dat примерно такого формата

dd (bus shl 8 )+(dev shl 3)+fn
dd (DeviceID shl 16) + VendorID
dd irq_line
dd ещё что-нибудь
dd -1 ; терминатор

При инициализации ядро грузит файл и по нему патчит PCI_CFG:INT_LN для всех прописанных устройств. Если файл отсутствует запускает нумератор и возвращается к предыдущему пункту. Возможен возврат к инициализации менеджера памяти и кучи ядра, в этом случае следов ACPICA в памяти не останется.
В финале лаунчер запустит pcidev с ключом BOOT.
pcidev сканирует шину и сравнивает результат с devices.dat. Если обнаружено новое устройство, стирает devices.dat и предлагает перезагрузить компьютер (дополнительно проверяет по своей базе наличие драйвера и, в случае успеха, предлагает выполнить необходимые действия по установке драйвера)
???
PROFIT

Упакованная acpi.dll занимает 90кб если убрать из дистриба atikms останется ещё 100 Кб.

Serge

Двухэтажный энумератор и +90Кб системного кода (пусть и в DLL) -- и это только для того, чтобы раскидать прерывания в APIC ?!

А не разумнее ли решать проблему "снизу" -- добавить в ядро прямой код (типа bus/southbridge/apic.inc) ?
Да, этот код будет специфичным для каждой платформы, но это будет всего сотня-другая строчек.
Для многих чипсетов сейчас регистровые модели открыты, а для остальных пока можно работать по дефолту, через PIC.

art_zh

Приведи пример как мне перекинуть свою сетевуху BUS2:D1:F0 pic IRQ 10 на APIC. С благодарностью приму работающий код для своего интела.

Если хочется сэкономить место, достаточно набить файл ручками. И мудрит с чипсетами не надо.

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

Serge,
убийственный аргумент!
Особенно если учесть, что я никогда не работал с интеловскими чипсетами. И не собираюсь.

Для AMD-шных мостов такая фишка уже тестируется.

Я не лезу в чужую работу и никого не заставляю что-то делать против их воли.
Но почему я не могу высказать свое недоумение (равно как и восторг) по конкретному вопросу, который касается всех?

XVilka
Так я так и хочу и именно это и предлагаю. И утилита уже есть, на основе ACPICA, универсальная для всех платформ. Осталось только сделать вывод списка и загрузку его ядром с последующим патчем pci_cfg.

Я совсем не против специализированного кода, но где этот код и кто его делает ? И будет он работать на каком-нибудь VIA или NForce ? Пока есть только долгие разговоры и никакого движения. Никаих других реальных альтернатив. Вчера посмотрел исходники Minix, @#$%^ и там acpi!!! Когда успели ? Год назад ещё ничего не было.

Для себя лично я могу забить номера прямо в ядро и положить на всё большой болт. Но хочется что бы система развивалась и была дружелюбней к пользователю.

art_zh
Это замечательно, что тестируется. Но кто будет помогать остальным ? Ты не собираешься, я тоже. Я и понятия не имею каким образом вычислить линию на IOAPIC для моего примера. Патчу Ghost-a два с половиной года. За это время продвижения по теме ноль. Только немного общих размышлений. Я предлагаю работающее универсальное решение для всех, чтобы дистрибутив мог стартовать на любом компе. Если есть такая же универсальная альтернатива ACPI я буду только рад. Но её не видно.