Resending because list address was garbled on the first try. On Mon, 8 Dec 2008 09:01:07 -0800 Michael Sundius <msundius@xxxxxxxxx> wrote: > well, attached is a patch for arch/mips/kernel/setup.c > > we've done lots of other stuff to this file this but I think this is > the essential > part you need to make sure that the bootmem allocator knows > about the memory before your kernel. > > note that I moved the call to memory_present() not for this issue but > to make sparsemem work (though I've changed that again > to call memory_present() from add_memory_region() since it > seems to make more sense to call it there. > > you may also want to think about using sparse memory model > as it will likely give your ap developers even more room. Well thanks for this, it seems pretty straight forward. I thought maybe there was something more nefarious preventing this from working so I'll work it in and see how it goes. Cheers, a > good luck. > Mike > > VomLehn, David wrote: > > Er, it's kind of a good news/bad news joke... > > > > The bad news is that MIPS Linux isn't smart enough, at least as of > > 2.6.24, to use memory that precedes the kernel. > > > > The good news is that we've got changes that will handle this. > > > > The bad news is that I'm so backed up even getting a basic patchset > > to add our platform to the kernel mainline that I don't know how > > long it will take until I'm be able to get these additional patches > > out. > > > > I'll cc the guy who did the changes to see if he can extract a > > patch for this. > > > > > >> -----Original Message----- > >> From: linux-mips-bounce@xxxxxxxxxxxxxx > >> [mailto:linux-mips-bounce@xxxxxxxxxxxxxx] On Behalf Of Andrew Sharp > >> Sent: Friday, December 05, 2008 6:18 PM > >> To: linux-mips@ > >> Subject: question regarding system memory whatever > >> > >> I recently changed plat_mem_setup() or equivalent in my platform > >> code to not mark the first 32M of memory as BOOT_MEM_ROM_DATA and > >> instead have the first BOOT_MEM_RAM memory region start at 0. > >> Here is the two lines of output from mem_init() for the two > >> different versions: > >> > >> Memory: 433408k/475136k available (2202k kernel code, 41556k > >> reserved, 690k data, 112k init, 0k highmem) > >> > >> Memory: 433408k/507904k available (2202k kernel code, 74324k > >> reserved, 689k data, 112k init, 0k highmem) > >> > >> As you can see, the 32M got added to "reserved" memory (?) and only > >> added to the right hand number of the "available". OK, so what > >> does that mean? I promised our monkey userspace programmers that > >> they would have another 32M of memory to slosh around in, but > >> before I release this change on them I'd like to know what these > >> numbers are telling me. > >> > >> This is on 2.6.22 from l.m.o on a Sibyte 1125 in 64bit LE. > >> CONFIG_FLATMEM=y which was the fashion at the time.
