Приветствую!

Делаю очередной проект c PCIe - в ожидании целевого железа балуюсь с Xilinx dev-board для Kintex UltaScale KCU105. Тестовый комп на десктопной ASUS. Слепил проект с XDMA PCie коркой и контроллером DDR4 на 1GByte. В PCIe два 32bit BARа по 1 MByte. Погоняли данные туда-сюда все ок.

Затем программист говорит - хочу мол видеть всю DDR4 память через BAR. Включаю на XDMA bypass канал - ставлю ему 32bit BAR в 2GByte размером. Загружаю проект в dev-board. После рестарта наслаждаюсь собственной копией картины Малевича "Черный Квадрат" 8-()
После первого культурного шока выясняется что эта"картина" теперь у меня надолго так как тестовый комп даже без FPGA dev-board показывает только ее. Пока сисадмин ищет другую мамку ставлю для проверки dev-board в целевой комп (серверная SuperMicro) вижу что с dev-board все ок - PCie нормально конфигурится, видны 2 BAR в 1 MGByte и один BAR 2GByte.

Что ж - бывает - приносят другую мамку (на это раз десктопный Gigabyte GA-HB1M) втыкаю туда, включаю. Получаю вариацию на тему картины Мунка "Крик" - в смысле в bios не войти, на экран выводит что-то не понятное, клава и мыш не работают ну и мне хочется кричать "Что за фигнняяя...?" Хорошо хоть это только при вставленной в комп FPGA карте. Ну думаю мамка старая дешевая переживает что в нее воткнули платку в 40 раз дороже чем она сама вот и истерит.
Ладно - один раз случайность - 2 раза совпадение ставлю в третий комп (опять десктопный ASUS H97-Plus) - получаю еще одну копию Черного Квадрата (ни кому не нужно ? 1/10 цены оригинала ).

Откатив проект для FPGA и уменьшив размер bypass PCIe BARA до 1 MByte на плате от Gigabyte стало тоже работать нормально. На платах от ASUS судя по всему затерло BIOS так как ни каким сбросом CMOS ничего не восстанавливается. И это просто на этапе BIOS конфигурации PCIe устройств!.

Удачи! Rob.

Думаю, что поломался не код BIOS, а ESCD/DMI data, они вполне законно обновляются именно при конфигурации устройств. Жаль, что материнки обычно не умеют очищать DMI data без входа в BIOS setup, а умеют только глючить .

RobFPGA, гигабайтовская мать кажется с dualbios. Может поэтому она после изъятия платы завелась?

Приветствую!


Да так и есть - но она и глючила по другому - после ресета с минуту думает работать или нет потом выдавала белиберду или иногда сообщение о "отсутствии устройств загрузки" и при этом ни клава ни мыш не жили. Если FPGA плату вытащит то начинает работать как в ни в чем небывало - все настройки сохраняются.

ASUS мамки же после первого включения сразу в даун с черным экраном.
В понедельник попытаюсь слепить SPI программатор проверить BIOS - благо на одной мамке ASUS (h97-plus) flash DIP8 на панельке!

Удачи! Rob.

не всякий BIOS долетит до середины Днепра тьфу, выделения из нижних 4 ГБайт BAR-а в 2 ГБайт.
Собс-но, потому что это никому не нужно.

У меня эксперименты в 2009 году упирались в 512 МБайт, так что радуйтесь, что хоть где-то вам удалось.

Вообще вся эта затея (замапить 2Г на BAR) изначально отдавала неслабой такой степенью бессмысленности и задумывалась в чисто отладочных целях.
Для подобных задач обычно пользуют косвенную адресацию (см. например как работают VGAшки через окно в 64к). Либо в случаях когда нужна скорость
(наиболее частый случай) запиливают нормальный DMA co scatter-gather и прочими плюшками.
А иметь доступ из BAR в память DDR напрямую имеет смысл лишь для "поиграться", ибо одиночный транзакции сразу угробят всю производительность DDR памяти.

Приветствую!

Я и не планировал использовать 2GByte BAR в целевом железе, это как раз предполагалось для отладки и различных экпериментов. Кто ж знал что производители материнок такую свинью подложат .
Ну не можешь ты выделить в BIOS большое окно для BAR так грязно выругайся на экран и все - нет же совершим суицид назло юзеру - поднимем продажи!.

У меня похожее было в другой системе. Но она была на базе PowrPC c VxWorks. Там при старте честно писало что "не может выделить" запрошенные 16 GByte BAR так как лимит окна для мапинга PCIe только 1.5 GByte.

Удачи! Rob.

Вообще я с трудом могу понять как можно таким простым способом перезаписать BIOS (если произошло именно это). Запись во флэшку - нетривиальная операция, и случайно её сделать сложно. Кроме того у флэшек предусмотрены разные софтовые защиты от случайной записи.

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

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

Приветствую!

Слепил на макетке из го....орстки (а по другому и не скажешь) деталей SPI программатор. Прошил файлом bios с сайта ASUS. Правда перед этим надо отрезать первые 2K поскольку там судя по всему собственно загрузчик.
Мамка H97 ожила. При этом ни один bios c ASUS сайта не совпадал с тем что вычитал из flash.

И ни каких защит при этом во flash не стояло - все внутренние protection биты были сброшены. Не зря же чип на панельке стоит - ох не зря .

Удачи! Rob.

содержимое флешки не совпало скорее всего по причине Intel ME.
Дело в том что тот самый Management Engine изначально позиционировался как инструмент для "проверки по ТУ" при запуске платы после пайки.
Не завелась - в брак.

А в том, что выложено в качестве "апдейтов" на оффсайте может содержать совсем другие данные для ME. Либо содержать только минимальный загрузчик.

Уважаемый RobFPGA, а вы не хотите попробовать ещё раз убить ожившую мать вашим фирменным способом, а потом считать её содержимое и сравнить? Возможно это даст ключ к пониманию?

Сообщение отредактировал Inanity - Feb 2 2016, 19:20

Я правильно понимаю, что эти таблицы (там видимо расписаны назначенные системные ресурсы типа окон памяти, портов I/O, прерываний и т.д. для каждой plug&play железяки) строятся динамически, то есть по каждому рестарту обновляются. Зачем тогда их писать во флэш и тем более зачем потом эту информацию использовать при следующем старте до нового динамического распределения ресурсов? Не вижу логики... В таком раскладе любая безумная конфигурация может "убить" БИОС напрочь с первого раза. Как-то не дуракоустойчиво...

DMI & ESCD - это защита вендоров от "пихания всякого".
При загрузке туда пишется всё, чего понавтыкали. Если после этого материнка перестанет работать и уйдёт по RMA, то первое на что будут смотреть - это в этот кусок флеша.

вообще DMI & ESCD уже устарели, замена называется CIM: http://www.dmtf.org/standards/cim