* early kernel debugging
@ 2009-04-02 20:05 Yigal Goldberger
2009-04-03 16:04 ` Tirumala Reddy Marri
0 siblings, 1 reply; 6+ messages in thread
From: Yigal Goldberger @ 2009-04-02 20:05 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board .
I see that after uncompressing the kernel it hangs.
I found a location (System.map) I think corresponds to the __log_buf (my SDRAM starts at physical address 0 (and u-boot performs -> Load Address: 00000000 Entry Point: 00000000) .
So I just removed the leading C0xxxxxx from the address leaving xxxxxx .
And that's where I looked .
I did see 2 error messages (though they were somewhat corrupt) the first designated a memory fault and the second a kernel oops at some address.
I looked this address up on System.map and it's somewhere inside prom.c
in of_scan_flat_dt( ) .
I have a few question at this point :
A)Am I looking at the right memory location for __log_buf ?
B)What is printed to the buffer (printk's of what verbose level ?)
C)In a previous kernel version 2.6.14 I don't remember explicitly using a flat device tree or pointing at such a tree through the bootm command) , but I used the ARCH=ppc then as opposed to ARCH=powerpc Now .
I see a lot of stuff regarding the need to provide such a data structure upon booting via bootm .Do I need to explicitly prepare such a data structure and provide a pointer to it via bootm ?
Might this be the cause for this early hang ?
Best Regards,
Yigal Goldberger.
^ permalink raw reply [flat|nested] 6+ messages in thread* RE: early kernel debugging
2009-04-02 20:05 early kernel debugging Yigal Goldberger
@ 2009-04-03 16:04 ` Tirumala Reddy Marri
2009-04-03 16:47 ` Feng Kan
0 siblings, 1 reply; 6+ messages in thread
From: Tirumala Reddy Marri @ 2009-04-03 16:04 UTC (permalink / raw)
To: Yigal Goldberger, linuxppc-dev
I am not sure if I understand correctly. But Looks like you are not
passing the device tree along with kernel image and RAMDISK(you may not
need it if you are using NFS mount). You boot command should some what
look like this "bootm kernel_addr ramdisk_addr devtree_addr" or "bootm
kernel_addr - devtree_addr" . If you are already doing that I would
check my bootargs for correct params.
-----Original Message-----
From: linuxppc-dev-bounces+tmarri=3Damcc.com@ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=3Damcc.com@ozlabs.org] On Behalf Of
Yigal Goldberger
Sent: Thursday, April 02, 2009 1:06 PM
To: linuxppc-dev@ozlabs.org
Subject: early kernel debugging
Hi All,
I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board .
I see that after uncompressing the kernel it hangs.
I found a location (System.map) I think corresponds to the __log_buf (my
SDRAM starts at physical address 0 (and u-boot performs -> Load Address:
00000000 Entry Point: 00000000) .
So I just removed the leading C0xxxxxx from the address leaving xxxxxx .
And that's where I looked .=20
I did see 2 error messages (though they were somewhat corrupt) the first
designated a memory fault and the second a kernel oops at some address.
I looked this address up on System.map and it's somewhere inside prom.c
in of_scan_flat_dt( ) .=20
I have a few question at this point :
A)Am I looking at the right memory location for __log_buf ?
B)What is printed to the buffer (printk's of what verbose level ?)
C)In a previous kernel version 2.6.14 I don't remember explicitly using
a flat device tree or pointing at such a tree through the bootm command)
, but I used the ARCH=3Dppc then as opposed to ARCH=3Dpowerpc Now .
I see a lot of stuff regarding the need to provide such a data structure
upon booting via bootm .Do I need to explicitly prepare such a data
structure and provide a pointer to it via bootm ?
Might this be the cause for this early hang ?
Best Regards,
Yigal Goldberger.=20
=20
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: early kernel debugging
2009-04-03 16:04 ` Tirumala Reddy Marri
@ 2009-04-03 16:47 ` Feng Kan
0 siblings, 0 replies; 6+ messages in thread
From: Feng Kan @ 2009-04-03 16:47 UTC (permalink / raw)
To: Tirumala Reddy Marri; +Cc: linuxppc-dev, Yigal Goldberger
Hi:
Did you try the early kernel printk option in kernel hacking. It can
give some
very helpful information. Make sure the address for the physical uart
address is
passed in correctly.
Feng
Tirumala Reddy Marri wrote:
> I am not sure if I understand correctly. But Looks like you are not
> passing the device tree along with kernel image and RAMDISK(you may not
> need it if you are using NFS mount). You boot command should some what
> look like this "bootm kernel_addr ramdisk_addr devtree_addr" or "bootm
> kernel_addr - devtree_addr" . If you are already doing that I would
> check my bootargs for correct params.
>
> -----Original Message-----
> From: linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+tmarri=amcc.com@ozlabs.org] On Behalf Of
> Yigal Goldberger
> Sent: Thursday, April 02, 2009 1:06 PM
> To: linuxppc-dev@ozlabs.org
> Subject: early kernel debugging
>
>
> Hi All,
> I'm using u-boot to boot kernel 2.6.24.2 on a powerpc based board .
> I see that after uncompressing the kernel it hangs.
> I found a location (System.map) I think corresponds to the __log_buf (my
> SDRAM starts at physical address 0 (and u-boot performs -> Load Address:
> 00000000 Entry Point: 00000000) .
> So I just removed the leading C0xxxxxx from the address leaving xxxxxx .
> And that's where I looked .
> I did see 2 error messages (though they were somewhat corrupt) the first
> designated a memory fault and the second a kernel oops at some address.
> I looked this address up on System.map and it's somewhere inside prom.c
> in of_scan_flat_dt( ) .
>
> I have a few question at this point :
> A)Am I looking at the right memory location for __log_buf ?
> B)What is printed to the buffer (printk's of what verbose level ?)
> C)In a previous kernel version 2.6.14 I don't remember explicitly using
> a flat device tree or pointing at such a tree through the bootm command)
> , but I used the ARCH=ppc then as opposed to ARCH=powerpc Now .
> I see a lot of stuff regarding the need to provide such a data structure
> upon booting via bootm .Do I need to explicitly prepare such a data
> structure and provide a pointer to it via bootm ?
> Might this be the cause for this early hang ?
>
> Best Regards,
> Yigal Goldberger.
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Early kernel debugging
@ 2011-03-25 8:50 Guillaume Dargaud
2011-03-27 18:00 ` Philipp Ittershagen
0 siblings, 1 reply; 6+ messages in thread
From: Guillaume Dargaud @ 2011-03-25 8:50 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
what can you do when the kernel you try to run stops before printing anything on the console ?
I tried enabling the 'early printk' option, but still I get nothing.
I posted something about it in the 'Booting with ramdisk in kernel' message and I haven't improved the situation since
then, although I found the CONFIG_BLK_DEV_RAM option.
--
Guillaume Dargaud
http://www.gdargaud.net/
"Freedom is just chaos, with better lighting."
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Early kernel debugging
2011-03-25 8:50 Early " Guillaume Dargaud
@ 2011-03-27 18:00 ` Philipp Ittershagen
2011-03-27 23:25 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 6+ messages in thread
From: Philipp Ittershagen @ 2011-03-27 18:00 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
On 03/25/2011 09:50 AM, Guillaume Dargaud wrote:
> Hello all,
> what can you do when the kernel you try to run stops before printing anything on the console ?
http://elinux.org/Kernel_Debugging_Tips#Debugging_early_boot_problems
Basically it means connecting a debugger to the running kernel (using
XMD, for example) and then reading the printk log buffer, which contains
the last lines printed.
Hope this helps!
Philipp
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Early kernel debugging
2011-03-27 18:00 ` Philipp Ittershagen
@ 2011-03-27 23:25 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 6+ messages in thread
From: Benjamin Herrenschmidt @ 2011-03-27 23:25 UTC (permalink / raw)
To: Philipp Ittershagen; +Cc: linuxppc-dev, Guillaume Dargaud
On Sun, 2011-03-27 at 20:00 +0200, Philipp Ittershagen wrote:
> On 03/25/2011 09:50 AM, Guillaume Dargaud wrote:
> > Hello all,
> > what can you do when the kernel you try to run stops before printing anything on the console ?
>
> http://elinux.org/Kernel_Debugging_Tips#Debugging_early_boot_problems
>
> Basically it means connecting a debugger to the running kernel (using
> XMD, for example) and then reading the printk log buffer, which contains
> the last lines printed.
It actually mostly depends on the platform. There's various powerpc
specific early debug mechanisms that are more/less robust/functional
depending on the CPU type, the platform, etc...
Look in udbg.c, there's a list of early debug hacks in there controlled
by various config options.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-03-27 23:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-04-02 20:05 early kernel debugging Yigal Goldberger
2009-04-03 16:04 ` Tirumala Reddy Marri
2009-04-03 16:47 ` Feng Kan
-- strict thread matches above, loose matches on Subject: below --
2011-03-25 8:50 Early " Guillaume Dargaud
2011-03-27 18:00 ` Philipp Ittershagen
2011-03-27 23:25 ` Benjamin Herrenschmidt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).