Skip to contentSkip to conversation

MMU Initialization Problem

DISCUSSION Nicolas Pohland 2 participants 2 messages Nov 9, 1999

lore
Share & tools
lore
#0 lore raw

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/

#1 lore raw
Quoted 3 lines · Nicolas Pohland

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.

Quoted 1 line

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.

Quoted 1 line

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/