[_4afc_ 25]

В ПК с ОС Ubuntu 20.04.06 LTS и установленной в слот PCIe платой с ПЛИС:

• Плата не видится после подачи питания, появляется только после перезагрузки ОС. Метод проверки: lspci -t
• Кроме того, если на включенном ПК начать менять прошивку ПЛИС - Ubuntu повисает.

 

Вопросы:

1. есть ли на Ubuntu некая команда "rescan PCIe" для подключения устройств на горячую?
2. можно ли сделать "unmount" PCIe устройства на период прошивки, а затем "mount/rescan"?

[new123 0]

вы же сами ответ написали )

echo 1 > /sys/bus/pci/rescan

если плата до этого уже была на pcie, то желательно перед этим сделать ее remove таким же способом

echo 1 > /sys/bus/<путь до платы>/remove

или 

echo 1 > /sys/bus/<путь до платы>/unbind

соответственно, если на нее подцеплен еще драйвер, то и его заранее выгрузить желательно, чтоб ресурсы отдал

Изменено 7 марта пользователем new123

[_4afc_ 25]

2 hours ago, new123 said:

вы же сами ответ написали )

echo 1 > /sys/bus/pci/rescan

Это работает если плата определилась. Действительно её можно remove и потом найти rescan.

 

А вот после первой подачи питания - rescan не помогает.

 

Может есть команда для Ubuntu/BIOS ожидать медленно стартующие PCIe сколько-то секунд?

[new123 0]

Давайте больше данных )

Во время старта ПК, bios начинает через какое то время проводить pcie enumeration, он там обычно пишет слева внизу. У платы в этот момент должно быть готово питание и она должна с этого момента в течении 100млсек пройти обучение. Такой вроде стандарт.

Чтобы плата умела при подаче питания пройти enum, как минимум она должна уметь hot plug через свой пин делать и линукс должен быть тоже сконфигурирован. Надо проверить вводные данные. 
 

[_4afc_ 25]

1 hour ago, new123 said:

Во время старта ПК, bios начинает через какое то время проводить pcie enumeration, он там обычно пишет слева внизу. У платы в этот момент должно быть готово питание и она должна с этого момента в течении 100млсек пройти обучение. Такой вроде стандарт.

На экране biosа пока не заметил, а логи инициализации PCIe в Ubuntu есть или важно именно bios до Ubuntu смотреть?

 

1 hour ago, new123 said:

Чтобы плата умела при подаче питания пройти enum, как минимум она должна уметь hot plug через свой пин делать и линукс должен быть тоже сконфигурирован. Надо проверить вводные данные.

По схеме PCIe:

A1_PRSNT#1 - в воздухе, можно замкнуть на

• B17_PRSNT#02 (X1)
• B31_PRSNT#02 (X4)

A11_PERST KEY - заведена на ПЛИС и сбрасывает корку (можно притянуть к 0/1)

B11_WAKE#KEY - в воздухе

 

Думаете стоит соединить A1-B17 в режиме x1 или A1-B31 в режиме x4? А как оно после ресета работает без этой перемычки?

 

PS: Добавление перемычки - не добавило определения после подачи питания.

[soldat_shveyk 2]

21 hours ago, _4afc_ said:

Плата не видится после подачи питания, появляется только после перезагрузки ОС

Через сколько ms после подачи питания FPGA сконфигурирована и готова к работе по PCIe?   OC видит плату после перезагрузки компа возможно потому, что на момент перезагрузки FPGA уже сконфигурирована. 

[_4afc_ 25]

1 hour ago, soldat_shveyk said:

Через сколько ms после подачи питания FPGA сконфигурирована и готова к работе по PCIe?   OC видит плату после перезагрузки компа возможно потому, что на момент перезагрузки FPGA уже сконфигурирована. 

Есть возможность запитать плату отдельно и лишь потом включить ПК. Очевидно в этом варианте ПЛИС уже сконфигурирована. 

Возможно она медленно реагирует на PCIe сброс или настройку трансиверов. 

Но непонятно почему времянки ресета - устраивают. 

[blackfin 16]

On 3/8/2024 at 9:59 AM, _4afc_ said:

Есть возможность запитать плату отдельно и лишь потом включить ПК. Очевидно в этом варианте ПЛИС уже сконфигурирована. 

Возможно она медленно реагирует на PCIe сброс или настройку трансиверов. 

Но непонятно почему времянки ресета - устраивают. 

PG054:

Quote

The PCI Express Specification states that PERST# must deassert 100 ms after the power good of the systems has occurred, and a PCI Express port must be ready to link train no more than 20ms after PERST# has deasserted. This is commonly referred to as the 100 ms boot time requirement.

 

[faa 4]

В 07.03.2024 в 15:57, _4afc_ сказал:

По схеме PCIe:

A1_PRSNT#1 - в воздухе, можно замкнуть на

• B17_PRSNT#02 (X1)
• B31_PRSNT#02 (X4)

A11_PERST KEY - заведена на ПЛИС и сбрасывает корку (можно притянуть к 0/1)

B11_WAKE#KEY - в воздухе

 

Сигналы PRSNT# (соответствующие количеству используемых линий х1 х4 х8 х16) при установленном в слот устройстве должны иметь низкий уровень.

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

Первоначальная енумерация устройства при холодном старте или холодной перезагрузке производится биос/уефи,

причем время готовности устройства к этой процедуре лимитировано (после окончания сигнала сброса 100мсек).

[_4afc_ 25]

7 hours ago, faa said:

Первоначальная енумерация устройства при холодном старте или холодной перезагрузке производится биос/уефи,

причем время готовности устройства к этой процедуре лимитировано (после окончания сигнала сброса 100мсек).

Ок. Плате дано 100мсек на реакцию по ноге A11_PERST KEY.

1. С чего при ресете PC вдруг Ubuntu считает, что времени хватило, а при подачи питания не хватило, даже если на плате PCI есть постоянное внешнее питание и для неё эти события вероятно одинаковы?
2. Можно проверить со стороны железа что устройство не готово к энумерации или что ему дали 100мс, а не 30? Например  обычным осциллографом увидеть какой именно сигнал пошел после A11_PERST KEY? Не проверять же что глаз раскрылся на GTP за 100мс...
3. Или со стороны Ubuntu по логам, типа: вижу старт в слоте PCIe, но потом неверный ответ, содержимое BAR - отправили в чёрный список.

[faa 4]

В 09.03.2024 в 11:04, _4afc_ сказал:

Ок. Плате дано 100мсек на реакцию по ноге A11_PERST KEY.

1. С чего при ресете PC вдруг Ubuntu считает, что времени хватило, а при подачи питания не хватило, даже если на плате PCI есть постоянное внешнее питание и для неё эти события вероятно одинаковы?
2. Можно проверить со стороны железа что устройство не готово к энумерации или что ему дали 100мс, а не 30? Например  обычным осциллографом увидеть какой именно сигнал пошел после A11_PERST KEY? Не проверять же что глаз раскрылся на GTP за 100мс...
3. Или со стороны Ubuntu по логам, типа: вижу старт в слоте PCIe, но потом неверный ответ, содержимое BAR - отправили в чёрный список.

Тут смотрели?

1. Питание от слота используется? Ресет по кнопке (или reboot с командной строки или "power_cycle" через ipmi) - это "горячий" рестарт, питание с платы не снимается, прошивка ПЛИС перезагружаться не должна. (ipmi - если есть BMC на хостовой плате с поддержкой ipmi).

"Холодный" рестарт -  со снятием питания, на слотах остается только "дежурное" слаботочное 3.3В (poweroff или "power_down", комстрока или ipmi соот-но).  Можно еще из розетки выдернуть (отключить от UPS) - это самый "холодный" рестарт, дежурное питание тоже пропадет.

2. 100мсек - это по спецификации PCIe (гуглить pcie 100ms). Что вы хотите смотреть осциллографом? Сигналы на линиях RX-TX? Там даже в gen1 больше гигагерца (2.5Гбс/2). У вас есть осциллограф с такой полосой, щуп соответствующий, согласование подключения щупа к линии обеспечиваете? Можно изнутри ПЛИС посмотреть, что, когда и так ли происходит (см.ссылку выше). "Глаз" на линиях можно посмотреть: при подключении через свитч/ретаймер (софт от производителей свитчей/ретаймеров); средствами xilinx (см.тут)

3. См. по первой ссылке. Там есть примеры команд.

[makc 192]

47 минут назад, faa сказал:

У вас есть осциллограф с такой полосой, щуп соответствующий, согласование подключения щупа к линии обеспечиваете?

Начало Link Training (receiver detection) можно прекрасно увидеть даже с помощью 100 МГц Ригола. А далее уже глядя на LTSSM разбираться, что происходит. Здесь идёт речь не о тонких материях в типа закрывающегося глаза, а о качественной проверке и понимании происходящего, КМК.

[dxp 34]

А что, 100 мс нынче -- это реальная проблема? Это требование на ATX системах тянется из старых версий стандарта, когда процы были простыми и поднимались шустро. Сегодня же даже дескоптный процессор -- это сложнючая система на кристалле, которая стартует долгие секунды (это можно наблюдать при включении компа), а уж на серверах это вообще запредельно долго -- специально замерял время от включения до подъёма линка на каком-то Xeon'е, довольно старом уже, там оно составляло 29 секунд! Выглядело так: включил питание, на мониторе (подключил VGA к серверу) чёрный экран, висит всё это долгие секунды, потом появляется приглашение BIOS и в ту же секунду поднимается линк. Т.е. енумерация там пролетает почти мгновенно, а основное время процессор находится "в себе", что-то проверяет, память тестирует. 

Кроме этого я ещё осциллографом посмотрел тайминги поднятия питания и сигнала сброса. Там времена от Power Good до сброса PCIe существенно больше 100 мс. Т.е. если загрузка FPGA происходит сразу после подачи питания, то эта задержка + гарантированные 100 мс дают достаточно времени для прихода устройства в готовность (там речь шла об Artix-7).

Я так подробно это смотрел, потому что тоже запаривался насчёт требования 100 мс готовности, и Artix-7 xc7a200t (самый толстый то есть) никак не успевал загрузиться за 100 мс. Даже при внешнем клоке (EMCLK) с оптимизацией времянок по QSPI всё равно выходило существенно больше 100 мс (то ли 130, то ли под 200, не помню уже). Но производитель не парится на эту тему, и понятно почему. Тандемной загрузки у этой FPGA нет, она начинается у Kintex. Но оказалось, что реальной проблемы на современных x86 нет -- сложная система приходит в готовность несоизмеримо дольше, чем 100 мс.

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

[blackfin 16]

On 3/10/2024 at 8:07 AM, dxp said:

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

Так в самом стандарте PCIe написано, что для настройки режима работы линка PCIe не требуется участие ни BIOS'а, ни OS'и.

Эквализацию и тестирование линка выполняет простая FSM на 32 состояния. Она и линк поднимает в режиме PCIe Gen1.

Когда BIOS начинает энумерацию устройств на шине, шина уже должна работать.

А если FSM обнаружила, что линк не дошел до состояния L0, она может просто сообщить BIOS'у, что линк неисправен.

Всё - IMHO, ессно..

[makc 192]

37 минут назад, dxp сказал:

А что, 100 мс нынче -- это реальная проблема?

Да, это вполне реальная проблема. На серверах её встретить сложно, а вот на десктопах и ноутах в М.2 - довольно легко.