> man operating_systems
Центр информации по операционным системам :: Форумы :: Операционные системы :: GNU/Linux
 
<< Предыдущая тема | Следующая тема >>
как сделать ОСНОВНОЙ память PCI-устройства ?
Переход на страницу  [1] 2
Модераторы: Roman I Khimov, Wanderer, Dron
Автор Добавил
vv40in
Суббота 07.06.2008 12:42
ID пользователя #1076
Зарегистрирован: Суббота 07.06.2008 12:10
Сообщений: 62
Доброго всем здоровья!
мы вот, собираемся разрабатывать RAM для размещения в PCI-слотах (зачем, почему - не для обсуждения. надо. насколько я знаю, Sun и пр. выпускают cPCi-слоты памяти). но я чайник в linux. и не могу понять как можно подсунуть pci-память операционке так, чтобы она(ОС) считала её ординарной, т.е. могла ее распределять под сегменты исполняемых модулей и данных. есть ли у кого опыт такого финта, надо что-то дописывать в mmu или еще где? есть ли примеры таких решений? или может, вообще нет никаких проблем, и в linux имеется готовый механизм для этого?

PS:
платформа: SPARC(32).

PPS:
и нужно, чтобы к pci-memory ОС обращалась как с ОСНОВНОЙ памятью. это без вопросов, без свопов, без блочных устройств и пр...

насколько я понял, изучая ядро - надо будет прописАть в PROM такой микрокод, который проинициализует (сначала конечно замапит мою pci-память) свой массив sp_banks (в нем POST сохраняет данные о банках памяти:{адрес,длина}), которым потОм пользуется start_kernel (или типа того), вызывая init_memory (или типа того). так вот. в этот массив добавить также и pci-память. либо сделать это ужЕ в ядре (в start_kernel). ну а уж OC потОм пусть пользуется... правда, остается опасность, что ОС потОм захочет перемапить pci шину. ну а я должен буду это как-то запретить...
и всё-равни надо будет создавать что-то вроде ChipSet-а PC-платформы для управления адресацией, который после POST будет запрограммирован на сквозную адресацию к PCI-памяти.

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

у кого есть идеи !? заранее благодарен.
Наверх
Dron
Суббота 07.06.2008 14:10


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
Вот ты спросил... здесь кто нибудь видел живой SPARC32???

Насколько понимаю PCI память отображается в физическое адресное пространство. В любом случае для данной PCI платы в ядре линукс придется строить драйвер (ну такой, весьма примитивный), который наверное сможет передать имеющуюся в его распоряжении память в пул свободных страниц.

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

В любом случае рыть надо в подсистеме pci и в mm. после того как станет ясно как ядро инициализирует доступную память - можно будет строить какие-то более внятные предложения.

Сам то я программлю ядро, но несколько в другую степь, криптуха в основном...

Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее...

Андрей Валяев
Наверх
Сайт
Hmmm
Суббота 07.06.2008 15:08

ID пользователя #719
Зарегистрирован: Среда 09.08.2006 11:29
Местонахождение: Москва
Сообщений: 108
Ну я конечно видел т.н. SPARC32 и даже пописывал для него, но такой изврат вижу впервые. Теоретически конечно ничто не мешает использовать память PCI устройств как conventional.
А какая конкретно полатформа предполагается для ковыряния? Для SPARC-II нужно чтобы PCI память (256M - max) попала в таблицы MMU и для нее было включено кеширование. Как на аппаратном уровне это работает я себе представляю, как линуксовому ядру это объяснить - хз, скорее всего через mmap. По крайней мере непосредственно MMU абсолютно пофиг с какой памятью работать, главное чтобы она была
Наверх
vv40in
Суббота 07.06.2008 15:53
ID пользователя #1076
Зарегистрирован: Суббота 07.06.2008 12:10
Сообщений: 62
у нас будет такая платформа. sparc(leon3)+prom+[небольшая sram]+[pci-master] на одной cPCI-плате, на на cPCI шине должны стоять устройства, в т.ч. и память.

в общем, можно ли сделать так (без дополнительных разборок с mmu)? :
на этапе POST надо карты pci-памяти, проинициализировать PCI-мастер так чтоб он напрямую видел карты pci-памяти, и подсунуть их память в ввиде обычных банков. (и вообще тогда можно без спец драйверов pci-катр-памяти обойтись ну, в принципе .
а mmap - это ufaik - вызов уровня приложений. а мне же надо, чтобы ядро ужЕ _приложениям_ выделяло там память. а там действуют вызовы типа vmalloc,ioremap, etc.
в общем, мне кажется, что если настроить pci-master на сквозную адресацию к pci-памяти до загрузки ОС, то в дальнейшем для ОС всё будет также прозрачно. либо я сильно заблуждаюсь и тогда придется попотеть ...
Наверх
Hmmm
Суббота 07.06.2008 16:28

ID пользователя #719
Зарегистрирован: Среда 09.08.2006 11:29
Местонахождение: Москва
Сообщений: 108
Честно говоря я лично никогда не сталкивался со SPARC Leon3, хотя утверждается что он V8. Если так, то 256 метров в PCI вы засунете. Но мне кажется, что если вы разберетесь с подсистемой управления памятью в линуксовом ядре, то в крайнем случае придется его немного допилить. А разбираться придется полюбому, специфика вашей задачи это условие просто диктует.
Ядро открытое, доработки вам требуются в общем нехитрые, так что задача выглядит более чем решабельной. У меня есть код инициализации шины PCI на SPARC-II (тоже V8), к сожалению он проприетарный, но ничего сложного там нет, спецификация шины в зубы и вперед Другое дело, что с линуксом я на спарках никогда не работал, поэтому как его ядро ковырять под эту архитектуру я не знаю.
Наверх
Dron
Суббота 07.06.2008 17:55


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
Не моя область... и спарков я никогда не видел...

мипсы видел но не программил, армы видел, а спарков не видел

Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее...

Андрей Валяев
Наверх
Сайт
vv40in
Суббота 07.06.2008 17:59
ID пользователя #1076
Зарегистрирован: Суббота 07.06.2008 12:10
Сообщений: 62
Hmmm написал(а) ...

Честно говоря я лично никогда не сталкивался со SPARC Leon3, хотя утверждается что он V8. Если так, то 256 метров в PCI вы засунете.

я чайник и не понимаю - какая связь между типом процессора и объемом памяти на шине. объясните, пожалуйста, если не трудно.

Hmmm написал(а) ...

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

тут я тоже не понимаю (пока не столкнулся). мне надо, чтобы POST сразу после инициализации шины pci, карт памяти PCI (а pci-мастер настроить на сквозную адресацию к этой памяти) и контроллера диска (тоже на PCI) загрузил с диска linux-boot в память на pci-карточке. и передал управление загрузчику. должно ли быть настроено mmu до этого? (??? а можно ли его вообще не использовать(отключить) для начала???). загрузчик в дальнейшем раскрутится
в общем-то, загрузчик можно поместить в локальную память на карте CPU. но только если это необходимо.

и вопрос чайника по pci: при обычной работе доступ к pci-памяти осуществляется ч-з драйверы? т.е. при запросе приложения mmap к памяти, заявленной драйвером устройства, управление передается к этому драйверу а тот рулит? или тут какой-то другой механизм?

Running Linux on a PCI Add-in Card (какое-то отношение имеет к теме. правда не совсем понял - есть ли cpu на add-in card)
Наверх
vv40in
Суббота 07.06.2008 19:31
ID пользователя #1076
Зарегистрирован: Суббота 07.06.2008 12:10
Сообщений: 62
Hmmm написал(а) ...

Ну я конечно видел т.н. SPARC32

а не могли бы Вы прислать пример типичного PROM-а sparc-a (если у Вас был типичный). я-то его никогда не видел.

Hmmm написал(а) ...

Для SPARC-II нужно чтобы PCI память (256M - max)

откУда ограничение на 256М?
кр.того PCI-spec3.0:

The number of upper bits that a device actually implements depends on how much of the
address space the device will respond to. A 32-bit register can be implemented to support a
single memory size that is a power of 2 from 16 bytes to 2 GB.

причем там этих регистров 6 штук (т.е. в сумме реально можно получить до 10Гб (?))
лимИт, конечно, может зависеть от платформы. но тогда объясните, пожалуйста.
Наверх
Hmmm
Воскресенье 08.06.2008 17:27

ID пользователя #719
Зарегистрирован: Среда 09.08.2006 11:29
Местонахождение: Москва
Сообщений: 108
Для начала вам следует разобраться с тем как устроен ваш процессор, к сожалению никакой вменяемой документации по Leon3 я в интернете не нашел (может плохо искал ) Но есть документация по microSPARC-IIep(тоже V8): mediacast.sun.com/users/Barton808/ media/STP1100BGA-microsparcIIep-manual.pdf Загляните в приложение B, там найдете информацию о 256M памяти PCI. Но эта документация не имеет прямого отношения к вашему процессору, поэтому возможно в вашем случае все немного иначе. Лучше конечно достать документацию именно к Leon3.
Примера "типичного PROM-а sparc-a" я к сожалению вам пилсать не могу, поскольку он проприетарный. Вы сами все это написать сумеете, единственный вопрос это разобраться с работой вашего процессора, и prom от microSPARC-IIep тут вам ничем не поможет.
После инициализации работа с памятью устройства идет как с обычной, за прозрачную трансляцию адресов отвечает контроллер PCI, поэтому я и написал, что в общем доработка ядра должна быть несложной. Никаких специальных драйверов для этого городить не нужно.
Наверх
vv40in
Понедельник 09.06.2008 11:24
ID пользователя #1076
Зарегистрирован: Суббота 07.06.2008 12:10
Сообщений: 62
понял. ограничение на память зависит от аппаратной архитектуры. она ее еще не полностью разработана. к тому же, еще не решено - реализовывать ли MMU, а при этом физическая адресная шина 36 бит, что расширяет горизонты.
кр того, в microSPARC-IIep карта памяти как-то, э--э-э, вообще само-ограничена. mmu там вообще преобразует 32-виртуальный адрес (va) в 31-битноый физический (pa) (а не из 32va в 36pa как полагалось бы).
но прошу не судить меня строго - я всё же новичек


Наверх
Переход на страницу  [1] 2  

Перейти:     Наверх

Транслировать сообщения этой темы: rss 0.92 Транслировать сообщения этой темы: rss 2.0 Транслировать сообщения этой темы: RDF
Powered by e107 Forum System

© OSRC.info, 2004-2010.
Авторские права на любые материалы, авторы которых явно указаны, принадлежат их авторам. По вопросам публикации таких материалов обращайтесь к авторам.
Авторские права на любые другие материалы принадлежат OSRC.info.
Сайт является помещением библиотеки. Копирование, сохранение на жестком диске или иной способ сохранения произведений осуществляются пользователями на свой риск.
При использовании материалов сайта ссылка на OSRC.info обязательна.