Resending because list address was garbled on the first try.
On Mon, 8 Dec 2008 09:01:07 -0800 Michael Sundius <firstname.lastname@example.org>
> 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.
> good luck.
> 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: email@example.com
> >> [mailto:firstname.lastname@example.org] 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.