"Now booting the kernel"

"Now booting the kernel"

[Nitesh Guinde]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

Hello all,
I am loading a linux kernel onto ML310 board .I want networking support and
hence I have a pci enabled design.
I am using linux 2.4 powerpc devel kernel. I have also tried the montavista
previewkit
But I end up with the same problem. I have enabled the option " support for
early boot texts: in the kernel debugging.
Now once run the kernel program in powerpc I get the following essages in
the serial minicom terminal
Enter Desired System ACE CF Configuration <0-7>.
0: ACE-loader.
1: Linux w/PCI.
2: VxWorks w/PCI.
3: QNX Demo.
4: Linux EDK Base Build.
5: VxWorks EDK Base Build.
6: User Configuration A.
7: User Configuration B.


Select:
loaded at: 00400000 008CB1E0
board data at: 008C8138 008C8150
relocated to: 00405308 00405320
zimage at: 00405813 004DE42A
initrd at: 004DF000 008C7382
avail ram: 008CC000 10000000


Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
Uncompressing Linux...done.
Now booting the kernel


The prompt goes dead at this point.The board details is available at
www.xilinx.com/ml310 <http://www.xilinx.com/ml310>

Any workarounds?

Thanks,

Nitesh

[-- Attachment #2: Type: text/html, Size: 1518 bytes --]

Re: "Now booting the kernel"

[Nathael PAJANI]

 >Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
 >Uncompressing Linux...done.
 >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.

Re: "Now booting the kernel"

[Nathael PAJANI]

(Sorry, I first replyed with the wrong mail address)

 >Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part2 rw
 >Uncompressing Linux...done.
 >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.

Re: "Now booting the kernel"

[Nitesh Guinde]

Hello Nathael,
I tried the stuff but I am still getting the same result.
I did not find the  section "/* 2. Invalidate all entries except the
 entry we're executing in */" So I commented the TLBWE line in the
section which says "invalidate all TLB entries " . Is it correct? The
ASM code for rebooting will have to be changed for my board... right?
Nitesh

Re: "Now booting the kernel"

[drizzt]

Hi,

> I tried the stuff but I am still getting the same result.
This step can be quite hard to go over... do not deseparate :)

> I did not find the  section "/* 2. Invalidate all entries except the
>  entry we're executing in */" So I commented the TLBWE line in the
> section which says "invalidate all TLB entries " . Is it correct?
I think it is.
Do not forget to uncomment it when you start having outputs.

> The ASM code for rebooting will have to be changed for my board... right?
Yes

On my board, this is a feature of the VME bus, which you should'nt have, 
so check for an instruction or register to perform a reset.


Have fun :) :)
Nathael.

Re: "Now booting the kernel"

[David H. Lynch Jr.]

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 !?

Re: "Now booting the kernel"

[David H. Lynch Jr]

David H. Lynch Jr. wrote:
> 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.
Sorry, this is Linux 2.6.14 on a Xilinx-VI