Subject: Re: PowerPC G5 port update and Open Firmware woes
To: Yevgeny Binder <yevbee@comcast.net>
From: Sanjay Lal <sanjayl@kymasys.com>
List: port-macppc
Date: 07/10/2006 02:18:31
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-2-262535918
Content-Type: multipart/alternative; boundary=Apple-Mail-1-262535847
--Apple-Mail-1-262535847
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
Hi Yevgeny,
the problem is that in PoweMacs OFW runs in what the standard defines
as "virtual mode", i.e. with the MMU turned on. The kernel switches
the MSR + segment registers to what OFW expects before calling the
client interface. The series of mtsrin instructions basically blows
away OFW's MMU context (see below for details). That is why, even
though the MMU is disabled in the kernel context, the system hangs
once the OFW interface is called after the series of mtsrin
instructions.
As it stands today the code is as follows:
(1) Save OFW translations (machdep.c : save_ofmap())
(2) pmap_bootstrap() (ofw_pmap is not initialized yet!!)
(3) Restore the OFW translations that NetBSD needs by loading them up
in ofw_pmap (machdep.c: restore_ofmap).
Unfortunately, restore_ofmap uses pmap_enter() which can only be
called once the pmap layer is up. Currently, I insert page table
entries for the OFW code+data in pmap_setup_segment0_map(). I think
things will fare better if you add in PTEs (uncached) for the
framebuffer Also, you need to modify restore_ofmap() so that the map
entries for the framebuffer are loaded into ofw_pmap.
Hope this helps
Sanjay
On Jul 8, 2006, at 11:46 PM, Yevgeny Binder wrote:
> After this point, however, pmap_bootstrap() starts to load the 16
> segment registers with a loop of mtsrin instructions. Console
> output stops upon the first load. I don't understand what effect
> this should have: Address translation has not yet been enabled in
> the kernel when this happens, and the Open Firmware client
> interface routines load up their own segment registers anyway. My
> only guess was that the addresses that I pass to dcbf, which I got
> from Open Firmware (and are hence virtual addresses in OFW's
> context, supposedly), somehow become invalid after the mtsrin. But
> if address translation is off in the kernel the whole time through,
> how can that be?
--Apple-Mail-1-262535847
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Hi Yevgeny,<DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>the problem is that in =
PoweMacs OFW runs in what the standard defines as "virtual mode", i.e. =
with the MMU turned on. The kernel switches the MSR + segment registers =
to what OFW expects before calling the client interface.=A0 =A0The =
series of mtsrin instructions basically blows away OFW's MMU context =
(see below for details). That is why, even though the MMU is disabled in =
the kernel context, the system hangs once the OFW interface is called =
after the series of mtsrin instructions.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>As it stands today the code =
is as follows:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>(1) Save OFW translations =
(machdep.c : save_ofmap())</DIV><DIV>(2) pmap_bootstrap() (ofw_pmap is =
not initialized yet!!)</DIV><DIV>(3) Restore the OFW translations that =
NetBSD needs by loading them up in ofw_pmap (machdep.c: =
restore_ofmap).</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Unfortunately, =
restore_ofmap uses pmap_enter() which can only be called once the pmap =
layer is up.=A0 Currently, I insert page table entries for the OFW =
code+data in=A0pmap_setup_segment0_map(). I think things will fare =
better if you add in PTEs (uncached) for the framebuffer=A0=A0Also, you =
need to modify restore_ofmap() so that the map entries for the =
framebuffer are loaded into ofw_pmap.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Hope this =
helps</DIV><DIV>Sanjay</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV><DIV><DIV>On Jul 8, 2006, =
at 11:46 PM, Yevgeny Binder wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><FONT face=3D"Monaco" size=3D"3" style=3D"font: =
12.0px Monaco">After this point, however, pmap_bootstrap() starts to =
load the 16 segment registers with a loop of mtsrin instructions. =
Console output stops upon the first load. I don't understand what effect =
this should have: Address translation has not yet been enabled in the =
kernel when this happens, and the Open Firmware client interface =
routines load up their own segment registers anyway. My only guess was =
that the addresses that I pass to dcbf, which I got from Open Firmware =
(and are hence virtual addresses in OFW's context, supposedly), somehow =
become invalid after the mtsrin. But if address translation is off in =
the kernel the whole time through, how can that be?</FONT></DIV> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=
--Apple-Mail-1-262535847--
--Apple-Mail-2-262535918
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iQEVAwUBRLH/So1Kh9bxllU0AQLuXQf+PBRrKuxC4G1+b6LEAztRRasdWQUlke9G
af5/Iz1ik7ihVEoBTDJCsiGEhuz1atjGqTijWeRQ3/oqWRfmDgQQa+ZQ5xCdc+uP
JU0Z9qHaddz6iKtLOEiDj7x1CgL8BZ6ktzPQZO0tO2GwFgCiljLLEixhT3J6rcjs
mk+3P322LH+tQV8Qa2k8BbLmiV+kn4PemL5Z2uu2LUZmMX3bLo97jrWJS2UuAHOk
5ZeniXGB6/E9n+82T/D9zt0rhC9IgDN2DXDtaHh9cSX9i/pKADvejs+s1S51we/Q
JiTxjqzPIPKmzdx1T1/d/f6zPU5dbm/wVzIVsg8nLwz7rapmv3MHew==
=ys0w
-----END PGP SIGNATURE-----
--Apple-Mail-2-262535918--