[vmp 0]

То есть секция TLB у вас размещалась в SDRAM? Это не слишком било по производительности? Разглядываю примеры - там располагали эту секцию в SRAM.

Не проверял. Но вообще-то она кешируется, в ARM926EJ-S кеш TLB имеет по 32 элемента на код и данные, так что для данной конфигурации почти все должно было осесть в кеше.

[defunct 0]

То есть секция TLB у вас размещалась в SDRAM? Это не слишком било по производительности? Разглядываю примеры - там располагали эту секцию в SRAM.

Это совершенно не бъет по производительности если суммарное количество активных секций (та память с которой работаем) не превашает 64 (напр 64 секции по 1MB). Активные секции постоянно будут в регистрах MMU и обращений к TLB практически не будет.

[EugenB2 0]

Пример инициализации MMU для SAM9XE под IAR 5.x

Раскладка ОЗУ - кешируются 31 мегабайт из 32, последний мегабайт оставлен для буферов при работе с DMA (некешируемый).

Секцию "TLB" нужно задать в .icf - файле, я ее клал в последние 16К последнего мегабайта ОЗУ (в некешируемую область), с адреса 0x21FFC000.

Спасибо за файлик. После некоторых его исправлений я наконец-то получил таки мои 200мипсов!

Я так подумал, а почему бы не разместить TLB таких объемов во FLASH(и ОЗУ не надо тратить и должно врое работать все), и разместил, залил вуаля, все также нормально(вроде нормально) работает.

mmu_sam9xe.zip

[EugenB2 0]

Ндаа. Радость была недолгой. Вставил во FreeRTOS, после prvSetupTimerInterrupt - это конфиг таймера шедулера - зависает все ((.

 

подправил исходничек и вуаля на FreeRTOS тоже заработало

mmu_sam9xe_2.zip

 

==============

Кстати, что за глюк форума, не дает отредактировать сообщение.

Изменено 16 января, 2010 пользователем EugenB2

[sasamy 11]

Это совершенно не бъет по производительности если суммарное количество активных секций (та память с которой работаем) не превашает 64 (напр 64 секции по 1MB). Активные секции постоянно будут в регистрах MMU и обращений к TLB практически не будет.

 

Зря вы таблицу страниц назваете TLB :) TLB - это как раз тот самый ассоциативный кэш из 64 регистров к которым и будем обращение. Translation Lookaside Buffer.

[sasamy 11]

Cам в догадках...

\ ??testit_0:

\ 00000008 10109FE5 LDR R1,??testit_1 ;; 0xd59f80 единственное обращение к памяти, а производительности особо не прибавилось

\ 0000000C 010050E1 CMP R0,R1

\ 00000010 0100002A BCS ??testit_2

\ 00000014 010090E2 ADDS R0,R0,#+1

\ 00000018 FAFFFFEA B ??testit_0

468 }

\ ??testit_2:

\ 0000001C 1EFF2FE1 BX LR ;; return

 

Может я и не прав - у arm9 кэши логические - они работают с логичсескими адресами, а таблицы страниц не что иное как данные, в совокупности с тем что 926 в отличие от 720 имеют гарвардскую архитектуру им нужно и кэш данных включать.

Изменено 16 января, 2010 пользователем sasamy

[aaarrr 63]

Может я и не прав - у arm9 кэши логические - они работают с логичсескими адресами, а таблицы страниц не что иное как данные, в совокупности с тем что 926 в отличие от 720 имеют гарвардскую архитектуру им нужно и кэш данных включать.

Вы сами-то поняли, что хотели сказать?

[sasamy 11]

Вы сами-то поняли, что хотели сказать?

 

Согласен - ерунду полную сморозил :)

[V_M_Luck 0]

Уважаемый vmp!

Возвращаясь к вашему примеру, не могли бы вы пояснить, как имеено связаны биты C и B описания секций с областью DMA? Интуитивно понятно, но чем все-таки это чревато?

 

Уважаемый vmp!

Возвращаясь к вашему примеру, не могли бы вы пояснить, как имеено связаны биты C и B описания секций с областью DMA? Интуитивно понятно, но чем все-таки это чревато?

[aaarrr 63]

Уважаемый vmp!

Возвращаясь к вашему примеру, не могли бы вы пояснить, как имеено связаны биты C и B описания секций с областью DMA? Интуитивно понятно, но чем все-таки это чревато?

Я хоть и не vmp, но отвечу :)

 

Рассмотрим два случая:

 

1. DMA пишет в память. В том случае, если DMA производит запись в область памяти, для которой включено кэширование (любого типа), то существует ненулевая вероятность, что ядро при чтении поднимет данные из кэша, вместо обращения к памяти. То есть для нормальной работы придется полностью или частично сбрасывать кэш перед чтением.

 

2. DMA читает из памяти. Здесь мы наблюдаем обратный эффект: в памяти могут содержаться устаревшие с точки зрения ядра данные, если кэш сконфигурирован в режиме write-back.

[V_M_Luck 0]

Спасибо за ответ.

Это в общем-то понятно. Вопрос возник вот почему. Я, разбираясь в этом вопросе провожу некоторые эксперименты. Я настроил UART на выдачу через PDC. Ну и шлю на ПК строчки. Без ММУ и кэшей все работает. Подключаю ММУ, все ОЗУ - одним сектором, кэш и буферизация включены, DCash, ICASH включены - все ОК. Отключаю DCash - тоже работает, но начинает глючить дебаггер. Отключаю кэш и буферизацию в ММУ - не работает! Вишу в Data abort.

Как же корректно сконфигурировать ММУ и кэши для использования DMA?

[aaarrr 63]

Вишу в Data abort.

Посмотрите, откуда падаете в Data Abort. Связь с кэшем тут если и есть, то весьма опосредованная.

[defunct 0]

Зря вы таблицу страниц назваете TLB :) TLB - это как раз тот самый ассоциативный кэш из 64 регистров к которым и будет обращение. Translation Lookaside Buffer.

За поправку спасибо!

нутром чуял что что-то не то, но теоретической базы полную истину изобразить нехватило. :(

 

В моем посте имелось в виду, что не будет обращений к Translation Table (TT) - той что лежит в памяти.

[vmp 0]

Как же корректно сконфигурировать ММУ и кэши для использования DMA?

Пример я уже давал выше. Буфера надо располагать в некешируемой области - для данного примера это от 0x21F00000 до 0x21FFBFFF.

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

Еще раз обращаю винмание на тонкость с переадресацией 0-х адресов - их надо отображать в 0x00200000 (флеш), иначе не работают прерывания.

Data Abort - возможно, вы настроили не всю таблицу.

То, что у вас работал PDC из кешируемой памяти - либо просто везение (эти адреса не лежали в кеше), либо неправильная настройка (кеш был выключен или эта область памяти не кешировалась).

[V_M_Luck 0]

Посмотрите, откуда падаете в Data Abort. Связь с кэшем тут если и есть, то весьма опосредованная.

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

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

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

Пример я уже давал выше. Буфера надо располагать в некешируемой области - для данного примера это от 0x21F00000 до 0x21FFBFFF.

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