From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KxRJG-00034G-5q
	for qemu-devel@nongnu.org; Tue, 04 Nov 2008 14:11:26 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KxRJF-00033X-5H
	for qemu-devel@nongnu.org; Tue, 04 Nov 2008 14:11:25 -0500
Received: from [199.232.76.173] (port=36062 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KxRJE-00033P-Qq
	for qemu-devel@nongnu.org; Tue, 04 Nov 2008 14:11:24 -0500
Received: from wf-out-1314.google.com ([209.85.200.169]:40641)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1KxRJF-0007lo-09
	for qemu-devel@nongnu.org; Tue, 04 Nov 2008 14:11:25 -0500
Received: by wf-out-1314.google.com with SMTP id 27so3366045wfd.4
	for <qemu-devel@nongnu.org>; Tue, 04 Nov 2008 11:11:23 -0800 (PST)
Message-ID: <f43fc5580811041111u1cfeff55jf456077c6b4a900d@mail.gmail.com>
Date: Tue, 4 Nov 2008 21:11:22 +0200
From: "Blue Swirl" <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] [PATCH] SM501 emulation for R2D-SH4
In-Reply-To: <491065DB.1040204@juno.dti.ne.jp>
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>
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: qemu-devel@nongnu.org

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?