On 24 March 2013 19:35, Rabin Vincent <ra...@rab.in> wrote: > 2013/3/24 Peter Maydell <peter.mayd...@linaro.org>: >> On 24 March 2013 17:27, Rabin Vincent <ra...@rab.in> wrote: >>> /** >>> + * memory_region_get_addr: Get the address of a memory region >>> + * >>> + * @mr: the memory region >>> + */ >>> +hwaddr memory_region_get_addr(MemoryRegion *mr); >> >> I'm afraid this doesn't make sense. A MemoryRegion by itself has >> no "address" -- it could be mapped into several places in several >> different address maps or none at all. > > OK. Do you mean that such a function can be used internally to the dump > code where it gets the MemoryRegion only from the RAMBlock.mr or do you > mean the dump code also shouldn't be doing it that way?
I mean that the dump code is wrong if it's trying to ask "what is the address of this MemoryRegion (or RAMBlock)" at all. That question doesn't have a well defined single answer. > If you mean the latter, could you please suggest an alternative way to > handle this? The problem is that the dump code assumes that > RAMBlock.offset provides the physical address, and this appears to not > be the case. That is also wrong, both for the reason you state and also because ramblocks can be aliased into multiple physical addresses too. I suspect you need to change anything that's trying to iterate through memory with "for each block in ram_list" to instead actually iterate through the system address space and say "if this is RAM then...". For instance with the vexpress-a9 you presumably want a LOAD section for both physaddr 0 (the alias) and physaddr 0x60000000 (the usual address). -- PMM
