В применении без внешней RAM есть только 32 килобайта внутренней памяти. Тратить 16 килобайт под таблицу трансляции адресов как-то жаль. Разместил таблицу во FLASH, MMU и DCache (ICache работал и раньше) включил. Вроде живёт.
Вопросы:
1) имеет ли смысл по скорости?
2) как правильно выполнить сброс DCache в SRAM перед DMA записями (не целиком, а только указанный диапазон MVA)
3) как правильно выполнить инвалидацию DCache после операции чтения блока откуда-либо по DMA (указанный диапазон адресов).
Помнится, в Intel 486 это происходило автоматически...
В двух последних вопросах хотелось бы видеть код, сами функции обращения к CP15 есть или могут быть написаны по мере необходимости.
Как я понимаю, нужно учитывать размер строки TLB и выдавать команды для всех требуемых адресов, инкреметируя начало буфера на размер строки?
Полная версия этой страницы: AT91SAM9XE512 & MMU
Сделал так:
Гложет мысль - выгонять кэш в 3-х килобайтном буфере может быть накладно по ресурсам? 100 вызовов обращения к CP15...
CODE
#define MK_MVA(addr) ((unsigned long) (addr) & ~ 0x1fUL)
void arm_hardware_invalidate(const void * base, size_t size)
{
enum { CACHEROWSOZE = 32 };
unsigned long len = (size + (CACHEROWSOZE - 1)) / CACHEROWSOZE + (((unsigned long) base & (CACHEROWSOZE - 1)) != 0);
unsigned long mva = MK_MVA(base);
while (len --)
{
CP15_invalidateCacheSingleEntryMVA(mva); // очистить кэш
mva += CACHEROWSOZE;
}
}
void arm_hardware_flush(const void * base, size_t size)
{
enum { CACHEROWSOZE = 32 };
unsigned long len = (size + (CACHEROWSOZE - 1)) / CACHEROWSOZE + (((unsigned long) base & (CACHEROWSOZE - 1)) != 0);
unsigned long mva = MK_MVA(base);
while (len --)
{
CP15_cleanDCacheEntryMVA(mva); // записать буфер, кэш продолжает хранить
mva += CACHEROWSOZE;
}
}
void arm_hardware_flush_invalidate(const void * base, size_t size)
{
enum { CACHEROWSOZE = 32 };
unsigned long len = (size + (CACHEROWSOZE - 1)) / CACHEROWSOZE + (((unsigned long) base & (CACHEROWSOZE - 1)) != 0);
unsigned long mva = MK_MVA(base);
while (len --)
{
CP15_cleanInvalidateDCacheEntryMVA(mva); // записать буфер, очистить кэш
mva += CACHEROWSOZE;
}
}
void arm_hardware_invalidate(const void * base, size_t size)
{
enum { CACHEROWSOZE = 32 };
unsigned long len = (size + (CACHEROWSOZE - 1)) / CACHEROWSOZE + (((unsigned long) base & (CACHEROWSOZE - 1)) != 0);
unsigned long mva = MK_MVA(base);
while (len --)
{
CP15_invalidateCacheSingleEntryMVA(mva); // очистить кэш
mva += CACHEROWSOZE;
}
}
void arm_hardware_flush(const void * base, size_t size)
{
enum { CACHEROWSOZE = 32 };
unsigned long len = (size + (CACHEROWSOZE - 1)) / CACHEROWSOZE + (((unsigned long) base & (CACHEROWSOZE - 1)) != 0);
unsigned long mva = MK_MVA(base);
while (len --)
{
CP15_cleanDCacheEntryMVA(mva); // записать буфер, кэш продолжает хранить
mva += CACHEROWSOZE;
}
}
void arm_hardware_flush_invalidate(const void * base, size_t size)
{
enum { CACHEROWSOZE = 32 };
unsigned long len = (size + (CACHEROWSOZE - 1)) / CACHEROWSOZE + (((unsigned long) base & (CACHEROWSOZE - 1)) != 0);
unsigned long mva = MK_MVA(base);
while (len --)
{
CP15_cleanInvalidateDCacheEntryMVA(mva); // записать буфер, очистить кэш
mva += CACHEROWSOZE;
}
}
Гложет мысль - выгонять кэш в 3-х килобайтном буфере может быть накладно по ресурсам? 100 вызовов обращения к CP15...
Пытаюсь для отладки увидеть, что произойдёт при обращении (записи) "отсутствующую страницу. Почему-то в обработчик Data Abort не попадаю... Действительно ли это должно произойти?
Простите мою неграмотность, но как TLB может вообще лежать во flash ? Там же вроде очень быстрое ОЗУ надо.
Это не TLB, а Translation Table. Особо быстрая память ей ни к чему, как раз по причине наличия TLB (Translation Lookaside Buffer). Почему-то эти две разные совершенно сущности постоянно путают.
ИМХО, мудрить с кэшем во многих случаях большого смысла не имеет:
- Если DMA работает на передачу, то гораздо проще объявить область памяти NCB, а перед запуском DMA чистить буфер записи. По скорости проигрыша практически не будет.
- Если DMA работает на прием, реальный выигрыш будет только при последующем массированном случайном доступе, что в общем случае нетипично.
Цитата(Genadi Zawidowski @ Apr 1 2013, 00:15) 
Гложет мысль - выгонять кэш в 3-х килобайтном буфере может быть накладно по ресурсам? 100 вызовов обращения к CP15...
ИМХО, мудрить с кэшем во многих случаях большого смысла не имеет:
- Если DMA работает на передачу, то гораздо проще объявить область памяти NCB, а перед запуском DMA чистить буфер записи. По скорости проигрыша практически не будет.
- Если DMA работает на прием, реальный выигрыш будет только при последующем массированном случайном доступе, что в общем случае нетипично.
Объявить некешируемой часть памяти не получается - атрибуты при одноуровневой таблице распространяются на зоны в мегабайт размером.
Наличие выигрыша будет проверяться осцилографом по времени нахождения в прерывании.
Наличие выигрыша будет проверяться осцилографом по времени нахождения в прерывании.
Цитата(Genadi Zawidowski @ Apr 5 2013, 01:42)
Объявить некешируемой часть памяти не получается - атрибуты при одноуровневой таблице распространяются на зоны в мегабайт размером.
Тогда есть смысл сделать многоуровневую таблицу - все равно все пути осядут в TLB.
Ну и попутно вопрос: а точно ли нужен DCache? Двукратный прирост скорости при операциях с памятью, конечно,
никогда не мешает, но ведь внутренняя SRAM и сама по себе достаточно быстрая.
Если внутренняя память может быть включена как TCM (Tightly Coupled Memory -- тесно связанная память), то кэширование ей не то что не нужно -- оно просто неприменимо. Это надо описание на проц смотреть.
Цитата(aaarrr @ Apr 5 2013, 01:57)
Тогда есть смысл сделать многоуровневую таблицу - все равно все пути осядут в TLB.
Ну и попутно вопрос: а точно ли нужен DCache?
Ну и попутно вопрос: а точно ли нужен DCache?
Например, много операций pcm->a-law и назад (32 штуки прерывание 8 кГц). т.е., константные данные во flash. Надеюсь на ускорение работы. Хотя, для этого хватает и WT кэширования, которое для FLASH и включено. А WB это так... хочется же запаса!
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.