Problem with iMacs and kernel entry
paubert at iram.es
Tue Feb 16 02:55:18 EST 1999
On Mon, 15 Feb 1999, Benjamin Herrenschmidt wrote:
> I've just thought about another problem:
> Since the new bootx will enter the kernel with MMU disabled, no-one is
> allowed to perform any kind of i/o until the MMU is re-enabled. At least
> that's my understanding, since cache and speculative pre-fetching are
> enabled for the whole address range, including devices.
Indeed, unless you disable the d-cache, but this creeates another series
of problems for 601 processors for which the cache can't be controlled
(you can work around with special direct-store segments but let's keep
things simple and processor independant in a bootloader).
> That means that the iMac "hack" in prom.c that disables the USB
> controller will get into trouble, won't it ?
> I want to avoid enabling the MMU in the bootstrap to avoid the problem of
> TLB misses on 603 (the boostrap has no exception handler) and I don't
> like the fact that the kernel entry plays with BATs with MMU enabled.
Well, in prepboot the MMU is enabled for a lot of reasons. This requires
the installation of 603 TLB miss handlers (which are well tested since I
only have 603), then I play with a lot of I/O (including complete
reconfiguration of PCI I/O and memory spaces to work around braindead PreP
firmware: I don't want to sacrifice 256 Mb to PCI I/O) and disable the MMU
before passing control to the kernel. So it's doable. There are also some
documents about how to perform a smooth transition of MMU management
between OF and client program. I wanted to implement this but am lacking
time right now.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request at lists.linuxppc.org ]]
More information about the Linuxppc-dev