Приветствую!
Во-первых, хотел бы отметить, что в начале столкнулся с проблемой отсутствия базового адреса в конфигурационном пространстве моста (как здесь).
Проблема была решена использованием не документированного ключа -B pci-bios. Кстати, в x86 BSP, в usage pci-bios ключ описан ...

Собственно мой вопрос. Спеки тундры оставляют желать лучшего (ИМХО) и приходится изучать линуховый драйвер.
Тундра хотит чтобы ей в качестве окна для мастера выдали диапозон из "PCI address space"! Никогда не сталкивался с таким необычным требованием. Единственное объяснение, которое я нахожу, это то, что изначально тундра была нацелена на рынок ppc, а там вроде физический адрес (physical address) и адрес шины (bus address) различны. Читал, что с 2 или 3х гигов в ппц шина устройств начинается. У меня х86 платка с тундрой на борту и насколько я понимаю эти адреса (phys and bus)идентичны. То есть написав такое в доке, тундра просто обобщила для всех платформ и я могу на x86 подсунуть ей просто непрерывный кусок phys mem через mmap и mem_offset.
В доке также написано, что PCI Target тундры будет сравнивать "incoming pci address" с заданными в регистрах координатами окна. Тут и возникает сомнение, хм, неужели нужно мапировать кусок из pci address space? И где этот кусок должен быть чтобы доступ на чтение-запись этого куска обрабатываться PCI таргетами pci шины и в частности таргетом моста тундры?
Any idea?

PS. Схема типа DMA, когда выделяем озу, отдаем физ адр и пишем в один из регистров Run! здесь не просматривается, похоже реакция на чтение-запись действительно анализируется PCI Target'ом моста именно по факту выставления запроса чтения-записи на шине pci...мрак(

Сколько стоит эта микросхема? Насколько популярны микросхемы типа PCIX-VME Bridge? Имеет ли смысл производить типа PCIX-VME Bridge?

Насколько я понимаю VME и вообще сбор данных с датчиков в одну корзину устарел. Бал правят распределённый сбор данных.

По ценам на эти вопросы я думаю вам смогут ответить представители тундры в европейском регионе или их ресейлеры. Этот шедевр мне дали бесплатно ))
В плане смысла, PCI на новых мамках вымирает потихоньку, вот и сделали..Популярен среди PowerPC решений, насколько я понял. Зайдите на тундра.ком, там мона сделать аккаунт МояТундра и попросить доступ ко всякого рода уайтпэйпам, типа "Buy or Create Yourself"...

Не очень понятны возникающие проблемы, поэтому начну издалека
Есть PCI шина, на ней происходят транзакции. Устройства на этой шине ловят эти транзакции, например, по адресу.
Так работают контроллер памяти, "обычные" PCI девайсы вроде сетевухи, и другие хитрые PCI-хзчто мосты (которые транслируют запросы в соответствии с настройками на другие шины).
Для управления tsi148 мостом нужно как минимум 4к "PCI address space"; по идее, это пространство должен резервировать BIOS. Но можно и вручную через CF8/CFC настроить, главное, что бы эти адреса не пересекались с другими устройствами.
Далее, у этого моста есть настраиваемые окна (через те регистры, которые отмаплены в пресловутые 4к). Т.е. мост, получая транзакцию сравнивает адрес с настройками, если совпадает - предпринимает какие-то действия (например, выдает транзакцию на VME шину). Тут важно, чтобы транзакция дошла от источника (процессора) через все промежуточные шины (PCI-PCI мосты и т.п.) до микросхемы. Вот и все и это прекрасно описано в даташите.
Другими словами, перед настройкой окон нужно позаботиться, чтобы эти адреса не совпадали с RAM (включая извраты с MMU), с другими PCI-устройствами (на всем пути от процессора до tsi148), а также успешно транслировались всеми промежуточными мостами.
С DMA ситуация другая, тут источник - сам тундровский мост (грубо говоря - bus mastering). Поэтому транзакции должно ловить другое устройство (обычно - RAM контроллер). Поэтому и нужно выделять реальную память и физический адрес сообщать мосту.
Примерно так, хоть и грубовато

vshemmДля управления tsi148 мостом нужно как минимум 4к "PCI address space"; по идее, это пространство должен резервировать BIOS. Но можно и вручную через CF8/CFC настроить, главное, что бы эти адреса не пересекались с другими устройствами. Very clear explanation but I'd like to emphasize that the memory space must not overlap memory windows for the other devices including memory controller (RAM) I.e. "PCI address space" is the memory region which is not assigned for any devices or system memory and therefore is free for PCI devices. For example, "ISA address space" (might be considered as a subset of the PCI address space) is the area above video controller memory but below BIOS extention modules, i.e. from 0xC0000 to 0xE0000 linear phys. address. In a nutshell, any PCI device that have memory mapped registers should require PCI memory space. It is not an "unusual requirement" at all.

коллеги!! не поделитель библиотеками и функциями под QNX 4.25?...
для Tundra Tsi148

vshemm, ed1k, спасибо. Очень детально!
Идею работы по сравнению координат окна я наверное уже могу ночью рассказать без мануала )). Но есть пробелы чисто системного характера, см. ниже..
С тундровыми 4к все в порядке, отмапил, доступ есть.

А что за CF8/CFC? Интересно, потому как день убил на то, чтобы найти ключ pci сервера, инициализирующий ресурс памяти моста. Как я понял, полазив по форумам, ключик этот помогает не для каждого типа моста..

> нужно позаботиться, чтобы эти адреса не совпадали с RAM
> that the memory space must not overlap memory windows for the other devices including memory controller (RAM)

Это вы про одно и тоже говорите, устройство memory controller? Как определить диапозон им занимаемый?


>Т.е. мост, получая транзакцию сравнивает адрес с настройками

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

Дык как же мне выбрать этот кусок памяти?
Например, моя тундра имеет базовый адресс dc000000, 4096 байт.
pci-bios с опцией -v говорит вот что:
resource_reserved 3f700000-ff700000 Bus0
resource_reserved d0000000-df000000 Bus1
На Bus1 сидять друг за другом 4 ethernet и тундра. Тоесть получается, что начиная с dc001000 до df000000 "свободно"?
Если нужно могу запостить вывод слогинфо со всеми ресурсными подробностями...
Если этот диапозон действительно свободен, то...

... каким образом его "позаимствовать"? mmap_device_memory? И потом читать/писать через возвращенный указатель виртуальной памяти?

Если так, то круг замыкается и понятно кто и как генерит транзакцию. Но почему Target тундры должен обработать такую транзакцию? Транзакции что, широковещательные? Или всеже у каждого pci устройства есть своя "зона ответственности"? ...

PS/ Не бейте за слишком большое число вопросов
PS2/to slonok/ увы, делиться пока нечем. Да и для 4ки пока такого не требовалося...Вы тоже драйвер под tsi148 пишите?

> важно, чтобы транзакция дошла от источника (процессора) через все промежуточные шины (PCI-PCI мосты и т.п.) до микросхемы.

А могут быть ситуации, что транзакция не проходит? Если так, то как выявить моста-убийцу ?

osDrummer
А что за CF8/CFC? Интересно, потому как день убил на то, чтобы найти ключ pci сервера, инициализирующий ресурс памяти моста. Как я понял, полазив по форумам, ключик этот помогает не для каждого типа моста..

Это кодовое название того, как программируют PCI настоящие мужчины Если ОС не предоставляет функций работы с конфигурационным пространнством PCI устройств, если у вас нет PCI BIOS, тогда остается только работать через порты ввода-вывода, например как здесь (первая попавшаяся прога на гугль-запрос, вовсе не реклама)

osDrummer
Это вы про одно и тоже говорите, устройство memory controller? Как определить диапозон им занимаемый?

Ну не знаю... Есть прерывания БИОС, которые рассказывают как много оперативной памяти установлено в компьютере, возможно есть функция в QNX, которая вам поможет. Обычно оперативка располагается линейно с нулевого адреса и до сколько у вас денег хватит.

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

Когда ваш код обращается к памяти, например по указателю, то физически на лапках процессора формируется физический адрес и еще кое-какие управляющие сигналы (они вам абсолютно не интересны), это может привести к тому, что за host/pci мостом на PCI шине сформируются похожие эл. сигналы, суть которых сводиться к тому же - например, "процессор хочет получить данные по такому адресу". Устройство PCI, которое разпознает адрес как находящийся внутри его окна ответсвенности, заявит на шину "о! это мой адрес, я щас дам данные". Если это устройство мост, pci/pci или pci/vme то оно просто передаст транзакцию, т.е. скажет на вторичную шину "нужны данные по такому-то адресу", т.е. сформирует эл. сигналы на вторичной шине по стандартам вторичной шины. Адрес может быть пересчитан по правилам и настройкам моста. Устройство на вторичной шине аналогично клаймит "о! это мой адрес" и выдает данные (или передает транзакцию дальше по цепочке, если это оказался опять мост). Процессор и host/pci bridge вам настраивать не нужно. Во время загрузки маленькие человечки уже обо всем позаботились

osDrummer
Дык как же мне выбрать этот кусок памяти?
Например, моя тундра имеет базовый адресс dc000000, 4096 байт.
pci-bios с опцией -v говорит вот что:
resource_reserved 3f700000-ff700000 Bus0
resource_reserved d0000000-df000000 Bus1
На Bus1 сидять друг за другом 4 ethernet и тундра. Тоесть получается, что начиная с dc001000 до df000000 "свободно"?
Если нужно могу запостить вывод слогинфо со всеми ресурсными подробностями...
Если этот диапозон действительно свободен, то...

Честно скажу - не знаю. Обычно менеджер устройств в ОС распределяет память, в том числе и для устройств. Т.е. память должна распределяться централизовано, иначе начнется бардак и кто-то на кого-то наедет. Как это делается в QNX я не знаю.

ed1k
Процессор и host/pci bridge вам настраивать не нужно. Во время загрузки маленькие человечки уже обо всем позаботились

Спасибо, ed1k. Теперь, фирштейн

ed1k
Обычно менеджер устройств в ОС распределяет память, в том числе и для устройств. Т.е. память должна распределяться централизовано, иначе начнется бардак и кто-то на кого-то наедет

Вот и меня тоже тревожит такой момент. По правильному надобы mmap_device_memory использовать для того чтобы отмапить кусок pci памяти. Но в хелпе по ней сказано, что..
This function already uses MAP_SHARED ORed with MAP_PHYS
Тоесть, если кто еще захочет отмапить - получит доступ.
С другой стороны тут же пишут...
You should use this function instead of using mmap() with the MAP_PHYS flag
Однако, через mmap можно поставить флаг MAP_PRIVATE, который бы уберег от посеганий...
Кто знает, в чем причина такого "от учивания от mmap"?

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

И еще, Если сейчас я вручную посчитал где мне можно сделать окно в pci address space, то в итоге, есть большая вероятность, что кроме родной борды драйвер на других x86+tsi148 работать не будет, поскольку там может быть совсем другая карта pci адресов

Я сейчас еще, в добавок, копаю линуховый драйвер (правда под ядро 2.4 ток нашел). Дык вот там есть такой под по созданию памяти для окна мастера шины:
//----------------------------------------------------------------------------
// vmeSetOutBound
// Set attributes of an outbound window.
//----------------------------------------------------------------------------
int
vmeSetOutBound( vmeOutWindowCfg_t *vmeOut)
{
int windowNbr = vmeOut->windowNbr;
unsigned int existingSize;

if(vmepcimem == 0)
return(-ENOMEM);
if(vmeOut->windowSizeL == 0)
return(-EINVAL);

// Allocate and map PCI memory space for this window.
existingSize = out_resource[windowNbr].end - out_resource[windowNbr].start;
if(existingSize != vmeOut->windowSizeL){
if(existingSize != 0){
iounmap((char *)out_image_va[windowNbr]);
release_resource(&out_resource[windowNbr]);
memset(&out_resource[windowNbr], 0, sizeof(struct resource));
}
if(allocate_resource(vmepcimem, &out_resource[windowNbr],
vmeOut->windowSizeL, 0, 0xFFFFFFFF, 0x10000, 0,0)) {
printk("allocation failed for 0x%x-0x%x (0x%x) ", out_resource[windowNbr].start,
out_resource[windowNbr].end, vmeOut->windowSizeL);
return(-ENOMEM);
}

out_image_va[windowNbr] =
(int )ioremap(out_resource[windowNbr].start, vmeOut->windowSizeL);
if(out_image_va[windowNbr] == 0){
release_resource(&out_resource[windowNbr]);
memset(&out_resource[windowNbr], 0, sizeof(struct resource));
return(-ENOMEM);
}
}

vmeOut->pciBusAddrL = out_resource[windowNbr].start
- pci_bus_mem_base_phys(vmechip_bus);

switch(vmechip_devid) {
case PCI_DEVICE_ID_TUNDRA_CA91C042:
return(uniSetOutBound(vmeOut));
break;
case PCI_DEVICE_ID_TUNDRA_TEMPE:
return(tempeSetOutBound(vmeOut));
break;
}
return(-ENODEV);
}

Если я правильно понимаю, то выделением следующиего свободного за тундрой участка pci как раз и занимается allocate_resource. Если тут есть знатоки линуховых драйверов, подскажите, правильно ли я понял работу этой функции.
Далее ioremap. Получение виртуального адреса в адресном пространстве ядра linux по физическим адресам out_resource.start и out_resource.end.
Здесь еще одна тонкость, ядро линуха ведь работает в привилигированном режиме x86 процессора, так? А в QNX ведь драйвер работает в user mode?

Ну вот еще одна штука - pci_bus_mem_base_phys. тут они вычесляют начало области pci и сохраняют смещение от начала этой области...затем это значение выступает, как адрес начала окна..

PS/ Я понимаю, что линух и qnx это два разных мира на уровне архитектуры, но действия в линуховом драйвере все же заставили меня призадуматься...

PS2/ ed1k, как я понял вы работали с universe в частности, и с vme в целом. Есть ли в природе какие нить книжки, обзоры с примерами по VME. Я нашел лишь стандарт VME64, но он довольно сух и очень много аппаратных вещей(сигналы). Или все так учаться на VME, тут пост почитал, там пример кода урвал..?
По PCI я где-то даж книжку видел, но так как вы с vshemm'ом рассказали, даж там не было
Вобщем интересует что почитать мона по проблематике pci+vme

osDrummer
Есть ли в природе какие нить книжки, обзоры с примерами по VME. Я нашел лишь стандарт VME64, но он довольно сух и очень много аппаратных вещей(сигналы). Или все так учаться на VME, тут пост почитал, там пример кода урвал..?
По PCI я где-то даж книжку видел, но так как вы с vshemm'ом рассказали, даж там не было
Вобщем интересует что почитать мона по проблематике pci+vme

Стандарт по VME мне не удавалось найти. В компании, где я когда-то работал, были книги по VME. По Тундре - был datasheet в котором все было подробно расписано. По PCI - гугль вам наверняка выдаст ссылку на пдф спецификации 2.2 или новее, если вы поищете PCI local bus specification. Для бизнеса (а не взять на почитать-ознакомится) или за более свежей спецификацию всегда можно обратиться в pcisig, или как там называется этот комитет, и купить. Лучшей книжки по PCI, чем спецификация я не знаю.

ГОСТ Р МЭК 821-2000
(МАГИСТРАЛЬ VME)
http://rapidshare.com/files/135294446/821-2000.rar.html

По-русски читать конечно полегче. Спасибо, slonok!
Наши стандарты меня всегда умиляли ) Еще помню когда MIL_STD1553(Манчестер) изучал, раз эдак 20 прочел нашу версию стандарта, понял) ...НО! Прикол был в том, что мне, как программисту из этого стандарта было неоходимо процента 2 наверное знаний)))

vshemm, а Вы можете по outbound (master) регистрам Tsi148 подсказать?
Пока у меня нет модуля ввода вывода, но предположим, что
1. IO модуль находится по адресу 0x82000000 (A32)
2. Выбранным мной pci адрес 0xdc100000 окна

В стартовый адрес (otsal) заносим 0xdc100000
В эндовый адрес (oteal) заносим 0xdc100000+win_size, пусть win_size будет 0x10000 ~65Кб
В смещение (otofl) 0x82000000-0xdc100000=5a100000 ??

Как я понял все регистры с окончанием 'u' нужны только для 64 битной адресации, поэтому в них надо загнать нули.

PS. Возможно пример не жизненным, поскольку работу с реальной адресацией еще не имел, поправте если что..

кстати стандарт не наш...его тупо передрали(более менее грамотно перевели на русский)

А могут быть ситуации, что транзакция не проходит? Если так, то как выявить моста-убийцу ?

Процессор и host/pci bridge вам настраивать не нужно. Во время загрузки маленькие человечки уже обо всем позаботились

Не всегда так Более того, запрос от процессора может вообще не пройти дальше локальной шины (например, если эти данные обнаружатся в L1/L2 кеше).
Убийц приходится искать ручками (головой) и/или анализатором-осциллографом

Обычно менеджер устройств в ОС распределяет память, в том числе и для устройств. Т.е. память должна распределяться централизовано, иначе начнется бардак и кто-то на кого-то наедет.

Именно.

По линуховому драйверу.
allocate_resource() резервирует дочерний регион, чтобы на него ничто не налезло. Родителем
служит vmepcimem, который (если мне не изменяет память ) является зарезервированным регионом для
данной PCI шины.
Точно также должны действовать драйвера тех эзернетов, которые сидят на той же шине.
Вот тут как раз тонкий момент.
Линуховый драйвер делает минимум настроек шины, на которой сидит tsi148. По хорошему, нужно использовать глобальный
request_mem_region() для выделения, но ведь нет гарантии, что PCI-PCI/X мост не был запрограммирован
так, чтобы не транслировать адреса вне этого региона. Поэтому драйвер берет имеющийся диапазон
(resource_reserved d0000000-df000000 Bus1 - в Вашем случае), проверяет его размер (если он мал -
завершает работу), а затем выделяет внутри него куски для каждого из окон.
Далее, происходит вызов ioremap (хотя я бы сделал ioremap_nocache()) для трансляции физического адреса в виртуальный.
Проще говоря, по адресу d0000000 может быть смапирована, к примеру, RAM; ioremap вернет другой адрес, обращение
по которому после трансляции в MMU выльется в транзакцию по d0000000 на внешней шине.
pci_bus_mem_base_phys() - возвращает начальный адрес PCI address space относительно адреса на процессорной шине
(для каждой шины он может быт разным). На х86 я не встречался с отличным от нуля базовым адресом, поэтому
это ppc-specific Кстати, в линуховом драйвере очень много ppc-specific моментов

а Вы можете по outbound (master) регистрам Tsi148 подсказать?

К сожалению, сталкивался с этим давно и буду писать по памяти (так что обязательно проверьте!).
Есть 3 64-бит значения:
* otsal-otsau: стартовый адрес окна на PCI/X;
* oteal-oteau: конечный адрес окна на PCI/X;
* otofl-otofu: смещение VME адреса относительно PCI адреса.
Алгоритм такой: если адрес попадает в окно (см. первые два значения), прибавляем к нему смещение
(третье значение) и получаем VME адрес.
Когда VME адрес по абсолютному значению больше PCI адреса, все ок. Но когда меньше, должно случиться
переполнение, и тут я не уверен, что регистры с суффиксом u не учавствуют в A16-A32...

Ну, похоже начинает проясняться.
По крайней мере я теперь понял зачем до настройки окна был вот такой код с проверкой:
// Get parent PCI resource & verify enough space is available.
memset(&pcimemres,0,sizeof(pcimemres));
pcimemres.flags = IORESOURCE_MEM;
vmepcimem = pci_find_parent_resource(vme_pci_dev, &pcimemres);
if(vmepcimem == 0){
printk("Can't get VME parent device PCI resource"[img]http://qnx.org.ru/components/minibb/img/smilies/wink.gif[/img];
return(1);
}

if((vmepcimem->end - vmepcimem->start) < 0x2000000){
printk(" Not enough PCI memory space available %08x
",
(unsigned int)(vmepcimem->end - vmepcimem->start));
return(1);
}

Единственное, что осталось для меня не до конца подтвержденным, так это выравнивание или гранулярность, в коде это по разному называют...Так в вызове allocate_resource параметр align (alignment requested, in bytes) указан равным 0x10000 (65Kб). С другой стороны, при записи в конечный адрес окна испоьзуется такой ход:
pTempe->lcsr.outboundTranslation[i].oteal =
swp32(vmeOut->pciBusAddrL + (vmeOut->windowSizeL-0x10000));
Плюс, тундра в регистрах pci адреса хранит только его часть A32-A16.

Правильно ли я понимаю, что мы не можем выделить pci окно меньшее 65K для использования тундрой?
А если клиентский код хочет выделить окно, скажем, в 16 байт, то на уровне драйвера нужно выделить минимальный размер в 65К и контролировать смещение в окне, передаваемое приложением драйверу?

PS1. Возможно это не сильно изменит картину изложения, но все же уточню ряд фактов:
Вторая шина имеет немного другой диапозон, чем я упоминал выше: d8200000-dfffffff
На ней находятся:
Ethernet1: d8200000-d8220000, size 20000 ~128K
Ethernet2: d8220000-d8240000, size 20000 ~128K
Ethernet3: d8240000-d8260000, size 20000 ~128K
Ethernet4: d8260000-d8280000, size 20000 ~128K
Not used: d8280000-dc000000, size 3d80000 ~64M
TundraVme: dc000000-dc001000, size 1000 ~4K
Not used: dc001000-dfffffff, size 3ffefff ~67M
------
Получено запуском "pci-bios -v -B" и далее анализом через sloginfo и "pci -vv".

PS2. Драйвер действительно делался для ppc, а затем, как я понял, был перенесен на x86, с небольшими правками.

Да, гранулярность накладывает ограничения и на минимальный размер окна. Причем, 64К - это максимальная гранулярность (для A64 и A32). Для А24 и А16 она составляет 4к и 16 байт соответственно.

А если клиентский код хочет выделить окно, скажем, в 16 байт, то на уровне драйвера нужно выделить минимальный размер в 65К и контролировать смещение в окне, передаваемое приложением драйверу?

Угу

Ок. Для A64 и A32 понял, спасибо!
Но почему для A24 и A16 она другая? Ведь тундра игнорирует два младших байта регистров стартового и конечного pci адресов?
В спеке написано...
31:16 - STAL - Start Address Lower
15:0 - Reserved - N/A
STAL (Start Address Lower): This field determines the start address of a particular memory
area on the PCI/X bus which is used to access VMEbus resources. The value of this field is
compared with A31-A16 of the PCI/X bus address.
Или я чего то не так понял?

Еще вопросик. Из спецификации тундры выходит, что на одной процессорной плате можно запустить slave и master и вести между ними обмен данными (если запросы мастера попадают в адреса заявленные слэйвом). Так ли это в действительности и можно ли таким образом протестировать работу мастера и слэйва?

Все верно, Вы читаете про OTSAL, где сравниваются адреса с PCI/X bus, которая не может быть 24- или 16-бит. Поэтому гранулярность 64К всегда.
Когда же сравниваются адреса с VME bus (т.е. для Inbound, см. регистры ITSAL), там гранулярность другая.

Slave и Master одновременно на одной тундре запустить не получится, а вот замкнуть (если я правильно понял) Outbound на Inbound - нет проблем Только это никак не относится к мастеру и слейву...

Аа, в Inbound... Там согласен, дествительно, гранулярность разная.
Кста, хотя в спеке написано, что из ITSAL+offset делают pci/x space адрес, в линуховом драйвере не заморачиваются на allocate_resource для inbound окон, а просто делают malloc и virt_to_bus (включая ppc версию).
Очень похоже на ваше предположение о том, что контроллер запрограммирован на фиксированный диапозон только для outbound окон.

...

Просто у меня только проц. модуль пока..Вот и думаю как бы протестить оконную работоспособность

По поводу замкнуть. Вы имеете ввиду, что можно настроить outbound окно так чтобы генирируемые тундрой vme адреса попадали в диапозон vme адресов заданных в inbound окне той же самой тундры?
В таком случае, если я правильно понял, PCI target тундры (outbound) будет замыкаться на PCI master(inbound) тундры через ее Linkage Module и "устройства" VME мастер и слэйв в работу вовлечены не будут?

....Коллеги не поделитесь какими процессорными модулями и каких фирм(с Тундрой мостом) вы пользуетесь и почему?..=)

Пользовался vme ppc sbc от aitech defense systems, также смотрели на изделия братского предприятия curtiss-wright controls embedded computing. Почему? Это вопрос риторический. Иногда было действительно надо по условиям эксплуатации и требованиям заказчика, иногда - просто по привычке. Сейчас я не работаю с CWC engineered systems, и с железом с тундро мостами тоже не работаю.

to slonoc Fastwel CPC600

to vshemm Обнаружил еще одну, не сразу брасающуюся в глаза, деталь. OTSAL и OTEAL, игнорируя младшие 16 бит, "требуют" делать между окнами в pci "пропуски".
Так, если для первого окна (размером 64K) задаем:
OTSAL = 0xdc010000
OTEAL = 0xdc020000
(нельзя указать OTEAL = 0xdc01ffff)
То для второго (размером 64K) уже придется перескакивать через 64K:
OTSAL = 0xdc030000
OTEAL = 0xdc040000
Иначе (если у второго окна указать OTEAL = 0xdc020000) произойдет перекрытие диапозонов, так как тундра сверяет приходящий pci адрес по [OTSAL,OTEAL], включительно.

..сам юзаю CPC600 ..

ftp://79.173.81.105/-GLOBAL%20CHANGE-/Mamont/books_manuals/VME/

вот там немножко документов по VME

Так, если для первого окна (размером 64K) задаем:
OTSAL = 0xdc010000
OTEAL = 0xdc020000
(нельзя указать OTEAL = 0xdc01ffff)
То для второго (размером 64K) уже придется перескакивать через 64K:
OTSAL = 0xdc030000
OTEAL = 0xdc040000
Иначе (если у второго окна указать OTEAL = 0xdc020000) произойдет перекрытие диапозонов, так как тундра сверяет приходящий pci адрес по [OTSAL,OTEAL], включительно.

Конечно, включительно Нужно просто указать для первого окна
OTSAL = 0xdc010000
OTEAL = 0xdc010000
для второго
OTSAL = 0xdc020000
OTEAL = 0xdc020000
и разрывов не будет
А по вашим данным выделяются окна размером в 128к.

slonok
ftp://79.173.81.105/-GLOBAL%20CHANGE-/Mamont/books_manuals/VME/

вот там немножко документов по VME

На большинство файлов требует логин и пароль.

bessonov3
пароль:
anonymous
логин:
anonymous

...попробуйте браузер другой...
а ещё лучьше тотал командер..

vshemm
Конечно, включительно Нужно просто указать для первого окна
OTSAL = 0xdc010000
OTEAL = 0xdc010000
для второго
OTSAL = 0xdc020000
OTEAL = 0xdc020000
и разрывов не будет

Однако...До этого, исходя из тундрового мануала, я б точно не дошел..Спасибо. Попробую, как вы сказали. Сейчас, как раз пытаюсь замкнуть outbound на inbound.
Еще "фишки" есть, о которых стоит упомянуть ?

slonok
ftp://79.173.81.105/-G

Спасибо.

>Однако...До этого, исходя из тундрового мануала, я б точно не дошел..

...Вчитался вот в это предложение:
The outbound PCI/X address is decoded when the PCI/X address is greater than or equal to
the start address and less than or equal to the end address.
И вижу, что действительно можно вбить адреса без разрывов! Я как-то зациклился на приходящем (целом) pci адресе...а выходит, что тундре важно узнать лишь диапозон A32-A16 pci адреса, о чем и было прописано в мануале
Еще раз, спасибо vshemm, что обратили внимание на мое неверное трактование мануала