Cortex-A9 SMP GICC_RPR всегда будет 0, прерывание не сработало

Question

контекст

На плате i.MX6Quad, когда система работала, я обнаружил, что Core3 не может справиться с каким-либо прерыванием.

Посмотрите регистры интерфейса GIC по Trace32, значение GICC_RPR всегда равно 0, что означает, что выполняется событие с наивысшим приоритетом, поэтому он объясняет вопрос uppon: событие с более низким приоритетом не может быть обработано.

Вопрос

Я вставил инструкцию: запишите 0 в GICC_EOI, что может изменить GICC_RPR на приоритет холостого хода (0xFF), но это не работает, оставьте 0.

Цель

Я хочу сделать приоритет сброса и деактивировать успех.

Рекомендации

• gic arch specf: 3.2.1 Сброс приоритета и деактивация прерываний

Снижение приоритета - это падение приоритета "Выполнение", которое происходит при действительной записи> в EOIR, либо в GICC_EOIR, либо в GICC_AEOIR.

При снижении приоритета рабочий приоритет уменьшается с приоритета прерывания, на которое ссылается запись EOIR, либо на

Answer 1

Запись Zero в EOI не помогает. Когда прерывание срабатывает, вы должны прочитать регистр GICC_IAR. Полученное вами значение - это номер прерывания, который сработал. Если вы находитесь в унаследованном режиме, вы должны записать этот номер прерывания в EOI, чтобы удалить это прерывание. Если вы находитесь в режиме сброса приоритета, запись этого числа в EOI уменьшает приоритет, а запись того же значения в DI отменяет прерывание (проверьте GICC_CTLR для подтверждения вашего режима). Надеюсь, что это устранит путаницу с RPR и EOI.

Некоторые указатели для устранения вашей проблемы: 1. Проверьте регистры GICD_ITARGET, чтобы увидеть, что есть прерывания, направленные на CPU3. 2. Убедитесь, что прерывания, которые вы ожидаете в CPU3 (если что-то конкретное), не маскируются в распределителе. 3. Проверьте GICC_PMR для CPU3, чтобы убедиться, что приоритет не слишком высок. Прерывание пересылается от дистрибьютора к интерфейсу процессора, только если его приоритет выше значения в этом регистре. 4. Проверьте, включен ли интерфейс CPU для CPU3. 5. Проверьте GICD_ISPEND, чтобы узнать, ожидает ли рассматриваемое прерывание

ПРИМЕЧАНИЕ. Будьте внимательны при использовании T32 для отладки GIC. T32 работает путем чтения значений из регистров / памяти. Это оказывает нежелательное влияние на некоторые регистры GIC, например, регистр GICC_IAR может считывать только один раз, чтобы подтвердить прерывание. Дальнейшее чтение вернет ложные номера прерываний. Когда T32 подключен и открыто окно для чтения регистров GICC, это вызовет "потерянное" прерывание, о котором никто не сможет позаботиться. Я бы предложил внести в логи логику обработки прерываний для устранения проблем.