Tutup atau Tangani Pembatalan Data ketika transaksi AXI membalas kesalahan

Latar belakang

Saya memiliki sistem ZynqMP yang memiliki empat core Cortex-A53 (PS) bersama dengan logika FPGA (PL). Mereka mentransfer data melalui bus AXI.

Saya telah menempatkan beberapa Xilinx AXI Quad SPI dalam desain saya. Linux yang berjalan pada PS berhasil menyelidikinya, dan memulai daemon yang secara berkala (333 Hz) meminta MCU pada SPI untuk membalas potongan datanya (~ hingga sekitar 500 byte, dibagi setiap 64 byte.)

Mereka berfungsi dengan baik untuk sementara waktu (median 50 menit) tetapi tiba-tiba readl_relaxed() di driver SPI menyebabkan Pembatalan Eksternal Sinkron yang menyebabkan Kepanikan Kernel. Tampaknya ini adalah balasan kesalahan AXI menurut ARM TRM, dan mungkin dapat dipulihkan karena "sinkron" yang berarti register tidak rusak (menurut pemahaman saya.)

Setelah beberapa pencarian saya menemukan do_sea( ) fungsi yang menangani KLHS dan juga menemukan bahwa tidak ada peluang untuk pulih sesuai dengan implementasinya.

Saya ingin kesalahan AXI ditangani seperti: membuang pembacaan, mengembalikan SIGBUS dan mematikan proses, dll.

Tentu saja saya sedang men-debug Pembatalan dan mencari tahu mengapa hal itu terjadi tetapi saat ini saya tidak tahu.

Pertanyaan

Jadi pertanyaan saya adalah:

  1. Mengapa SEA tidak dapat dipulihkan dalam implementasi Linux arm64?
  2. Jika saya bisa "menangani" atau "mengabaikannya", bagaimana cara memodifikasi kode kernel Linux (Saya tahu ini bodoh tapi saya ingin tahu apakah ada caranya.)
  3. Apa yang bisa membalas error di Quad SPI IP? Readl_relaxed yang saya sebutkan di atas membaca data Rx FIFO.

person puhitaku    schedule 17.12.2018    source sumber
comment
Catatan yang sama sekali tidak terkait: C++1x, yang Anda referensikan di profil Anda, sekarang menjadi C++11.   -  person S.S. Anne    schedule 20.09.2019


Jawaban (1)


1) Saya belum pernah menempuh jalur ini, tetapi menurut saya jalur tersebut dapat dipulihkan jika inf->fn mengembalikan 0; yang berarti ghes_notify_sea() harus mengembalikan 0; dengan demikian salah satu sumber kesalahan SEA berhasil melaporkan kesalahan.

2) Saya rasa Anda memerlukan lebih banyak info. Saya akan mulai dengan mengubah driver/acpi/apei/ghes.c:732

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

yang akan memberi Anda lebih banyak informasi ketika kesalahan terjadi. Berbekal informasi tersebut, Anda perlu mencari tahu apakah Anda memiliki pengendali yang tidak berfungsi, atau hilang. Bagaimanapun, ini adalah tempat untuk mengatasinya.

3) Anda sedang berhadapan dengan implementasi ACPI. Ada 155 kloc di kernel ditambah jumlah yang tidak diketahui di firmware dan perangkat keras. Kode kernel tampaknya tidak menangani kondisi apa pun yang Anda hadapi. Pertama, Anda perlu menentukan tersangka mana yang terlibat dan interaksi apa yang gagal sebelum Anda dapat menggali akar permasalahannya.

Selamat Menggali!

person mevets    schedule 19.12.2018
comment
Terima kasih atas saran rinci Anda. Saya akan mencoba mendapatkan info lebih lanjut tentang pembatalan tersebut, dan kemudian menggali impl ACPI. - person puhitaku; 20.12.2018