Производительность SAM9XE, непонятки с этим процом Опции

[EugenB2]

Имеется платка с SAM9XE512, все запускает, шьется, работает. Но есть одно неприятное НО. Решил я затестить производительность сей штуки. Сделал тупо просто:
t=GetTickCount(); 1ms тики
for(k=0;k < 6600000; k++); подобрал, чтобы 1секунду примерно
t=GetTickCount()-t; равно 1000
(вообще сделал вывод в DEBUG и компом проверил отсчет 1 секунды)

Итак получаем в дизасме(позже выложу), что цикл занимает 5 инструкций, одна из них 2такта . Итого 7 тактов.
Итак 7*6600000=46200000 46 MIPS
Потом включаю ICache. Вуаля, производительность сразу в два раза 92мипса.
А теперь вопрос! Где обещанные 200MIPS????? Или я где-то ошибся?

Сообщение отредактировал EugenB2 - Jan 14 2010, 21:06

[vmp]

Я пользуюсь примером EugenB2. Единственное, я маплю адреса Boot Memory на Flash, поэтому первая запись TT 0x00000C1A.

В третий раз повторяю - первая запись должна быть 0x00200C1A.

Если использовать SRAM, то необходимо его дробить на мелкие страницы?

Зачем? Его и так мало. Тогда проще вообще не заморачиваться с кешированием, оставить только один I-cache, который не требует включения MMU.

[aaarrr]

Попадаю из первого обращения к стеку.

Куда в этот момент указывает SP?

Я пользуюсь примером EugenB2. Единственное, я маплю адреса Boot Memory на Flash, поэтому первая запись TT 0x00000C1A.

Режим кэширования (WB или WT) никакого значения не имеет.

Когда отключаю DCache, убираю запись в TT 0x00300C1E (SRAM) - попадаю в Data Abort. То же, если TT не исправлять.

Очень похоже, что вы пытаетесь обратиться к памяти, которой физически не существует. Кэш в режиме WT просто маскирует этот косяк. Попробуйте исправить запись на 0x00300C1A - должны тоже получить abort.

Если использовать SRAM, то необходимо его дробить на мелкие страницы?

Нет.

В третий раз повторяю - первая запись должна быть 0x00200C1A.

Еще раз спрашиваю: почему? Ответ "потому что иначе не работают прерывания" совершенно не устраивает.

В некешируемой области биты С и B должны быть равны 0 (некешируемая и небуферируемая).

Ну, буферизацию как раз можно оставить - зачем гробить производительность окончательно? Благо буфер записи легко очистить перед запуском DMA.

[V_M_Luck]

Похоже, что все-таки я неправильно настраивал ТТ.
Вариан тпервых записей, с которыми я мог отключать и подключать DCache:
0x00200C1A, 0x00100C1A,0x00200C1A,0x00300C1E

Еще раз спрашиваю: почему? Ответ "потому что иначе не работают прерывания" совершенно не устраивает.

Первая запись существенна. Хотя действительно, это совершенно не очевидно.

Нет.

Я имел ввиду, если под DMA выделить часть SRAM, отключив в ней кэширование и буферизацию.
В общем я так и сделал. Описал таблицу дескрипторов второго уровня и дал 1 КБ SRAM под DMA.

Кстати: в PDC нужно указывать физические, а не виртуальные адреса. Как-то не удобно...


Похоже, что все-таки я неправильно настраивал ТТ.
Вариан тпервых записей, с которыми я мог отключать и подключать DCache:
0x00200C1A, 0x00100C1A,0x00200C1A,0x00300C1E

Еще раз спрашиваю: почему? Ответ "потому что иначе не работают прерывания" совершенно не устраивает.

Первая запись существенна. Хотя действительно, это совершенно не очевидно.

Нет.

Я имел ввиду, если под DMA выделить часть SRAM, отключив в ней кэширование и буферизацию.
В общем я так и сделал. Описал таблицу дескрипторов второго уровня и дал 1 КБ SRAM под DMA.

Кстати: в PDC нужно указывать физические, а не виртуальные адреса. Как-то не удобно...

[aaarrr]

Первая запись существенна. Хотя действительно, это совершенно не очевидно.

Пока не станет очевидно, все действия можно приравнять к битью в бубен.
Мапить что-то вручную в нулевой адрес может понадобится только в двух случаях:
1. Если не установлен GPNVM[3], но тогда процессор стартовал бы с ROM
2. Если "случайно" выполняется ремап

Я имел ввиду, если под DMA выделить часть SRAM, отключив в ней кэширование и буферизацию.
В общем я так и сделал. Описал таблицу дескрипторов второго уровня и дал 1 КБ SRAM под DMA.

Понятно.

Кстати: в PDC нужно указывать физические, а не виртуальные адреса. Как-то не удобно...

Зато абсолютно логично. Не знает периферия о виртуальных адресах ничего.

[V_M_Luck]

2. Если "случайно" выполняется ремап

Что вы имеете в виду?
Я использую как основу Atmel пример. Там в board_lowlevel.c был вызов BOARD_RemapRam(); - я его закоментарил. На всякий случай проверяю на старте GPNVM[3] бит. Еще есть лазейки для "случайного" ремапа?

[aaarrr]

Еще есть лазейки для "случайного" ремапа?

Нет, но проверьте на всякий случай MATRIX_MRCR. Кроме того, следует учитывать, что remap существует только для ядра, периферия (например, PDC) будет всегда использовать обычную карту памяти - тоже потенциальный источник ошибки, правда, не в данном случае.

При обычном раскладе по адресам 0x000000 и 0x200000 будет находится одно и то же содержимое, что исключает необходимость манипуляций с MMU для отражения flash в 0.

[V_M_Luck]

Большое спасибо за ответы!

[vmp]

Еще раз спрашиваю: почему? Ответ "потому что иначе не работают прерывания" совершенно не устраивает.

Все-таки полез разбираться в работающую программу.
Действительно у меня стартап включал ремап. Поскольку программа была слинкована на адреса ПЗУ (0x00200000), то ей было все равно, включен ремап или нет. После отключения ремапа программа работает как с TLB[0] = 0x00200C1A, так и с TLB[0] = 0x00000C1A.

[aaarrr]

Славно, ПСС найдены, все встало на свои места

[sulsher]

а не подскажите пример решения данной проблемы на ассемблере?