А DMA в этих процах без MMU не обходится?
Справедливости ради проект мог быть и без DMA....

Я уже тут вроде где-то описывал - повторяться неохота.
Кратко говоря: кардиограф на 24 канала по 8кГц каждый (ADS1298) (только не надо меня спрашивать - зачем так много каналов и так много кГц - это было требование заказчика, в прикладную область я не вникал, для этого в проекте были профессора медицины) с кучей разной ЦОС (разные фильтры, FFT и спец.алгоритмы). Причём ЦОС предполагалось перетащить с готовой работающей на PC модели, соответственно - не оптимизированной под DSP и вся в double.
Приём потока с 3-х 8-канальных АЦП висящих на McASP+EDMA (с передачей одного из каналов на аудио-ЦАП на этом-же McASP), обработка, передача потока обработанных данных, а также вычисленных характеристик на USB клиенту.


Ну-ну на дуине поток в > 192kS/s с кучей ЦОС на double??? Такое думаю даже ни один M4F, гордо называемый маркетологами "DSP", не потянет.
Если Вы про EDMA3, то он работает независимо от MMU. Если про другие DMA - я их не использовал.
Да, работал не на максимальной производительности. После утаптывания PC-шного алгоритма под DSP, оказалось, что DSP и ARM-ядра каждое загружены не более чем на 10% на 300МГц тактовой.
Так что оно особо и не нужно было.
Но потом заказчик озвучил, что хочет продолжить проект и добавить кое-какой обработки, вот под это дело я авансом решил ещё немного разгрузить ARM9-ядро и включить кеш данных (что давно хотел, но руки не доходили). Вот и прописал инит MMU.


Конечно обходится. Если речь про EDMA3, так это вообще там часть периферии не относящейся к конкретному ядру. С ним может хоть DSP хоть ARM работать, а можно вообще - одним каналом рулить ARM, другим - DSP. А вот MMU - относится только к ARM-ядру. У DSP своё кеширование, а виртуализации памяти вообще нет (насколько я помню).
Есть правда ещё какое-то IDMA, но это только уже в DSP-ядре и его я не использовал и не разбирался.

Да, наш форум с короткой памятью. Приходится повторяться.
За ответ спасибо.

Эх! я бы ещё поработал с L137! Классный МК и изучил я его не полностью и не задействовал все его возможности. Но, к сожалению, задач под него не находится....

Тут не согласен, ДМА прекрасно работает без ММУ, мало того, в своих проектах еще приходилось "бодаться" за память, т.к. работа ДМА в кэшируемой области представляет некоторые трудности, хотя скажу сразу - мх6 камень без ММУ и кэшей - фигня, с производительностью даже меньше М3го...

а вы SD/MMC интерфейс случайно не подняли по полной программе?

В чём?

В allwinner

С allwinner не работал.

Тогда примите на веру, что документации все-таки нет. Я тогже не работал с ним.

Вот честно не понимаю людей, нафига ломать мозги об недокументированные чипы? Ну выйдет на 5-10 процентов дешевле ваша железка, и что? Вы ж не в стопятьсотраз повторяете китайский планшет или медиаприставку, а делаете довольно недешевое оборудование, раз уж необходим мощный проц, поэтому какой смысл тут экономить??
К тому же, какой EOL у этих рокчипов и виннеров?? Когда в первый раз "увлекся" данными чипами, года 2 назад, в тренде были А10 и А13, интересно, они еще выпускаются или уже "канули в лету"?

В топку тогда его

Под последовательностью подпишусь.

http://eastar.ru/products/hardware/uhp-200/

TI AM3352 (Cortex-8)
Собственный загрузчик.
Собственная сетевая ось.


По теме топика.
Cortex-9 сам поддерживает когерентность кешей при DMA.
Не хватает на восьмом этой фичи. Седьмой это умеет?

Не стоит обобщать... Пример из моей вселенной:
Renesas R7S721020 (RZ1AL):

Когерентность ручками, через CP15... Может быть, Вы не включили Data Cache? И write back режим?
Или скажите тогда, КАК ЭТО СДЕЛАТЬ! Очень не хватает...

C Cortex-9 не работал, только с 8. Приведу первоисточник.

http://infocenter.arm.com/help/index.jsp?t...228a/index.html
I/O coherent systems (e.g. Cortex-A9 with ACP) implement a hardware mechanism
where accesses to shared DMA memory regions are routed to the cache controller
which will invalidate (for DMA reads) or cleans (for DMA writes) the relevant cache
lines.

Пока просто держим DMA данные в некешируемых областях и планируем перейти на
принцип flush/invalidation через CP15.

.