Перейти к содержанию

Лабораторная 11.11 — Проба конкуренции между захватом IIO на хосте и управлением пакетом через gpreg

Цель

Определить, может ли текущий overlay курса поддерживать одновременно захват iio_readdev на хосте и управление пакетом gpreg со стороны PS, либо эти две операции мешают друг другу.

Инженерный вопрос

Текущий блокировщик это отсутствие RF-сигнала или более глубокая конкуренция между трактом захвата Linux IIO и прямым доступом devmem к блоку gpreg курса?

Скрипт

Файл Назначение
blocks/block_11_integrated_sdr_project/python/lab_11_11_iio_gpreg_contention_probe.py выполняет отдельные и перекрывающиеся сценарии захвата, снимает снимки axi_ad9361_adc_dma и записывает, какая сторона отказывает при перекрытии

Минимальный набор сценариев

Проба должна включать три сценария:

  1. отдельный захват iio_readdev;
  2. короткий перекрывающийся захват с почти немедленным запуском пакета;
  3. более длинный перекрывающийся захват с более поздним запуском пакета.

Этого достаточно, чтобы разделить:

  • «IIO не работает никогда»;
  • «gpreg не работает никогда»;
  • «оба работают по отдельности, но мешают друг другу при перекрытии».

Пример запуска

python blocks/block_11_integrated_sdr_project/python/lab_11_11_iio_gpreg_contention_probe.py \
  --ssh-host 192.168.40.1 \
  --ssh-user root \
  --ssh-password analog \
  --iio-uri ip:192.168.40.1 \
  --json-out docs/assets/lab111_iio_gpreg_contention_probe_live.json

Контракт отчёта

JSON-отчёт должен содержать:

  • состояние AD9361 до и после пробы;
  • один снимок регистров axi_ad9361_adc_dma до и после каждого сценария;
  • результат отдельного захвата;
  • результат перекрывающегося захвата;
  • результат помощника пакета при перекрытии;
  • последние строки dmesg после каждого сценария.

Интерпретация

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

Типичные исходы:

  • захват успешен, пакет отказывает с Bus error;
  • пакет успешен, захват отказывает по таймауту refill;
  • оба успешны, только когда не перекрываются.

Такие исходы указывают на проблему интеграции или арбитража вокруг живого проекта PL, а не на обычную настройку усиления RX или START_OFFSET.

Текущая живая заметка

Живое продолжение 2026-06-21 разделило проблему на два отдельных слоя:

  • отключение входа монитора тактов axi_gpreg_bpsk убрало прежний Bus error по адресу 0x79040004 во время перекрытия;
  • тот же пересобранный overlay всё равно нарушал стек RX-захвата Linux при горячей загрузке через fpga_manager на уже работающей системе;
  • после этой горячей перезагрузки доступ к gpreg восстанавливался, но отдельные захваты iio_readdev возвращали таймаут refill Unknown error (110);
  • ручной fpga load U-Boot того же bitstream до загрузки Linux показал, что более старый overlay «убрать DAC DMA из PL» вызывает панику ядра в axi_dmac_probe(), то есть стоковое дерево устройств Linux по-прежнему ожидает наличия этого пути TX DMA в железе;
  • попытка восстановить путь RX DMA через unbind / bind платформенного драйвера Linux вызвала kernel oops в dma_channel_rebalance().

Второе живое продолжение 2026-06-23 ещё сузило режим отказа:

  • исправленная нагрузка bridge_txrx_mux с перестановкой слов снова была горячо загружена из базовой линии стокового shell через fpga_manager;
  • хост по-прежнему видел трёхустройственный контекст IIO (ad9361-phy, cf-ad9361-dds-core-lpc, cf-ad9361-lpc) после перезагрузки;
  • axi_gpreg также снова стал читаемым, а помощник пакета повторил известный результат done + timeout, tx_valid_count = 2376, rx_valid_count = 0, received_bits = 0;
  • однако короткий захват iio_readdev по таймеру всё равно возвращал таймаут refill Unknown error (110) с нулём отсчётов;
  • компактная безопасная по мощности RF-развёртка по нескольким комбинациям START_OFFSET, усиления RX и ослабления TX по-прежнему не дала активности на стороне RX.

Третье живое продолжение 2026-06-23 убрало последнюю оставшуюся неоднозначность стокового shell:

  • специальный помощник сравнения blocks/block_11_integrated_sdr_project/python/lab_11_13_stock_vs_runtime_rx_compare.py подтвердил, что свежий стоковый shell по-прежнему поддерживает и прямой захват libiio Buffer.refill() на хосте, и короткий захват iio_readdev до какой-либо перезагрузки overlay;
  • затем тот же помощник горячо загрузил исправленную нагрузку через fpga_manager, снова подтвердил чтение axi_gpreg и воспроизвёл тот же runtime-отказ на обоих RX-путях хоста: libiio отказал с OSError: [Errno 110] host unreachable, а iio_readdev с таймаутом refill Unknown error (110);
  • то же сравнение также показало, что cf-ad9361-dds-core-lpc меняется с sync_start_enable = arm в стоковом shell на sync_start_enable = disarm после runtime-перезагрузки.

Практический вывод: блокировщик теперь уже, чем «runtime-перезагрузка ломает всё». Базовая линия стокового shell исправна, текущий runtime-образ сохраняет fpga_manager, axi_gpreg и базовое перечисление IIO живыми, но тракт RX DMA / refill по-прежнему не доставляет пригодных отсчётов, а мост по-прежнему не видит RX-valid трафика. Не используйте живую перезагрузку fpga_manager вместе с перепривязкой драйверов как обычный рабочий процесс курса, пока плата не будет заново проверена после чистой загрузки.

Шаблон инженерного вывода

Отдельный захват IIO ______.
Короткое перекрытие вызвало ______.
Длинное перекрытие вызвало ______.
Следующий шаг — проверить ______ перед дальнейшими развёртками BER.