APIC

Internal structure and you change requests/suggestions
  • 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 возможно подвигнет кого-нибудь использовать её возможности для работы с термодатчиками, вентиляторами, батареями, подсветкой, и чем там ещё можно управлять.
    А что решил делать с именованием?
  • >>А что решил делать с именованием?

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

    Users browsing this forum: No registered users and 3 guests