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 >
