From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KxoxU-0008BF-Uz
	for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:26:32 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KxoxQ-00089n-I7
	for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:26:32 -0500
Received: from [199.232.76.173] (port=34438 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KxoxQ-00089j-AE
	for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:26:28 -0500
Received: from wa-out-1112.google.com ([209.85.146.176]:64272)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1KxoxP-0000oI-Ak
	for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:26:28 -0500
Received: by wa-out-1112.google.com with SMTP id j5so186506wah.18
	for <qemu-devel@nongnu.org>; Wed, 05 Nov 2008 12:26:01 -0800 (PST)
Message-ID: <f43fc5580811051226x6dd2ebf1xde581ee592f9147f@mail.gmail.com>
Date: Wed, 5 Nov 2008 22:26:01 +0200
From: "Blue Swirl" <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] [PATCH] [RESEND] SM501 emulation for R2D-SH4
In-Reply-To: <fb249edb0811051213r509799f1of6e5724190defecf@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <490D0C8F.9010601@juno.dti.ne.jp>
	<f43fc5580811012352k67091dd3oe56c42a150fe4398@mail.gmail.com>
	<491065DB.1040204@juno.dti.ne.jp>
	<f43fc5580811041111u1cfeff55jf456077c6b4a900d@mail.gmail.com>
	<4911D34E.6090809@juno.dti.ne.jp>
	<f43fc5580811051025p2fab5629ie324460515b1257f@mail.gmail.com>
	<fb249edb0811051213r509799f1of6e5724190defecf@mail.gmail.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: andrzej zaborowski <balrogg@gmail.com>
Cc: qemu-devel@nongnu.org

On 11/5/08, andrzej zaborowski <balrogg@gmail.com> wrote:
> 2008/11/5 Blue Swirl <blauwirbel@gmail.com>:
>
> > On 11/5/08, Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp> wrote:
>  >> Blue Swirl wrote:
>  >>
>  >> > On 11/4/08, Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp> wrote:
>  >> >
>  >> > > Thank you for reviewing!
>  >> > >
>  >> > >  I add the new version of patch to this mail, which reflects
>  >> > >  you and andrzej's comments.  Some more comments on it will be
>  >> > >  appreciated.  Especially advice on VRAM implementation with
>  >> > >  normal RAM will be useful for me.
>  >> > >
>  >> > > > The display buffer should be allocated using machine definition
>  >> > > >
>  >> > > .ram_require.
>  >> > >  I tried normal RAM implementation : "#define USE_NORMAL_RAM" in the
>  >> patch
>  >> > > will
>  >> > >  turn the new implementation on.  But it causes system hang during
>  >> SH-Linux
>  >> > > boot up.
>  >> > >  The initial VRAM clearance seems to cause the hang.
>  >> > >  The reason might be my wrong implementation, or any MMU problem of SH4.
>  >> > >
>  >> > >  I did,
>  >> > >  - added VRAM size to .ram_require
>  >> > >  - invoked qemu_ram_alloc() with the VRAM size parameter,
>  >> > >  - and invoked cpu_register_physical_memory(), passing
>  >> the
>  >> > > return value of
>  >> > >  qemu_ram_alloc() as third parameter.
>  >> > >
>  >> > >  Is this sequence correct?
>  >> > >
>  >> >
>  >> > Yes, but the system RAM is not allocated using qemu_ram_alloc. Now
>  >> > qemu_ram_alloc gives the same area (0 to VRAM_SIZE) the second time.
>  >> >
>  >> > So the following:
>  >> >    /* Allocate memory space */
>  >> >    cpu_register_physical_memory(SDRAM_BASE, SDRAM_SIZE,
>  >> 0);
>  >> > should be changed to:
>  >> >    ram_addr = qemu_ram_alloc(SDRAM_SIZE);
>  >> >    cpu_register_physical_memory(SDRAM_BASE, SDRAM_SIZE,
>  >> ram_addr);
>  >> >
>  >> > Maybe that helps?
>  >> >
>  >>
>  >>  Yes, it helps.  Thank you!
>  >>
>  >>  Here's the new patch which uses normal RAM as the VRAM, and
>  >>  checks VGA_DIRTY_FLAG for partial update.
>  >>
>  >>  I think it is ready for merge to the trunk.
>  >>  Could anyone help it?
>  >
>  > Looks good to me. What about you, Andrzej?
>
>
> While I don't know the hardware, it looks correct to me, feel free to merge.

Committed as r5632. Thanks!