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.
