MMU Initialization Problem

MMU Initialization Problem

[Nicolas Pohland]

Hi Mark,

I have the same problem on a FADS board and 2.3.10. I do not have a
solution yet, but maybe able to describe the
problem in more detail.


I can unzip the kernel at location 0 and then this space is mapped to
0xc0000000 in 1 8Mb page.
Then the start_here routine and in it the MMU_init function called.

This is what I found strange:

a. The level 1 descriptors in the table are made up of effective
addresses (or virtual) and
NOT of physical addresses. 

b. The valid bit (LSB) of the descriptor is not set to 1.

Have I missed something here ?

Ciao,
Nicolas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MMU Initialization Problem

[Dan Malek]

Nicolas Pohland wrote:

> 
> I can unzip the kernel at location 0 and then this space is mapped to
> 0xc0000000 in 1 8Mb page.

What do you mean?  You have to load zImage at or above 0x200000, then
jump to that location.  The boot code on the front of zImage has to
perform the uncompress of the kernel, and it further initializes the
board information sturcture for the rest of the Linux kernel.

> This is what I found strange:

You can't use the "standard" chip select and IMMR mappings that
most debuggers set for the FADS board.  The IMMR has to be well
into the kernel virtual space, something like 0xf0000000.

If you are using mpc8bug, you have to disable all debug and exception
traps, effectively removing the debugger capability.  You can't
debug Linux once the MMU is enabled, which happens within the first
few instructions.


> Have I missed something here ?

You should really get on the linuxppc-embedded mailing list.  All of
this was recently discussed, along with many other things that would
be helpful toward what you are doing.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/