qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] [RESEND] SM501 emulation for R2D-SH4


From: andrzej zaborowski
Subject: Re: [Qemu-devel] [PATCH] [RESEND] SM501 emulation for R2D-SH4
Date: Wed, 5 Nov 2008 21:13:35 +0100

2008/11/5 Blue Swirl <address@hidden>:
> On 11/5/08, Shin-ichiro KAWASAKI <address@hidden> wrote:
>> Blue Swirl wrote:
>>
>> > On 11/4/08, Shin-ichiro KAWASAKI <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]