headerheaderheaderheaderheaderheaderheaderheader
header
headerheaderheaderheaderheaderheaderheaderheaderheaderheaderheader
header
MMU процессора ColdFire и защита памяти FreeMiNT
Статья Markus Fröschle

MMU процессора ColdFire не просто отличается от MMU процессора m68k, он _совершенно_ другой.

Кроме этого, MMU (Memory Management Unit - Блок управления памятью) процессора ColdFire уже используется системами FireTOS и EmuTOS (BaS) для осуществления совместимости структуры памяти FireBee с компьютерами Atari, для обеспечения 'фальшивых' ошибок шины (в оригинале невозможных в Coldfire) и для помещения страниц видеопамяти в ST RAM. Так что внедрение этого MMU по всей вероятности потребует также внести изменения в существующий код FireTOS и/или BaS (или как минимум потребует отличного знания что уже используется и как).

Без особой детализации:

MMU процессора m68k обычно инициализирует MMU с более или менее статическим деревом (достаточно успешная реализация для сокращения количества необходимой памяти) дескрипторов страницы что приводит адреса виртуальной памяти в соответствие с физически существующими страницами (или не приводит, чтобы вызвать ошибку, если кто-то пытается достичь неправильной страницы памяти). Каждый отдельный процесс в MiNT обладает своей собственной таблицей/деревом, которые переключаются туда-сюда в зависимости от необходимости. Как только дерево MMU настроено, обычно коду нет необходимости больше трогать MMU, с этого момента времени он более-менее "просто работает".

Принцип работы MMU в процессоре Coldfire абсолютно иной. Больше нет дерева MMU, вместо этого у него есть (очень ограниченное) число дескрипторов страницы в нем самом. Каждый раз, когда процессор пытается получить доступ к адресу памяти, в котором у MMU нет текущего дескриптора страницы, процессор формирует исключение. Код такого исключения должен либо заменить один из существующих дескрипторов на новый, использующий "вручную" схему LRU, и перезапустить прерванную процедуру или вывести сообщение об ошибке доступа/шины.

Таким образом, внедрение защиты памяти MiNT для процессоров Coldfire должно использовать имитацию статических деревьев MMU процессоров m68k с помощью софта. Прямая попытка внедрения страниц размером 8k (размер страницы MiNT по умолчанию) требует как минимум один байт на дескриптор страницы, что приводит к размеру таблицы в 64К для каждого процесса только для того, чтобы покрыть 512 MBytes памяти TT RAM, которым обладает FireBee (при этом не учитываются области ST RAM и I/O).

Для ограничения количества необходимых дескрипторов страниц (и используемой ими памяти), процессоры Coldfire позволяют бОльшие (и изменяемые) размеры страницы (до 1 MByte). BaS и FireTOS уже используют страницы размером в 1 MByte, в то время как MiNT нужны страницы в 8k (которые, к счастью, поддерживаются MMU процессора Coldfire на уровне железа), таким образом, код защиты памяти также должен быть способен работать со страницами переменного размера.

Существует и еще одна опасность: В связи с реализацией в процессорах ошибок доступа к памяти (при этом должен генерироваться код исключения) и внутренней работы MMU (автоматическая схема замены LRU) вполне возможна ситуация, когда "автоматическая" замена LRU дескрипторов страницы "похитит" страницу, где находится стек супервайзера. Ошибка следующей страницы может закончиться в нирване (двойная ошибка шины), так как не будет страницы стека, необходимой для помещения в нее части стека исключения.

BaS и FireTOS предоставляют очень ограниченную поддержку для этой ситуации, в настоящее время работает более-менее случайно из-за относительно большого размера страницы и относительно низкой нагрузки на ограниченного числа дескрипторов страницы, которое может удержать MMU, что приводит к небольшой вероятности потери стеков супервайзера (часто это учтено в "нормальном" коде, для предотвращения его потери).

Я как-то провел небольшой тест - попытался поменять текущий размер страницы 1 MByte на 8k, что немедленно привело к зависанию.

Защита памяти MiNT также должна это учитывать и убедиться что не потеряется никакой процесс на стеке супервайзера на странице памяти и также всегда будет доступна следующая нижняя страница (так как стек затем должен расшириться более чем на одну страницу, если мы уменьшим размер страницы).

Я не хочу сказать, что это невозможно (без сомнения это можно сделать), просто это в самом деле _действительно огромная_ работа.
Последние новости
EmuTOS 1.1.1
2021-08-16:
08 июля 2021 года Команда Разработчиков EmuTOS выпустила ...
читать полностью
Проблемы с оборудованием на сервере firebee.org
2021-03-22:
Вы очевидно уже заметили это: некоторые новости, ...
читать полностью
Вышел GFA Basic Editor (GBE) v3.7
2021-01-18:
Дтя тех кто был не в курсе - оригинальный автор ...
читать полностью
Лента RSS | Правила использования | Карта сайта