Jump to content

    
Sign in to follow this  
EugenB2

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

Recommended Posts

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

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

Share this post


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

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

Share this post


Link to post
Share on other sites
Пример инициализации MMU для SAM9XE под IAR 5.x

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

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

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

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

mmu_sam9xe.zip

Share this post


Link to post
Share on other sites

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

 

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

mmu_sam9xe_2.zip

 

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

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

Edited by EugenB2

Share this post


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

 

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

Share this post


Link to post
Share on other sites
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 имеют гарвардскую архитектуру им нужно и кэш данных включать.

Edited by sasamy

Share this post


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

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

Share this post


Link to post
Share on other sites

Уважаемый vmp!

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

 

Уважаемый vmp!

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

Share this post


Link to post
Share on other sites
Уважаемый vmp!

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

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


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

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

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

 

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

Share this post


Link to post
Share on other sites
Как же корректно сконфигурировать ММУ и кэши для использования DMA?

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

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

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

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

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

Share this post


Link to post
Share on other sites
Посмотрите, откуда падаете в Data Abort. Связь с кэшем тут если и есть, то весьма опосредованная.

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

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

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

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

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

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