В приложении на Linux подразумевается обращение к On-Chip-SRAM, PIO и пр.
Доступ через mmap.
Но FPGA может быть не сконфигурирована. Или сконфигурирована неправильно.
Если FPGA не сконфигурирована, то
open("/mem/") возвращает нормальный файловый дескриптор
mmap возвращает указатель
выполнение операции
variable = pointer_to_mmap[index];
приводит к тому, что в HPS рабочей остаётся только кнопка Reset.
try{...} до catch{...} не доходит

известны ли кому-нибудь способы определить доступность периферии заранее?

FPGA - SoC Cyclone V

Сделайте в fpga регистр, в который будет заноситься сигнатура типа 0xaa55 при конфигурации и проверяйте её прямым чтением (inw (address)). А лучше написать свой драйвер и проверять готовность через ioctl, так правильней из userspace

А еще надежнее физически подключить вывод FPGA к GPIO HPS и выдавать лог сигнал о том что все ок.

подключить порт JTAG к микроконтроллеру, им же делать конфигурацию и из JTAG читать статус конфигурации - ОК или нет...
При таком подходе через JTAG ПЛИС можно делать сканирование и проверить припайку. Микроконтроллер же и будет этим заниматься...

А в чём разница? Это будет тоже самое обращение к периферии, которое также вероятно приведёт к зависанию линуха.

Почитайте про такой модуль как FPGA manager и про работу с ним. Он входит в состав HPS и отвечает за конфигурирование FPGA из под проца и мониторинг состояния FPGA. В hwlib для него написан драйвер, из под линуха тоже должно быть что-то. А заоодно почитайте вот эту тему. В ней вы узнаете о ещё одной проблеме, которая может возникнуть, когда FPGA грузится позже проца.

Да, я тоже сразу откинул варианты с регистром, всё равно его через mmap читать-писать.
В качестве альтернативного варианта избежать хотя бы части проблем решил считывать биты режима в регистре статуса модуля менеджера FPGA.
Они показывают, была ли вообще удачно загружена FPGA.

Но это тоже не очень хороший вариант. Потому что можно загрузить какую попало конфигурацию ПЛИС, биты режима покажут User mode, что говорит о успешной загрузке конфигурации, а при чтении-записи области без периферийныхустройств, ядро так же упадёт.

Ну так не надо какую попало. Туда загружется то, что туда загружают. Особых сбоев тут быть не должно. Но если этот момент принципиален, могу предложить два пути решения: а) копать в линухе, потому что зависания ненормальны, в bare metal, если fpga не загружена, то просто с регистров 0 читаются; б) попробовать как вариант поиграться с h2f_gp (general purpose signals, включаются в hps компоненте qsys), может быть получится передавать сигнатуру через этот интерфейс.

Да, согласен, не надо какую попало и вообще ошибки делать на надо, надо всегда всё сразу правильно делать. На ошибки только время зря тратится.

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

То, что в bare metal 0 читаются - интересно. Почему же тогда в Linux падение происходит?

Может потому, что по умолчанию в Линухе не производится включение мостов?

Вы меня не поняли. Читать надо не через mmap, а через io по прямому адресу, тогда ничего не зависнет. И делать это лучше в модуле ядра.

+1. В bare metal читаю по прямому адресу и всё норм. Даже если мосты не инициализированы, зависания нет, ибо его там и не должно быть.


Распространённое заблуждение. В случае HPS qsys необходим для генерации preloader'a. Настройки, которые вы делаете в hps компоненте через папочку handoff попадают в конфиги preloader'a с помощью утилиты generate bsp-editor'a. А загружена ли прошивка FPGA, собранная с данным qsys, или нет - без разницы, на HPS это не влияет, т.к. модули, которые вы конфигурите хардверные.

Простой пример. Вы хотите читать/писать NAND память с помощью встроенного ONFI контроллера. По-умолчанию проц вам этого не даст, однако, если вы подсунете ему preloader, собранный из qsys, где на NAND был разведён клок и выведены соотвествующие ноги, то всё заработает. FPGA при этом можно вообще не трогать.