[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] 040/060 MMU tree builder
Hi!
On Tue, 18 May 1999, Michael Schwingen wrote:
> On Mon, May 17, 1999 at 02:26:29AM +0000, Odd Skancke wrote:
> >
> > TOS sets up the memory according to the values found at phystop.w,
> > memtop.w, and _memtop.w, right? This means that one can change those
> > variables and jump trough the reset vector. Then TOS should set up memory
>
> Correct. However, TOS should turn off the MMU in the reset handler, and that
> means that your remapped memory will be gone. Hooking into the reset vector
> should be too early in the startup process to change that, IIRC.
Ok, but if the boot is a warm boot, it should not do anything with the
current mmu settings I think. Cause with a warm boot, all memory and
memory related things have already been set up. Anyway, since the mmu
setup runs after the warm boot needed to reset phystop etc., it is not set
up until then anyway.. hmm.. trying to set the mmu up before a warm boot
is another thing I haven't tested....
>
> > Well, as it does now, it sets up the mmu-tree, loads the URP and SRP with
> > the same tree address (with 1:1 mapping), sets up the TTRs and turn on the
> > MMU. This works very well on the Hades TOS. I think that if it turns out
>
> Correct. You can init and enable the MMU with a 1:1 mapping from the auto
> folder - however, it is too late then to remap RAM, since GEMDOS is already
> initialized.
Well, nothing is impossible :) I just thought of something that might
work, but I haven't tested it yet. I will report it if it works...
>
> > according to some kind of info file. Well.. to be fully honest, I have
> > been trying to map the area between $0x00e00000 and $0x01000000 to the
> > last two megabytes in the TT-RAM logical addressing space and I have not
> > been successful, altho when I think about it now, there are numerous
> > things I didn't try. But, I know that TOS does not touch the MMU settings
> > during startup. Unless it turn off the mmu and turns it back on for each
> > program it executes in the autofolder, but that is highly unlikely.
>
> Um - the hades TOS does not turn off the MMU? sure? How is that supposed to
> work on warm/cold boots?
Yes, I see the problem. As MiNT, with memory protection enabled, creates
and sets a new translation tree for each process, a warm boot in this case
would create havoc. But, I think that MiNT should rely on and not enable
Memory Protection unless the MMU is already enabled. Then, in MiNT reset
handler it should set the mmu registers to the original tranlation tree,
as found when it started. This would make it possible to use one "layout"
until the next cold-boot. I mean, during a cold boot, everything hardware
related is set up, and the memory map is created. Then on sucessive
warm-boots, the current "hardware" configuration should be preserved. Does
this sound reasonable?
Odd Skancke - ozk@atari.org