Jump to content

    
Sign in to follow this  
EugenB2

Производительность SAM9XE

Recommended Posts

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

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

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

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

Share this post


Link to post
Share on other sites
Попадаю из первого обращения к стеку.

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

 

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

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

 

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

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

 

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

Нет.

 

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

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

 

 

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

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

Share this post


Link to post
Share on other sites

Похоже, что все-таки я неправильно настраивал ТТ.

Вариан тпервых записей, с которыми я мог отключать и подключать DCache:

0x00200C1A, 0x00100C1A,0x00200C1A,0x00300C1E

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

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

Нет.

Я имел ввиду, если под DMA выделить часть SRAM, отключив в ней кэширование и буферизацию.

В общем я так и сделал. Описал таблицу дескрипторов второго уровня и дал 1 КБ SRAM под DMA.

 

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

 

 

Похоже, что все-таки я неправильно настраивал ТТ.

Вариан тпервых записей, с которыми я мог отключать и подключать DCache:

0x00200C1A, 0x00100C1A,0x00200C1A,0x00300C1E

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

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

Нет.

Я имел ввиду, если под DMA выделить часть SRAM, отключив в ней кэширование и буферизацию.

В общем я так и сделал. Описал таблицу дескрипторов второго уровня и дал 1 КБ SRAM под DMA.

 

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

Share this post


Link to post
Share on other sites
Первая запись существенна. Хотя действительно, это совершенно не очевидно.

Пока не станет очевидно, все действия можно приравнять к битью в бубен.

Мапить что-то вручную в нулевой адрес может понадобится только в двух случаях:

1. Если не установлен GPNVM[3], но тогда процессор стартовал бы с ROM

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

 

Я имел ввиду, если под DMA выделить часть SRAM, отключив в ней кэширование и буферизацию.

В общем я так и сделал. Описал таблицу дескрипторов второго уровня и дал 1 КБ SRAM под DMA.

Понятно.

 

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

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

Share this post


Link to post
Share on other sites
2. Если "случайно" выполняется ремап

Что вы имеете в виду?

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

Share this post


Link to post
Share on other sites
Еще есть лазейки для "случайного" ремапа?

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

 

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

Share this post


Link to post
Share on other sites
Еще раз спрашиваю: почему? Ответ "потому что иначе не работают прерывания" совершенно не устраивает.

Все-таки полез разбираться в работающую программу. :)

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this