Am 26.08.2015 um 21:50 schrieb Vincent Rivière:
On 26/08/2015 10:51, markus@mubf.de wrote:Its not only that the Coldfire MMU is different from the m68k MMU's, it's that it is _totally_ different.Excellent description, Markus! This is the first time that the MMU facts are clearly exposed.
Thanks.As there is more feedback than I originally expected (after Mathias' first post did not generate any feedback at all): does that mean there is a something like a common interest in getting this to work although its quite a lot of effort?
In my personal opinion, memory protection is way more than just a nice developer's feature.
Frankly, to me it's one of the things that makes the difference between a 'toy OS' and a serious one.
There's a whole lot of software around that's not written as clean as one would wish (especially on the Firebee). If you have an operating system that can't deal properly with the crashes its causing and doesn't recover cleanly from them, the anger (with lost data, corrupt file systems or just the lost time you need to reboot) will fall back to operating system and platform - the end user doesn't care if it's the application that is to blame.
I actually can think of a way to implement first steps towards memory protection for the Coldfire, at least on top of EmuTOS. This might not help the majority of users since they probably will be using FireTOS, but it could be a first start.
BaS_gcc already contains a working page fault handler and code to map and unmap virtual pages. This code could be exposed to MiNT (in a similar way it exposes its DMA API for the FEC network driver). As a first step, this would allow FreeMiNT to modify MMU mappings without disturbing what's needed to make the Firebee appear as a Falcon (since BaS_gcc would still be under control). At least something to think about...
I saw in FreeMiNT sources something like "fake supervisor mode". From what I understood, when that mode is enabled Super() does not really switch to supervisor mode. It does some black magic (privilege violation handler?) to get the program running, anyway. This can be acceptable if the program just executes a few instructions in supervisor mode, such as reading TOS variables. Maybe I'm completely mistaken, these are only old reminiscences in my mind.
I saw this as well when I tried to understand how memory protection is supposed to work, but was at the impression this would be an unfinished or at least barely tested feature?
AFAICS (only had a brief look into it), it suports a very limited subset only of what applications may want to do in supervisor mode: reading the bus error vector, the bootdev, drvbits and cookie_p system variables (or are these just meant as examples, I would have expected it to at least allow _hz_200 reads?). Code to handle Coldfire stack frames seems to be missing as well.