[Qemu-devel] External RAM

[Qemu-devel] External RAM

[Brian Roantree]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

Hi, I'm not sure which list this belongs in and was unable to find anything like it so here goes,

I am using QEMU 0.15.90 to emulate a processor and have currently got it running in a loosely timed simulation with a systemC kernel as well, I have also  created and attached a block of RAM as well as another device and am running into a problem. It is registered as IO memory and replaced the generic internal ram that was allocated using qemu_ram_alloc, the problem I'm having is that my bootloader is now trying to write to RAM address  4293918720 (0xFFF00000) which doesn't exist. My question is can I somehow use qemu_ram_alloc to allocate the RAM but still use the different IO functions to read and write from this block of memory?

I have tried creating a device for the ram and after initialising it using

Addr = qemu_ram_alloc(s->sc_shared_ram,"name.ram", ram_size);
cpu_register_physical_memory(addr_base, ram_size, Addr);
where s is processor device_state and sc_shared_ram is a device_state with the modified read and write functions

however when the Ram is used the read and write functions are never employed.

Any help you could provide would be much appreciated, also apologies if I'm not that clear with my wording I haven't been doing QEMU development that long so am not also sure how to express what I want.

[-- Attachment #2: Type: text/html, Size: 3506 bytes --]

Re: [Qemu-devel] External RAM

[Blue Swirl]

On Wed, Aug 29, 2012 at 1:38 PM, Brian Roantree
<Brian.Roantree@imgtec.com> wrote:
> Hi, I’m not sure which list this belongs in and was unable to find anything
> like it so here goes,
>
>
>
> I am using QEMU 0.15.90 to emulate a processor and have currently got it
> running in a loosely timed simulation with a systemC kernel as well, I have
> also  created and attached a block of RAM as well as another device and am
> running into a problem. It is registered as IO memory and replaced the
> generic internal ram that was allocated using qemu_ram_alloc, the problem
> I’m having is that my bootloader is now trying to write to RAM address
> 4293918720 (0xFFF00000) which doesn’t exist. My question is can I somehow
> use qemu_ram_alloc to allocate the RAM but still use the different IO
> functions to read and write from this block of memory?
>
>
>
> I have tried creating a device for the ram and after initialising it using
>
>
>
> Addr = qemu_ram_alloc(s->sc_shared_ram,”name.ram”, ram_size);
>
> cpu_register_physical_memory(addr_base, ram_size, Addr);
>
> where s is processor device_state and sc_shared_ram is a device_state with
> the modified read and write functions
>
>
>
> however when the Ram is used the read and write functions are never
> employed.
>
>
>
> Any help you could provide would be much appreciated, also apologies if I’m
> not that clear with my wording I haven’t been doing QEMU development that
> long so am not also sure how to express what I want.

Either the memory is registered as MMIO (but then it's not possible to
execute code from it), or it's registered as RAM (but then it's not
possible to register MMIO handlers). In between those, there's ROMD,
which is read as RAM but written as MMIO device.

Re: [Qemu-devel] External RAM

[Brian Roantree]

Thanks for the reply however as my boss was sat watching me I wound up taking another direction.

Because I knew the address of the block of RAM and the name I was calling it with I was able to create a block. Instead of using malloc to allocate the memory for it, I set the address for the RAM to the address of the external block I'd created meaning that all the standard RAM functions should work :)

When I have some time I'll have to try creating and using ROMD 
	
>-----Original Message-----
>From: Blue Swirl [mailto:blauwirbel@gmail.com] 
>Sent: 01 September 2012 10:26
>To: Brian Roantree
>Cc: qemu-devel@nongnu.org
>Subject: Re: [Qemu-devel] External RAM

>On Wed, Aug 29, 2012 at 1:38 PM, Brian Roantree <Brian.Roantree@imgtec.com> wrote:
>> Hi, I’m not sure which list this belongs in and was unable to find 
>> anything like it so here goes,
>>
>>
>>
>> I am using QEMU 0.15.90 to emulate a processor and have currently got 
>> it running in a loosely timed simulation with a systemC kernel as 
>> well, I have also  created and attached a block of RAM as well as 
>> another device and am running into a problem. It is registered as IO 
>> memory and replaced the generic internal ram that was allocated using 
>> qemu_ram_alloc, the problem I’m having is that my bootloader is now 
>> trying to write to RAM address
>> 4293918720 (0xFFF00000) which doesn’t exist. My question is can I 
>> somehow use qemu_ram_alloc to allocate the RAM but still use the 
>> different IO functions to read and write from this block of memory?
>>
>>
>>
>> I have tried creating a device for the ram and after initialising it 
>> using
>>
>>
>>
>> Addr = qemu_ram_alloc(s->sc_shared_ram,”name.ram”, ram_size);
>>
>> cpu_register_physical_memory(addr_base, ram_size, Addr);
>>
>> where s is processor device_state and sc_shared_ram is a device_state 
>> with the modified read and write functions
>>
>>
>>
>> however when the Ram is used the read and write functions are never 
>> employed.
>>
>>
>>
>> Any help you could provide would be much appreciated, also apologies 
>> if I’m not that clear with my wording I haven’t been doing QEMU 
>> development that long so am not also sure how to express what I want. >

>Either the memory is registered as MMIO (but then it's not possible to execute code from it), or it's registered as RAM (but then it's not possible to register MMIO handlers). In between those, >there's ROMD, which is read as RAM but written as MMIO device.

Re: [Qemu-devel] External RAM

[Andreas Färber]

Hi,

Am 29.08.2012 15:38, schrieb Brian Roantree:
> I am using QEMU 0.15.90 to emulate a processor and have currently got it
> running in a loosely timed simulation with a systemC kernel as well,

Generally you will get more specific answers when asking about the
current code base - we're about to release v1.2.

In this case, the memory allocation (GLib), the Memory API and the
object model for devices (QOM) have all three changed significantly
since v0.15, so if you ever want to have your modifications included
upstream you'll end up redoing everything a second time almost from
scratch - which your watching boss might not be so happy about. ;)

Not sure if "SystemC kernel" is just your guest kernel or one of the
forked versions of QEMU with SystemC support, in the latter case you
should cc its maintainers on your questions and may want to poke them to
upstream their changes to avoid the diversion sketched above.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg