[Dron_Gus 2]

Есть ядро arm1176jzf-s внутри s3c6410.

Суть проблемы: групповой pop отрабатывает неверно. Выяснилось, когда начал разбираться почему после вызова функции портится локальный указатель. Оказалось неверно восстанавливается из стека.

При этом

    push {r0, r1, r2, r3, r4, r5}
    pop {r0, r1, r2, r3, r4, r5}

Работает на ура. А вот:

    push {r4, r5, r6, r7, r10, lr}
    pop {r4, r5, r6, r7, r10, pc}

Уже не работает как надо. Делаем push {r4, r5, r6, r7, r10, lr}:

r4             0x57f7a000    1475846144
r5             0x57e77f70    1474789232
r6             0x57f7a000    1475846144
r7             0x2    2
...
r10            0x57039a10    1459853840
...
lr             0x570001a8    1459618216
pc             0x570001b4    0x570001b4 <clbss_l+36>

После pop {r4, r5, r6, r7, r10, pc}:

r4             0x57f7a000    1475846144
r5             0x57e77f70    1474789232
r6             0x57039a10    1459853840
r7             0x570001a8    1459618216
...
r10            0x57f7a000    1475846144
...
lr             0x570001a8    1459618216
pc             0x570001a8    0x570001a8 <clbss_l+24>

Порча стека исключена - иструкции идут друг за другом, прерывания выключены.

Стэк после push (после pop остается прежним):

0x57e77f28:    0x57f7a000    0x57e77f70    0x57f7a000    0x00000002
0x57e77f38:    0x57039a10    0x570001a8    0xffffffff    0xffffffff
0x57e77f48:    0x57f7a000    0x57e77f70

 

Что я забыл? Где посмотреть? Память проинициализирована верно, вроде как. Приложение до падения успевает отработать много кода с интенсивными обращениями к памяти.

 

[AlexandrY 2]

Нарушена целостность сигналов при работе с DDRAM

[aaarrr 63]

Нарушена целостность сигналов при работе с DDRAM

Слишком смелое утверждение. ТС даже не сообщил, включен ли кэш.

[Dron_Gus 2]

Включение кэша не влияет. Кэш только инструкций, т.к. MMU еще не включен.

Чтобы снять некоторые вопросы - отлаживаю последний u-boot на mini6410. Железо должно быть рабочим (Китацы клепают уже давно, тесты памяти не валятся, старый u-boot работает, с ним ядро запускается и плата стабильно работает).

Мне кажется, если бы проблема была в целостности сигналов, то неверно отрабатывалась бы и инструкция с другим набором регистров.

Что интересно. При выполнении pop {r4, r5, r6, r7, r10, pc}, регистры читаются не с SP +0, +4, +8, +12, +16, +20, +24, а с SP +0, +4, +16, +20, +8, +20.

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

Плюс предсказатель ветвлений вроде как следит за интрукциями вида pop {..., pc}.

Куда еще копать не знаю.

[VslavX 0]

Режим THUMB? Инструкция ассемблером кодируется правильно? (бинарный опкод - тот что нужно?)

Режимы ARM/THUMB при возврате не меняются? (тогда BX нужен)

[Dron_Gus 2]

Режим ARM. У всего приложения.

Опкод, вероятно, тот что нужен (вроде как gdb должен дизасемблировать, если пользоваться командой x/*i, а не брать отладочные данные).

Изначально это был пролог/эпилог большой сишной функции. Когда удалось выяснить, что именно портит регистры, код сократился до push и pop прямо в стартапе - поведение не меняется.

[Dron_Gus 2]

Проблема локализована. Ядро и периферия могут работать синхронно и асинхронно. В асинхронном режиме работает вылетает такой баг. В синхронном режиме такого нет. Но и максимальной производительности не получить.

 

З.Ы. в очередной раз "радуюсь" подробности самсунговской документации.