В чем заключается проблема инициализации? Оказывается мы должны при включении питания каким-то образом подготовить ЭВМ или комплекс, причем заведомо известно, что содержимое ОП теряется, поэтому мы должны предусмотреть некие ПЗУ, которые содержат код, исполняемый процессором, потому что изначально этот код не предусмотрен, который позволит, с учетом конкретной архитектуры ЭВМ, запустить (инициализировать) у-ва входящие в с-му. А у-в таких много: начиная от СИ, заканчивая котроллерами или ресурсами, работающими на СИ, причем многоуровневыми. Но может оказаться, что изменяется состав вашей вычислительной с-мы. Изменение программ, выполняющих инициализацию не годится. Поэтому возникает проблема конфигурации, которая заключается в следующем: может оказаться, что у вас имеется несколько однотипных устройств, которые находятся в с-ме; несколько однотипных контроллеров, которые требуют одних и тех же ресурсов. До сих пор эти проблемы решались примитивным образом: производитель должен был где-то продавать комплектацию каждого из у-в. Сейчас же, при наличии идентификации, есть возможность автоматического выбора конфигурации у-в и инициализации ПО самостоятельно, а не вручную, как это делалось раньше.
Рассмотрев особенности инициализации и конфигурации в рамках спецификации P`n`P мы дошли до того, что в конфигурационном адресном пространстве контроллер ПУ-в должен выглядеть сл.обр.
Это те регистры КПУ, которые он должен отобразить в АП СИ PCI. Эти регистры разделены на две большие части. К первой части относятся те регистры, которые исп-ся в одном экземпляре для всего контроллера, а ко второй части – ячейки для каждого из устройств, подключаемых к контроллеру.
Пример такого подхода классический: на звуковой карте есть очень много устройств: входной и выходной каналы, регулятор громкости, микшер и т.д. и т.п. Это каждое из устройств независимо: микшер может быть, а может и не быть, также и регулятор. Т.е. на контроллере м.б. несколько логических устройств. На контроллере есть общее АП, независимое от числа логических устройств и входящих в контроллер и части, которые дублируются на каждом из устройств. Существуют специальные команды, которые отображают эти части в общее АП, путем занесения номера логического устройства в специальную ячейку. В свою очередь каждая из этих частей делится на 3 типовых части. Первая часть – управление КПУ в целом; вторая часть зарезервирована; третья часть – регистры, определяемые производителем. Последние части в АПУ и АПК: управление, определяемое производителем и конфигурация производителя, т.е. те данные, которые использует драйвер производителя.
