Отклонить или обработать прерывание данных, когда транзакция AXI отвечает на ошибку - PullRequest
Новая
       97

Отклонить или обработать прерывание данных, когда транзакция AXI отвечает на ошибку

0 голосов
/ 17 декабря 2018

Фон

У меня есть система ZynqMP, которая имеет четыре ядра Cortex-A53 (PS) наряду с логикой FPGA (PL).Они передают данные через шину AXI.

Я поместил в свой дизайн несколько Xilinx AXI Quad SPI.Linux, работающий на PS, успешно проверяет их и запускает демоны, которые периодически (333 Гц) запрашивают микроконтроллеры на SPI отвечать на их порцию данных (~ до 500 байтов, разделенных на каждые 64 байта).

Онинекоторое время работает хорошо (в среднем 50 минут), но внезапно readl_relaxed () в драйвере SPI вызывает синхронную внешнюю отмену, которая приводит к панике ядра.Похоже, что это ответ AXI об ошибке в соответствии с ARM TRM , и он может быть восстановлен, потому что он «синхронный», что означает, что регистры не повреждены (в моем понимании).

После некоторого поискаЯ обнаружил функцию do_sea () , которая обрабатывает SEA, а также обнаружил, что нет возможности восстановить ее в соответствии с реализацией.

Я хочу обработать ошибку AXI следующим образом: отброситьпрочитайте, верните SIGBUS и возглавьте процесс, который нужно уничтожить, и т. д.

Конечно, я отлаживаю прерывание и нахожу причину, по которой это происходит, но в настоящее время я понятия не имею.

Вопрос

Итак, мои вопросы:

  1. Почему SEA не восстанавливаются в реализации Linux arm64?
  2. Если я могу «обрабатывать» или «игнорировать» это, как мне изменитьКод ядра Linux (я знаю, что это глупо, но я хотел бы знать, есть ли способ.)
  3. Что может ответить на ошибку в Quad SPI IP?Упомянутый выше readl_relaxed читает данные Rx FIFO.

1 Ответ

0 голосов
/ 19 декабря 2018

1) Я никогда не шел по этому пути, но мне кажется, что они могут быть восстановлены, если inf-> fn вернет 0;это означает, что ghes_notify_sea () должна вернуть 0;таким образом, один из источников ошибок SEA успешно сообщил об ошибке.

2) Я думаю, вам нужно немного больше информации.Я бы начал с изменения драйверов / acpi / apei / ghes.c: 732 

from:
rc = ghes_read_estatus(ghes, 0);
to:
rc = ghes_read_estatus(ghes, 1);

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

3) Вы имеете дело с реализацией ACPI.В ядре 155 kloc плюс неизвестное количество в прошивке и оборудовании.Код ядра, по-видимому, не обрабатывает условия, с которыми вы сталкиваетесь.Прежде всего вы должны определить, кто из этих подозреваемых участвует и какие взаимодействия терпят неудачу, прежде чем вы сможете выявить основную причину.

Happy Digging!

...