[U-Boot] Debugging into the kernel from u-boot

[U-Boot] Debugging into the kernel from u-boot

[Dunda, Matthias]

Hi all-

I - more or less - successfully got U-Boot up and running on our custom
designed board.

U-Boot leaves its premices in boot_jump_linux and this is the last I see on
the console:

## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   Linux-2.6.29.6-rt23
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1830522 Bytes =  1.7 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 00400000
   Booting using the fdt blob at 0x400000
   Uncompressing Kernel Image ... OK
## Transferring control to Linux (at address 00000000)...
   Booting using OF flat tree...

When I halt the board using the BDI3000 debugger, I find the PC somewhere in
0xc000c96c in __delay. Accessing 0xc000.... makes no sense, as we don't even
have mapped memory there.

Using HW breakpoints I can see the single instructions from 0x0 on, but I
get no link to the source.

Where can I get a meaningful starting point in the kernel? 

Why are all the symbols in vmlinux located at 0xc0... and how does the
relocation take place? I saw some comment in arch/powerpc/kernel/setup_32.c
but yet I have no clue where to start practically?

Any help would be appreciated!

Have a nice weekend!
Matthias

[U-Boot] Debugging into the kernel from u-boot

[Stefan Roese]

Hi Matthias,

On Friday 30 April 2010 14:55:42 Dunda, Matthias wrote:
> I - more or less - successfully got U-Boot up and running on our custom
> designed board.
> 
> U-Boot leaves its premices in boot_jump_linux and this is the last I see on
> the console:
> 
> ## Booting kernel from Legacy Image at 02000000 ...
>    Image Name:   Linux-2.6.29.6-rt23
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    1830522 Bytes =  1.7 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
> ## Flattened Device Tree blob at 00400000
>    Booting using the fdt blob at 0x400000
>    Uncompressing Kernel Image ... OK
> ## Transferring control to Linux (at address 00000000)...
>    Booting using OF flat tree...
> 
> When I halt the board using the BDI3000 debugger, I find the PC somewhere
> in 0xc000c96c in __delay. Accessing 0xc000.... makes no sense, as we don't
> even have mapped memory there.

This address makes perfect sense. Linux maps physical address 0 to virtual 
address 0xc000000 on PowerPC.
 
> Using HW breakpoints I can see the single instructions from 0x0 on, but I
> get no link to the source.
> 
> Where can I get a meaningful starting point in the kernel?

You have all the equipment you need. Use the BDI3000 to debug the Linux 
kernel.
 
> Why are all the symbols in vmlinux located at 0xc0...

See above.

> and how does the
> relocation take place? I saw some comment in arch/powerpc/kernel/setup_32.c
> but yet I have no clue where to start practically?
> 
> Any help would be appreciated!

I suggest you take a look at this link as well:

http://www.denx.de/wiki/view/DULG/LinuxPostMortemAnalysis

Hope this helps.

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

[U-Boot] Debugging into the kernel from u-boot

[Dunda, Matthias]

Hi Stefan,

> 
> You have all the equipment you need. Use the BDI3000 to debug 
> the Linux 
> kernel.

is it correct, that I can only use HARD breakpoints? Because when I set
BREAK SOFT, the gdb always says it cannot access memory at c000....

And even with HW breakpoints I'm not able to do clean stepping thru the
code. The pointer jumps more or less arbitrarily thru the file resulting in
a crash after some steps.

[U-Boot] Debugging into the kernel from u-boot

[Wolfgang Denk]

Dear "Dunda, Matthias",

In message <569685F045B85741820D0265E0D2999D019CFE8C@tddhh01.hh.thales-naval.de> you wrote:
>
> is it correct, that I can only use HARD breakpoints? Because when I set
> BREAK SOFT, the gdb always says it cannot access memory at c000....

This should be a configuration issue, most probabl;y with your BDI
config file.

> From the BDI3000 documentation I assume, that using MMT XLAT and setting
> PTBASE is only important, if I load and start the kernel directly, without
> the initialization from U-Boot. Am I right?

No. These are always important when you want to debug the kernel. And
you need BDI support enabled in the kernel as well.

> For information I attach the log I read out of memory at __log_buf
> location... although I already posted that on the linuxppc-dev list...

Argh.. Multiple postings on several lists :-(

[Not to mention that, strictly speaking, this discussion is off topic
here.]

> Do you think, that there's maybe a hardware issue because of the timing
> errors in the call trace?

No.

> Is this the reason for the strange behaviour of the gdb when trying to step
> thru the code?

I don't know which "strange behaviour of the gdb" you are talking
about.  Did you read the available documentation and FAQ's on this
topic?

> I mean - assuming that the hardware is correct - I should be able to do
> "state-of-the-art" code stepping even at early stage like in
> early_init_devtree, right?

Right.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Spock, did you see the looks on their faces?"
"Yes, Captain, a sort of vacant contentment."