Re: [Qemu-devel] Memory Map
Sure, i'm very interested in. I've used another implementation that still require large amount of data to be allocated (but with O(1) search time) Have a good day --- Mer 2/3/11, Vincent Palatin vpala...@chromium.org ha scritto: Da: Vincent Palatin vpala...@chromium.org Oggetto: Re: [Qemu-devel] Memory Map A: Salvatore Lionetti salvatorelione...@yahoo.it Cc: Blue Swirl blauwir...@gmail.com, qemu-devel@nongnu.org Data: Mercoledì 2 marzo 2011, 22:13 Hi, On Wed, Mar 2, 2011 at 12:11, Salvatore Lionetti salvatorelione...@yahoo.it wrote: Still now, some memory region is called with base+offset. So: [0x204] = value (write from uP register) cause read(opaque, offset=204, value) while [0x504] = value (write from uP register) cause read(opaque, offset=4, value) The two opaque are different as expected. Where i am wrong? If you mean 0x5004 and not 0x504 (as stated in your previous email), IMO it is a current limitation of the Qemu feature called subpage (which is used when you are mapping a memory area smaller than the MMU page size as in your example). When using subpages in the current code, the offset becomes the distance to the MMU page boundary instead of the distance to the base address of the peripheral. This is somewhat impractical and confusing when you are mapping the same subpage sized MMIO device at different addresses. As the emulation I'm working on has a lot of subpage sized peripherals, I have written a patch to workaround this limitation. I will send it to the list for comment if you want to try it. -- Vincent
Re: [Qemu-devel] Memory Map
Hi,
many thanks for your response.
Now i'm i've avoided the unregistering stuff, map done already at desired
address space.
Still now, some memory region is called with base+offset.
So:
[0x204] = value (write from uP register)
cause
read(opaque, offset=204, value)
while
[0x504] = value (write from uP register)
cause
read(opaque, offset=4, value)
The two opaque are different as expected.
Where i am wrong?
--- Ven 25/2/11, Blue Swirl blauwir...@gmail.com ha scritto:
Da: Blue Swirl blauwir...@gmail.com
Oggetto: Re: [Qemu-devel] Memory Map
A: Salvatore Lionetti salvatorelione...@yahoo.it
Cc: qemu-devel@nongnu.org
Data: Venerdì 25 febbraio 2011, 17:10
On Thu, Feb 24, 2011 at 11:08 AM,
Salvatore Lionetti
salvatorelione...@yahoo.it
wrote:
Hi,
This is what my board do
cpu_register_physical_memory(0, 128*1024*1024, ...)
cpu_register_physical_memory(0xFF80, 8*1024*1024,
...)
and this layout does not change over the entire live
(virtual) of the board.
For the following offset (1st column) and size in
bytes (2nd column)
{0x00, 512},
{0x000200, 16},
{0x000300, 32},
{0x000400, 32},
{0x000500, 64},
{0x000600, 64},
{0x000700, 128},
{0x000800, 30},
{0x000900, 256},
{0x000A00, 44},
{0x000B00, 256},
{0x000C00, 24},
{0x000F00, 20},
{0x001000, 20},
{0x001100, 20},
{0x001400, 168},
{0x001800, 24},
{0x002000, 4096},
{0x003000, 24},
{0x003100, 24},
{0x004500, 36},
{0x005000, 224},
{0x008000, 768},
{0x008300, 16},
i do, for each item,
a = cpu_register_io_memory(r, w, o,
DEVICE_NATIVE_ENDIAN)
cpu_register_physical_memory(_base+offset, len, a)
And _base could be reprogrammed at any time. So before
to change _base i:
cpu_unregister_io_memory(a)
What i see is that accessing to _base+
_base+0x005000 = Wake up r/w with offset 0
_base+0x000204 = Wake up r/w with offset 0x204
So the question
- Am i wrong something?
cpu_unregister_io_memory() is the counterpart of
cpu_register_io_memory(), it does not affect mappings
created by
cpu_register_physical_memory(). They should be removed
first.
- Is possible to map address with last
TARGET_PAGE_BITS (es 0x200) bits set?
Yes.
Re: [Qemu-devel] Memory Map
Hi, On Wed, Mar 2, 2011 at 12:11, Salvatore Lionetti salvatorelione...@yahoo.it wrote: Still now, some memory region is called with base+offset. So: [0x204] = value (write from uP register) cause read(opaque, offset=204, value) while [0x504] = value (write from uP register) cause read(opaque, offset=4, value) The two opaque are different as expected. Where i am wrong? If you mean 0x5004 and not 0x504 (as stated in your previous email), IMO it is a current limitation of the Qemu feature called subpage (which is used when you are mapping a memory area smaller than the MMU page size as in your example). When using subpages in the current code, the offset becomes the distance to the MMU page boundary instead of the distance to the base address of the peripheral. This is somewhat impractical and confusing when you are mapping the same subpage sized MMIO device at different addresses. As the emulation I'm working on has a lot of subpage sized peripherals, I have written a patch to workaround this limitation. I will send it to the list for comment if you want to try it. -- Vincent
Re: [Qemu-devel] Memory Map
On Thu, Feb 24, 2011 at 11:08 AM, Salvatore Lionetti
salvatorelione...@yahoo.it wrote:
Hi,
This is what my board do
cpu_register_physical_memory(0, 128*1024*1024, ...)
cpu_register_physical_memory(0xFF80, 8*1024*1024, ...)
and this layout does not change over the entire live (virtual) of the board.
For the following offset (1st column) and size in bytes (2nd column)
{0x00, 512},
{0x000200, 16},
{0x000300, 32},
{0x000400, 32},
{0x000500, 64},
{0x000600, 64},
{0x000700, 128},
{0x000800, 30},
{0x000900, 256},
{0x000A00, 44},
{0x000B00, 256},
{0x000C00, 24},
{0x000F00, 20},
{0x001000, 20},
{0x001100, 20},
{0x001400, 168},
{0x001800, 24},
{0x002000, 4096},
{0x003000, 24},
{0x003100, 24},
{0x004500, 36},
{0x005000, 224},
{0x008000, 768},
{0x008300, 16},
i do, for each item,
a = cpu_register_io_memory(r, w, o, DEVICE_NATIVE_ENDIAN)
cpu_register_physical_memory(_base+offset, len, a)
And _base could be reprogrammed at any time. So before to change _base i:
cpu_unregister_io_memory(a)
What i see is that accessing to _base+
_base+0x005000 = Wake up r/w with offset 0
_base+0x000204 = Wake up r/w with offset 0x204
So the question
- Am i wrong something?
cpu_unregister_io_memory() is the counterpart of
cpu_register_io_memory(), it does not affect mappings created by
cpu_register_physical_memory(). They should be removed first.
- Is possible to map address with last TARGET_PAGE_BITS (es 0x200) bits set?
Yes.
[Qemu-devel] Memory Map
Hi,
This is what my board do
cpu_register_physical_memory(0, 128*1024*1024, ...)
cpu_register_physical_memory(0xFF80, 8*1024*1024, ...)
and this layout does not change over the entire live (virtual) of the board.
For the following offset (1st column) and size in bytes (2nd column)
{0x00, 512},
{0x000200, 16},
{0x000300, 32},
{0x000400, 32},
{0x000500, 64},
{0x000600, 64},
{0x000700, 128},
{0x000800, 30},
{0x000900, 256},
{0x000A00, 44},
{0x000B00, 256},
{0x000C00, 24},
{0x000F00, 20},
{0x001000, 20},
{0x001100, 20},
{0x001400, 168},
{0x001800, 24},
{0x002000, 4096},
{0x003000, 24},
{0x003100, 24},
{0x004500, 36},
{0x005000, 224},
{0x008000, 768},
{0x008300, 16},
i do, for each item,
a = cpu_register_io_memory(r, w, o, DEVICE_NATIVE_ENDIAN)
cpu_register_physical_memory(_base+offset, len, a)
And _base could be reprogrammed at any time. So before to change _base i:
cpu_unregister_io_memory(a)
What i see is that accessing to _base+
_base+0x005000 = Wake up r/w with offset 0
_base+0x000204 = Wake up r/w with offset 0x204
So the question
- Am i wrong something?
- Is possible to map address with last TARGET_PAGE_BITS (es 0x200) bits set?
Have a good day
