Subject: need help booting EDB7211 eval board under 2.4.0-test*

From: Mike Touloumtzis <[email-masked]>
Date: Sat, 26 Aug 2000 18:26:18 -0700

Hi,

I'm trying to get a Cirrus Logic EDB7211 evaluation board booting the
2.4.0 kernels.  I have the basic architecture files and a serial driver
written/ported, everything compiles and links, and now I'm trying to
get it booting to userspace.

My current kernel is patched against 2.4.0-test3-pre7-rmk1, so it's a
little out of date.

The EDB7211 has non-contiguous physical memory, so like the SA-1100
I'm using the NUMA support (two nodes, each with one bank, and using a
similar bit-shifting trick with __virt_to_phys and __phys_to_virt).

#define __virt_to_phys(x)  (((x) & 0xff7fffff) | ((x) & 0x00800000) << 1)
#define __phys_to_virt(x)  (((x) & 0xfeffffff) | ((x) & 0x01000000) >> 1)

DRAM part of the memory map is:
	Physical	Virtual		Size	NUMA Node
	--------	-------		----	---------
	0xc0000000	0xc0000000	8 MB	0
	0xc1000000	0xc0800000	8 MB	1

(the amount of DRAM is fixed, so I chose to make DRAM virtually
contiguous).

A problem arises when arch/arm/mm/init.c:paging_init() tries to set up
the second node.  The boot process hangs (the kernel's probably caught
in some trap handler somewhere; I haven't figured out where) when it
tries to set up the mem_map array for the second node.

The stack looks like this:

	alloc_bootmem_core()	mm/bootmem.c
	alloc_bootmem_node()	mm/bootmem.c
	free_area_init_core()	mm/page_alloc.c
	free_area_init_node()	mm/numa.c
	paging_init()		arch/arm/mm/init.c
	... more stuff ...

When I investigated, it turns out that free_area_init_core() wants to
allocate each node's mem_map within the node itself, so it passes the
nid to alloc_bootmem_node().  The hang occurs when alloc_bootmem_core()
tries to zero the newly allocated bootmem area; access to the 0xc0800000
region (second bank) doesn't work.

Upon further checking, I couldn't access 0xc0400000 (halfway through the
1st bank) either.  I added serial output to pagetable_init in mm-armv.c
(now called memtable_init) and it's handling both nodes as expected;
physical and virtual addresses all check out.  It's like the new page
tables don't 'take', and I'm still going through the boot-time 4MB
page directory.

My questions are:

-- Is there some point after [page|mem]table_init at which the values
   are actually 'kicked in', or do they take effect right away?
-- Does pagetable_init modify the swapper_pgdir directory, and is the
   swapper_pgdir the main pgdir for kernel access from task 0?
-- Does anyone know what the heck is going on :-)?

Also, what is the intended purpose of FLUSH_BASE and FLUSH_BASE_PHYS,
and how should they be chosen?  I'm a little unclear on what they are
used for, and they're suspicously proximate to the failure point.

I can boot beyond this point (to other memory related problems outside
the scope of this mail :-) if I remove the second node (leaving 8MB of
contiguous memory) from arch/arm/kernel/arch.c.

I'm just learning both the ARM architecture and the guts of the kernel,
so I thought I'd ask to see if anyone here had insight into the problem.

miket

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]