|
|
1.1 root 1: The HP300 version uses a kernel which is loaded into the range 0xfffxxx... but
2: is linked for range 0x000.. This causes the problem that with switching the
3: MMU to the mapped kernel, the PC becomes invalid. The HP version solves the
4: problem by mapping 1:1 the last page of physical memory into virtual memory.
5:
6: On the Amiga, there *is* memory at PA 0x0, so we might as well use it, causes
7: much less grief and weirdness in locore.s. However, since memory down there
8: is CHIPMEM, inherently slower than FASTMEM, and badly needed for framebuffer
9: storage space, we'll copy the kernel over to the first bank of FASTRAM, and
10: when enabling the MMU, the kernel will execute in FASTRAM, although the PC
11: stays the same.
12:
13: This strategy has the big advantage (compared to the solution in Amiga MACH)
14: that we can link the kernel absolutely to VA 0, for all memory models, since
15: we'll never execute the kernel in the FASTMEM space while the MMU is turned
16: off.
17:
18: This strategy also means, that we don't have to relocate any addresses while
19: bootstrapping the mmu!!
20:
21: Initialization of the MMU happens in amiga_init.c. This file is quite a mess,
22: I have generated it trying to understand what's happening in the hp300 locore.s
23: file. I think, it should be able to handle MMU initialization much cleaner
24: now that we don't have to think about relocation until the MMU is enabled.
25: If you need your daily bit of horror, take a look at amiga_init.c...
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.