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

Фон

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

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

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

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

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

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

Вопрос

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

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

arm64 linux-kernel arm embedded abort
person puhitaku    schedule 17.12.2018    source источник
comment
Совершенно не относящееся к делу примечание: C++1x, на который вы ссылаетесь в своем профиле, теперь называется C++11.   -  person S.S. Anne    schedule 20.09.2019

Ответы (1)


arrow_upward
1
arrow_downward

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 плюс неизвестное количество в прошивке и железе. Код ядра, по-видимому, не справляется с любым условием, с которым вы столкнулись. Сначала вам нужно определить, кто из этих подозреваемых вовлечен и какие взаимодействия не работают, прежде чем вы сможете выяснить основную причину.

Удачных копаний!

person mevets    schedule 19.12.2018
comment
Спасибо за ваше подробное предложение. Я попытаюсь получить больше информации о прерываниях, а затем покопаюсь в реализации ACPI. - person puhitaku; 20.12.2018