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(0xFF800000, 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)
> > {0x000000, 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.
>
