Re: SPARSEMEM support for Atmel AT91SAM9G45 and M10
Nicu Pavel <[email protected]>
| Newsgroups | gmane.linux.ports.arm.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Marek, Did a similar mapping as you suggested, but high_memory value still holds only the first mapping address. Thanks, Nicu Pavel On Wed, May 26, 2010 at 5:10 PM, Marek Vasut <[email protected]> wrote: > Dne St 26. května 2010 15:46:21 Yegor Yefremov napsal(a): >> > I'm resurrecting an old thread >> > >> > (http://lists.arm.linux.org.uk/lurker/message/20090914.072902.97115112.en >> > .html) about using the two memory banks available >> > on Atmel AT91SAM9G45/M10. I managed to make it work on 2.6.30 by >> > following Russell King advice on how to configure SPARSEMEM. >> > >> > I submitted a working patch for 2.6.34 here: >> > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6143/1 >> > >> > The problem is that I'm unsure how to get rid of the #define that >> > forces high_memory value in mm/init.c, should I add a fixup function >> > to board-sam9m10g45ek.c to provide meminfo information ? >> >> I've already tested the patch on 2.6.33 and it is working properly. >> Concerning high_memory value problem I think the cause is how >> find_node_limits() in arch/arm/m/init.c is implemented. We have two memory >> banks one starting at 0x70000000 and another at 0x200000000. The virtual >> mapping looks like this: >> >> 0x70000000 -> 0xc0000000 >> 0x20000000 -> 0xc8000000 >> >> However find_node_limits() routine is working with physical addresses so >> the upper limit is 0x70000000 and not 0x20000000 as it should be. As a >> result max_low is pointing to 0x70000000 and that's why only first bank >> will be mapped correctly. >> >> How can find_node_limits() be changed to work with virtual addresses? >> >> Regards, >> Yegor >> > Hey, try searching for "[PATCH 1/5] pxa/vpac270: Enable SparseMEM for 256 MB of > RAM" ... The device has also one memory bank mapped under the primary one. Maybe > that can help. Cheers >> >> _______________________________________________ >> linux-arm mailing list >> [email protected] >> http://lists.infradead.org/mailman/listinfo/linux-arm >