Board.KolibriOS.org

Serge
нет универсальной альтернативы - только частные решения для конкретных случаев.
В твоем (и любом другом) конкретном случае выбор ясен:

1) надо либо раскуривать мануалы твоего чипсета и кодить напрямую,
2) либо портировать мегакод из Линукса.

Причем во втором случае одним только внешним энумератором дело не ограничится: рерутинг IRQ все равно придется каждый раз при старте производить через один известный своей универсальностью проход. И не уверен что ACPI сможет решить все проблемы присно и во веки веков:

В финале лаунчер запустит pcidev с ключом BOOT.
pcidev сканирует шину и сравнивает результат с devices.dat.

А как pcidev сможет разглядеть "невидимые" устройства и функции, как перекинет нужные линии куда надо, если PM-регистры и коммутаторы вдруг окажутся "заморожены" по дефолту, а как их включить ACPI не знает?
Минимальный драйвер чипсета все равно будет нужен, хотя бы для инициализации (про хотплаг и SMI пока вообще забудем). Но тогда возвращаемся к той же самой альтернативе (см. выше), но теперь уже и вариант 2) не будет "универсальным решением для всех". И я уже говорил что мы тогда получим -- еще один линукс, только с ассемблерным ядром.

Я предлагаю работающее универсальное решение для всех, чтобы дистрибутив мог стартовать на любом компе.

Забавно, я тоже хочу чтобы дистрибутив мог стартовать на любом компе - на базе Linuх Live или хотя бы и на нынешнем "универсальном" PC-ядре Колибри; и чтобы мог самостоятельно настраивать параметры компиляции неуниверсального ядра для конкретной платформы.
А если платформа не поддерживается - чтобы говорил что сорри, драйверов для вашего чипсета пока не имеется. Пользуйтесь пока старым ядром и спонсируйте дальнейшую разработку проекта (вариант: инвестируйте в себя, обзаведитесь правильным железом ).

Насчет твоей сетевухи - я совершенно не представляю себе как устроены интеловские мосты, но на АМД-шных чипсетах GЕС МАС (bdf 0:14h:6) по дефолту скрыт (невидимая функция, однако!), интегрированный сетевой чип формально приписан к какой-нибудь 4-й шине, но прерывание с него обрабатывается не как внешнее PCI-IRQ, а как внутреннее прерывание южного моста. Например, на Гудзоне под нее выделена отдельная IOAPIC-линия #15h, и всем этим делом управляют 5 специальных PM-регистров.
Может и в интелах есть подобные заморочки?

art_zh

PCIDEV должен только определить наличие нового устройства. Если у нас появилось устройство с пином==1 и irq < 16, значит оно новое. Конечно шину может сканировать и само ядро, но так сэкономится время на загрузке.

Заморочки с интегрированными девайсами на интелах конечно есть, но у меня внешняя сетевуха. Я смотрел много разного кода в разный системах и напрямую с чипсетом работал только Minix3. И то, там программировался роутер для PIC. А вот прямого программирования линков для PCI я нигде не видел. Всё только через ACPI.

LiveCD Linux может подложить свинью. Он умеет раскидывать расшареные прерывания для снижения задержек. Опять же через ACPI. Делает это тихо и незаметно, никому не сообщая. Нашему ядру простым патчем pci_cfg:0x3C в этом случае не обойтись.

Serge: хочу только напомнить, что не на всех компьютерах есть APIC и/или ACPI. Но таких зависаний, как ты описал, воспроизвести не удалось пока.

yogev_ezra

Нет APIC - нет проблем. И ACPI тогда тоже не нужно. Будут работать как сейчас. USB пока не удалось потестить. Хочу сделать расшареные обработчики прерываний. Если проблема вылезет снова, значит это действительно очень хитрый баг в коде. Не знаю даже что хуже в этой ситуации, кривое железо или кривой код.

Serge wrote:Я смотрел много разного кода в разный системах и напрямую с чипсетом работал только Minix3. И то, там программировался роутер для PIC. А вот прямого программирования линков для PCI я нигде не видел. Всё только через ACPI.

Этот Великий и Ужасный собирает информацию и разводит все эти линки через регистры контроллеров PCI, SMB, и PM. Так почему бы не читать/менять эти регистры напрямую, может даже меньше заморочек окажется?

Если ради смеха выкинуть из ядра АПМ-код (он все равно глючит на половине биосов) и перевести выключение/перезагрузку на прямую запись в PM-регистры южного моста, то потребуется всего 6 строчек (10 байт) прямого кода вместо килобайта АПМ-извращений! Аналогичная ситуация будет и с ACPI, только здесь можно ожидать эффект не в 100, а минимум в 1000 раз по размеру кода, и в миллион - по быстоте.

И ради чего его вообще тащить в систему, этого монстра - только чтобы раскидать прерывания ?
Раскидаем - и на этом успокоимся...
А дальше?

Я не представляю как можно реализовать полноценный хоть какой-нибудь косолапый обработчик ошибок и хотя бы минимально-приемлемый тренинг линий PCIe и SATA (и еще хотплаг) без прямой работы с мостами. А есть еще GPIO, и они тоже кому-то могут быть нужны. И еще бывают совсем нестандартные, сыроватые устройства, материнки с кривыми биосами, которые только и ждут когда Колибри наконец научится дружить с железом и даст им новую жизнь.

Ядерные модули нужны, для каждого популярного чипсета (вариант: только для своего ). Не суть важно, будут ли это DLL или монолитные inc-блоки (я за второй вариант), и не обязательно впихивать туда сразу всю функциональность мостов - пока достаточно простейших элементов управления PM, APIC, SMB, SIO, HPET, и маппинга MMIO-cfg. Этого вполне хватит чтобы развязать (почти) все сегодняшние мертвые узлы, и подготовить задел для будущего развития.

Serge wrote:LiveCD Linux может подложить свинью.

Ладно, фиг с ним, с линуксом. Инсталлятор с настройкой ядра на подходящую платформу вполне можно построить и на базе ISO-Колибри.

art_zh
Этот Великий и Ужасный хранит информацию записанную разработчиками. Если на плате распаяно ещё что-то кроме стандартного южного моста, её без таблиц ACPI и не сконфигурируешь. А таких плат сейчас большинство.
И не забываем про ноуты, которых теперь больше половины продаётся. Там "оригинальные" дизайны особо часто встречаются. То же управление подсветкой у каждой модели может быть своё. А вещь необходимая. Я понимаю, ты под свою конкретную плату можешь ядро отполировать так, что сверкать будет. Но мы то не встроенную систему разрабатываем.

Serge
Всё, теперь я наконец тебя понял.
Тебе просто в лом открыть коробку и посмотреть как эти таинственные Разработчики раскинули провода типовой схемы, которая прилагается к каждому чипсету.

Мне понятен суеверный страх "чистых" программистов перед электроникой, но уж ты-то не можешь не знать, что все эти фирменные материнки в пределах одного чипсета отличаются друг от друга только переназначением отдельных GPIO и наличием каких-нибудь дополнительных контроллеров (на которые, в свою очередь, имеются свои типовые схемы подключения).

Ясно, что если система построена на "закрытом" чипсете - то не зная распиновки и спецификации регистровой модели в ней никогда не разберешься. Но ведь это вопрос NDA, а вовсе не ACPI, так!

Ладно, если ты решил строить систему "для всех" - тогда без ACPI конечно не обойтись. Не буду мешать.
Я должен был высказать все свои аргументы перед точкой бифуркации, и я их изложил.

art_zh
"в пределах одного чипсета" в том то и дело. Будь он один единственный на свете Чипсет на ближайшие ...дцать лет. А тут каждый год считай по новому сокету выпускают.

Это не я решил "строить систему для всех". Так всегда было.

diamond wrote:Колибри унаследована от системы, которая изначально задумывалась как десктопная, и продолжает развиваться, как десктопная.

Serge, если это а) будет работать, б) будет работать точно как текущее ядро - в режиме PIC - если не удастся загрузить библиотеку, в) поможет дальнейшему развитию, то я согласна.

CleverMouse wrote:Serge, если это а) будет работать, б) будет работать точно как текущее ядро - в режиме PIC - если не удастся загрузить библиотеку, в) поможет дальнейшему развитию, то я согласна.

Поддерживаю.

в) Мне поможет точно на ближайшие пару месяцев тестиривать звук и видео одновременно. Плюс я сделаю каскадирование обработчиков прерываний. Так что польза для ядра и системы в целом будет несомненно. Поиск в devices.dat может заменить сканирование шины каждым драйвером. Стабильно работающая ACPICA возможно подвигнет кого-нибудь использовать её возможности для работы с термодатчиками, вентиляторами, батареями, подсветкой, и чем там ещё можно управлять.
а,б)

CleverMouse wrote:если не удастся загрузить библиотеку

То есть нумератор устройств на базе ACPICA ? Весь остальной код будет в ядре. Разумеется если не удастся найти devices.dat и получить данные от acpi, ядро будет работать в режиме PIC. Дополнительно я планирую добавить опцию в загрузочный экран для выбора режима PIC. Удаление devices.dat и acpi.dll даст тот же результат. В худшем случае devices.dat можно сделать самому.

Тогда флаг в руки и вперёд.

Serge wrote:Мне поможет точно на ближайшие пару месяцев тестиривать звук и видео одновременно.

Аналогично + USB.

Serge wrote:Плюс я сделаю каскадирование обработчиков прерываний. Так что польза для ядра и системы в целом будет несомненно.

Расшаренные прерывания это очень большой плюс.

Serge wrote:Поиск в devices.dat может заменить сканирование шины каждым драйвером.

Собственно, когда ты только сделал драйверную подсистему количество самих драйверов было не большим и можно было обойтись. Но сейчас уже рядовых пользователей действительно не стоит заставлять разбираться в установке драйверов, да и использование отдельных программ-загрузчиков драйверов выглядит странно, поэтому и появилась тема Driver service.

Serge wrote:Стабильно работающая ACPICA возможно подвигнет кого-нибудь использовать её возможности для работы с термодатчиками, вентиляторами, батареями, подсветкой, и чем там ещё можно управлять.

А что решил делать с именованием?

>>А что решил делать с именованием?

Пока ничего. Вопрос открыт. Предложений нет. Пока это не очень актуально, но считаю, что надо разработать систему именования для всех устройств - портов, дисков, датчиков, контроллеров, плат.

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