|
|
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.