On Tuesday 01 November 2011 14:37:24 Matthias Weisser wrote: > I don't know the memory layout strategies for all the Linux/Unix variant > out there. But typically text/bss/data is in the lower address range > (some megs above 0) and in the upper range (right under kernel space) > there is space used for stack and shared objects. Even with ASLR the > address I used in the patch should be mappable.
relying on any address layout behavior is doomed to fail. and in this case, it's unnecessary. so let's not bother. > >>> also, with Simon's other patch to md to use the remap func, the address > >>> of our memory backing store doesn't matter. > >> > >> Well, you are right. But with the posted patch you don't need any remap > >> function and md/mm/mtest/mw works out of the box. > > > > This is interesting. What is the test purpose of specifying a > > particular virtual address for your memory? > > Emulating the behavior of a u-boot on real hardware as close as > possible. We have some chunk of memory at a given location. Thats it. > With a minimum of additional work we can also simulate additional banks > of RAM using multiple mmaps. adding a CONFIG knob to control the virtual address of the memory is fine > > If this is useful then we should make the mmap function fail if it > > cannot honour the address, since otherwise presumably some tests will > > fail. > > Maybe. But on the other hand tests can always extract the actual address > of RAM from gd->bd->bi_dram[0].start. If test use these address we can > abandon the use of of fixed address. But I still thinks its nice to have > an aligned address of RAM start as this is what we have on (all?) real > hardware. i'd rather see bi_dram die than extend it. if you want to utilize the virtual memory, let's use the already existing map helper. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
