From owner-freebsd-ppc@FreeBSD.ORG  Tue Mar  3 23:35:59 2009
Return-Path: <owner-freebsd-ppc@FreeBSD.ORG>
Delivered-To: freebsd-ppc@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 01A23106564A
	for <freebsd-ppc@freebsd.org>; Tue,  3 Mar 2009 23:35:59 +0000 (UTC)
	(envelope-from grehan@freebsd.org)
Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12])
	by mx1.freebsd.org (Postfix) with ESMTP id B72198FC1B
	for <freebsd-ppc@freebsd.org>; Tue,  3 Mar 2009 23:35:58 +0000 (UTC)
	(envelope-from grehan@freebsd.org)
Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57])
	by alto.onthenet.com.au (Postfix) with ESMTP id 26342116E1;
	Wed,  4 Mar 2009 09:16:07 +1000 (EST)
Received: (from dommail.onthenet.com.au [192.100.104.17])
	by dommail.onthenet.com.au (MOS 3.8.6-GA)
	with HTTP/1.1 id EQW86822 (AUTH peterg@ptree32.com.au);
	Wed,  4 Mar 2009 09:13:10 +1000 (EST)
From: Peter Grehan <grehan@freebsd.org>
To: Justin Hibbits <jrh29@alumni.cwru.edu>, freebsd-ppc@freebsd.org
X-Mailer: Mirapoint Webmail Direct 3.8.6-GA
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20090304091310.EQW86822@dommail.onthenet.com.au>
Date: Wed,  4 Mar 2009 09:13:10 +1000 (EST)
Cc: 
Subject: Re: graphics on G4
X-BeenThere: freebsd-ppc@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Porting FreeBSD to the PowerPC <freebsd-ppc.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
	<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
	<mailto:freebsd-ppc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 23:35:59 -0000

Hi Justin,

>>What happens if we have physical or device memory in the
>>same range as kmem VAs?

 This shouldn't happen: kmem VAs use seg regs 13 and 14 i.e.
the virtually-mapped space is 0xD000.0000 -> 0xEFFF.FFFF.

 Kernel physical memory is 1:1 mapped, using BAT registers, as
is i/o space. Since there are only 4 BAT registers used, a DSI
trap will evict a BAT and re-use it, if the faulting address
falls in the battable[] array. See
powerpc/aim/trap_subr.s:dsitrap().

 Now, mapping the frame buffer from user-space *doesn't* use
the BATs, but instead uses PTEs from user VA. Each process has
unique segment register values which prevent it from
corrupting memory in other address spaces (including the
kernel's).

>> > > >It seems like trying to modify it through the BAT map (as
>> > > >zero/copy page, /dev/mem and friends do) will overwrite
>> > > >random bits of KVA instead...
 
 Shouldn't do, since KVA doesn't occupy that space.

>I wrote a simple kernel module to print out BAT and segment
registers, and the
>output immediately following boot is:

>Later, and I don't know precisely what is meant by "later",
registers 540 and 541 get changed to 0x4......., which
>means the video memory gets un-BAT-mapped.

 That is probably a BAT spill, which should be harmless.

 None of the above helps, I know :( But it's outlining what
should be happening.

later,

Peter.