Re: [MiNT] 040/060 MMU tree builder (fwd)

[Michael Schwingen <rincewind@discworld.dascon.de>]

On Fri, May 21, 1999 at 09:56:43PM +0000, Odd Skancke wrote:
> 
>  Well, I agree that all hardware should be reset, ofcourse, and the Hades
> TOS does that. But I thought that the memory was kept intact trough a warm
> boot. By this, I mean that the memory layout/mapping should not be changed
> by a warm-boot, since some things are resident, and would thus fail if
> memory mapping changed. And since TOS does allow for resident programs to
> survive a warm boot, the pmmu must not be changed during them. I might be
> on thin ice here, and this is more a question than anything :) I honestly
> thought this was the major difference between a cold and warm boot.

Nothing survives a warm boot in terms of memory management - TOS
re-initializes everything. You may reduce _phystop, so that TOS will not
touch stuff above that.

The only code that TOS lets you execute after a reset is the reset vector
hook (which is called *very* early in startup), and those low-memory
'packages' with the magic checksum. It is *your* task to make sure that the
code is still there and was not overwritten.

>  Yes, this would be the absolutely best solution. I guess Milan TOS lets
> you configure this to some extent?

No. The bootblock sets up a working PMMU mapping before starting TOS, and
the TOS never touches that (except for some special pages that map the ST
IO area at $xxFFxxxx).

You can't turn it off (there are a lot of things that would break then, eg.
fast ram would not be one block anymore). The only amount of configurability
is the settings in the NVRAM which decide if you get an emulated romport
EPROM and if you want 4/8/14MB ST-RAM.

> Yes, agreed. But since it doesn't, I'm looking for other ways to do it :)

Patch the TOS - it shouldn't be too difficult to move the PMMU-Init-code
into the TOS as soon as you have it working.

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen