From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kxol1-0003eA-2x for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:13:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kxokz-0003d5-Fe for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:13:38 -0500 Received: from [199.232.76.173] (port=55157 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kxokz-0003d0-D5 for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:13:37 -0500 Received: from rv-out-0708.google.com ([209.85.198.243]:57824) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kxokz-00069p-6D for qemu-devel@nongnu.org; Wed, 05 Nov 2008 15:13:37 -0500 Received: by rv-out-0708.google.com with SMTP id f25so171851rvb.22 for ; Wed, 05 Nov 2008 12:13:35 -0800 (PST) Message-ID: Date: Wed, 5 Nov 2008 21:13:35 +0100 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] [PATCH] [RESEND] SM501 emulation for R2D-SH4 In-Reply-To: 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> <491065DB.1040204@juno.dti.ne.jp> <4911D34E.6090809@juno.dti.ne.jp> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org 2008/11/5 Blue Swirl : > On 11/5/08, Shin-ichiro KAWASAKI wrote: >> Blue Swirl wrote: >> >> > On 11/4/08, Shin-ichiro KAWASAKI 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. One nit is that qemu_ram_alloc() makes it possible for ram to be allocked inside devices, so for example the local_mem_base and local_mem_bytes parameters can be removed. Cheers