Problem with iMacs and kernel entry

Problem with iMacs and kernel entry

[Benjamin Herrenschmidt]

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.

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.

Any comments ?

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ 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@lists.linuxppc.org ]]

Re: Problem with iMacs and kernel entry

[Gabriel Paubert]

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 ?

Very likely. 

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

	Gabriel.


[[ 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@lists.linuxppc.org ]]

Re: Problem with iMacs and kernel entry

[Benjamin Herrenschmidt]

On Mon, Feb 15, 1999, Gabriel Paubert <paubert@iram.es> wrote:

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

I'm interested in pointer to those documents, do you have URLs handy ?

I finally have the boostrap working on my G3. It's about 400 bytes of PPC
asm, that's all ;-) Basically, what it does is:

 - Switch Interrupts off, MMU off, invalidate BATs, flush TLB
 - Copy itself elsewhere in case it overlaps the kernel destination
 - Execute a "script" of copy operations to perform, the script is appended to
   the boostrap itself by BootX. This scripts will copy kernel pages from
whatever
   location they occupy in memory (kernel is not made contiguous under
MacOS anymore).
   At the end of this process, we have the kernel copied at 0 physical
and contiguous
   (by "kernel", I mean here the pack
kernel+ramdisk+args+colormap+device-tree.
 - The kernel is entered with a stack pointer pointing to the
(top-512bytes) of
   a 64Kb area located just after the kernel "block".

The best way to fix the iMac problem is, I beleive, to move the code for
switching the USB controller off to BootX (it's in a BootX-specific
section of code anyway) and remove the one in the kernel. This will cause
compatibility trouble between new BootX and old kernels on the iMac, but
iMac users, I beleive, still update their kernels quite often, so it's
not a very big problem. Note that we can probably remove the
page-touching code from prom.c too.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ 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@lists.linuxppc.org ]]