-- On 1/8/07, Ralf Baechle <email@example.com> wrote:
On Mon, Jan 08, 2007 at 06:44:51PM +0100, Franck Bui-Huu wrote:
> This patch makes a better usage of these two globals.
> 'min_low_pfn' is now correctly setup for all configs, which
> allow us to rely on it in boot memory code init.
From a working kernel:
Determined physical RAM map:
memory: 00001000 @ 00000000 (reserved)
memory: 000ef000 @ 00001000 (ROM data)
memory: 0035a000 @ 000f0000 (reserved)
memory: 03bb6000 @ 0044a000 (usable)
So it's basically 64MB starting at physical 0.
Oh and Malta does not use CONFIG_HIGHMEM.
Yeah I just noticed that, Malta supports highmem but actually doesn't
Regarding to your mapping, usable ram starts at 0x44a000. So
min_low_pfn is now set to the corresponding pfn and the bootmem alloc
assumes it's the begining of your memory. This is done by
bootmap_size = init_bootmem_node(NODE_DATA(0), mapstart,
However, old code always assumed that the begining of the memory was
0. That was done by:
bootmap_size = init_bootmem(mapstart, highest);
After a while paging_init() is called which in turn calls:
which expands to:
free_area_init_node(0, NODE_DATA(0), zones_size,
__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
In your case "__pa(PAGE_OFFSET) >> PAGE_SHIFT" results in 0 since you
haven't applied patch #2 and setup PHYS_OFFSET. So now, we're assuming
that the start of physical mem is 0 and I think it's wrong since we
previously assumed a different value.
Could you try to apply patch #2 on top of patch #1 and give it a try ?
I expect your kernel to panic in a different way. This time you should
be shooted by the following sanity check added by patch #2:
if (min_low_pfn != ARCH_PFN_OFFSET)
panic("PHYS_OFFSET(%lx) and your mem start(%lx) don't match",
If so, could you give another try with PHYS_OFFSET defined as follow:
#define PHYS_OFFSET 0x44a000
BTW mem_map size should be 32Kb smaller.