The ColdFire MMU and FreeMiNT memory protection
by Markus Fröschle
Its not only that the Coldfire MMU is different from the m68k MMU's, it's that it is _totally_ different.
Besides that, the Coldfire MMU is already in use by FireTOS and EmuTOS (BaS) to make the FireBee memory layout Atari compatible, to implement 'faked' bus errors (that are not available on Coldfire) and to superimpose video memory pages into ST RAM. Thus implementing this would most likely require changes to existing FireTOS and/or BaS code as well (or would at least require intimate knowledge of what's already in use and how).
Without going into too much detail:
m68k MMUs basically initialize the MMU with a more or less static tree (a pretty smart implementation to reduce the amount of memory required) of page descriptors that maps virtual memory adresses to physically existing memory pages (or doesn't map them to force an error if somebody tries to access invalid memory). Every single process in MiNT has it's own table/tree that gets switched back and forth at context switches. Once the MMU tree is set up, code basically doesn't need to touch the MMU anymore, it more or less "just works" from this point in time.
The Coldfire MMU's aproach is totally different. There is no MMU tree anymore, instead it has a (very limited) number of page descriptors in the MMU itself. Every time the processor tries to access a memory address where the MMU has no current page descriptor available, the processor issues an exception. The exception code then must either replace one of the existing descriptors with a new one "manually" using a LRU scheme and restart the interrupted routine or issue an access/bus error.
Thus, the MiNT implementation of memory protection for Coldfires would need to kind of mimic the static MMU trees of the m68k MMUs in software. A straightforward implementation of 8k (MiNT's default page size) pages would require at least one byte per page descriptor, resulting in a 64k table for each process to just cover the 512 MBytes of TT RAM the FireBee has (not to mention ST RAM and I/O areas).
To limit the number of necessary page descriptors (and their memory usage), Coldfires allow larger (and variable) page sizes (up to 1 MByte). BaS and FireTOS already use 1 MByte pages while MiNT needs 8k pages (which is luckily supported by the Coldfire MMU in hardware), thus the memory protection code would likely need to be able to deal with variable page sizes as well.
There's yet another pitfall: Due to the way page faults are handled on Coldfires (exception code needs to deal with them) and MMU inner workings (automatic LRU replacement scheme) it's entirely possible that an "automatic" LRU replacement of a page descriptor "steals" the page where the supervisor stack resides. The next page fault would then end in Nirwana (double bus fault) since it would have no stack page available needed to push the exception stack frame to.
BaS and FireTOS have very limited support of this situation, today it more or less just works by accident due to relatively large page size and relatively low load on the limited number of page descriptors the MMU can hold which results in low probability of getting lost of supervisor stack (it's touched often enough in "normal" code to keep it from getting stolen).
A small test I once did by just changing current 1 MByte page size to 8k pages immediately led to a fatal crash.
MiNT memory protection thus would also need to deal with that and ensure that no process would get lost of its supervisor stack memory page and would always have the next lower page available as well (since the stack could then span across more than one page if we reduced page size).
I'm not saying it would be impossible (it definitely could be made), it's just that its a _real huge_ load of work. |
|
|
|
|
Najnowsze wiadomości
|
TeraDesk 4.07
2016-11-30:
Wydano nowÄ™ wersja programu TeraDesk.
|
Czytaj dalej
|
Wieści o nowej partii produkcyjnej
2016-08-13:
Medusa zidentfikowała element który sprawiał problem na nowo wyprodukowanych ...
|
Czytaj dalej
|
Opóźnienia produkcji nowej serii - cała prawda i tylko prawda.
2016-07-26:
Zgodnie z oryginalnymi zapowiedziami, nowa seria Firebee powinna być już dostarczona. ...
|
Czytaj dalej
|
|
