"Now booting the kernel"

Hi!

At this state the bootloader stops executing and the Linux Kernel starts. The problem is that the Linux kernel does not know yet how to use the serial.

You won't have any message before it is set up (in early-console if my memory is allright)

So what you can do to check what's going on, is put "breakpoints" in the boot sequence. This means in the file arch/ppc/kernel/head*.S used for your board you should try to comment the line with the "tlbwe" instruction in the section "/* 2. Invalidate all entries except the entry we're executing in */" This will allow you to keep access to your board registers.

Then you go step by step, putting some code which will reboot the board when executed, so you know you're going up to that point, and then move the "breakpoint" further.

This code does the reboot (for the booke I can reboot the board by writting '4' at address 0xfa001001):

ASM:
lis r4,0xfa00
li r5,4
stb r5,0x1001(r4)
msync

C:
*((volatile unsigned char*)0xfa001001 = 4;

This way, instead of hanging up, the board reboots and you know where you are.

If you're going up to this:
bl machine_init /* arch/ppc/kernel/setup.c */
bl MMU_init /* arch/ppc/mm/init.c */
It's quite good, these are C functions, but they are processor specific, once again, check that the ones used (compiled) are those you need.

And next you've got the "start_kernel" call, which leads you to C code definitely. It's in init/main.c.

I hope I did not tell anything wrong, and that this will help.

Have fun.
Nathael.

I am having similar difficulties on a Xilinx Virtex 4.

I have some advantages over Nitesh in that I have a 32bit port at
0x70000000 that I can write values to and see what they are (at least until the MMU is enabled)
and with some additional complexity use as a sort of UART to write text.

Thus far this is what I get:

Starting MonitorX.elf: V3.3.2.0.
Loading zImage.elf.

loaded at:     00400000 0048C138
board data at: 0048A124 0048A138
relocated to:  004050AC 004050C0
zimage at:     00405865 00489E79
avail ram:     0048D000 08000000

Linux/PPC load: console=ttyS0,9600 console=tty0 root=/dev/sda2 Uncompressing Linux...done.
Now booting the kernel

After that I am in arch/ppc/kernel/head_4xx.S and only get output from my debug port. I have used that to determine as follows:

B1B1B1B1 - @head_4xx.S
00058001 - @initial_mmu
C0000000 - output Virtual
Address of KERNELBASE
00000000 - output physical
address of KERNELBASE
00057003 - @setup tlb
entry for debug console
70000000 - physical
address of memory to create tlb for debug console (same as debug port)
00057002 - @turn_on_mmu
00021032 - MSR Machine
status register
C00022A0 - virtual address
of start_here
40000000 - physical
address of start_here ??? shouldn't this be 000022A0 ?

I can trace right up to the rfi that kicks the processor into virtual mode.
The very first thing I have done at start_here is write a unique value to my debug - I never see that.

That should mean either:
I do not have the correct tlb entry to enable my debug port to
work once the MMU is enabled
or
I am not getting to start_here.

Interestingly I also output identifiers for exceptions - and I am getting repeated DTLB miss exceptions - all for address FFB13458

I also did memory dumps of what I thought were interesting regions at the end of load_kernel

The dump of 0x0 looks very much like the start of head_4xx.S - the signature values I am writing to my debug port (as well as the address of the debug port itself) all in close proximity are tty good clues.

the dump of 0x400000 looks like the start of arch/ppc/boot/simple/head.S which is what I would expect.

the dump of 0x22a0 looks like start_here.

The only thing I see that seems to be wrong is that if I use tophys() to try to convert start_here to a physical address I don't think I should get 0x40000000 For reference a snippet of my debug output code is below.

            lis     r14,0x7000                                       // 
high address of debug port
            lis     r0,0x5
            ori    r0,r0,0x7002                          
            stw   r0,4(r14)
            eieio                                                      

// output 0x57002

lis r0,start_here@h //
output start_here (virtual)

            ori     r0,r0,start_here@l
            stw     r0,4(r14)
            eieio
  
            tophys  (r0,r0);                                          
// output start_here physical
            stw     r0,4(r14)
            eieio

Help !?

Sorry, this is Linux 2.6.14 on a Xilinx-VI