Difference between revisions of "Kernel Debugging Tips"
(→Accessing the printk buffer after a silent hang on boot: add bold to tip) |
(Add OSK example) |
||
Line 7: | Line 7: | ||
silent is to dump the printk buffer from the boot | silent is to dump the printk buffer from the boot | ||
loader. To do it you have to know how your boot | loader. To do it you have to know how your boot | ||
− | loader maps memory compared to the kernel. | + | loader maps memory compared to the kernel. |
− | what I do with Redboot on i.MX31: | + | |
+ | === Redboot example on a Freescale ADS board === | ||
+ | Quinn says: Here's what I do with Redboot on i.MX31: | ||
fgrep printk_buf System.map | fgrep printk_buf System.map | ||
Line 28: | Line 30: | ||
useful in debugging your console. | useful in debugging your console. | ||
+ | === U-boot example on an OMAP OSK board === | ||
+ | Tim Bird tried these steps and they worked: | ||
+ | |||
+ | grep __log_buf System.map | ||
+ | |||
+ | or | ||
+ | |||
+ | grep __log_buf /proc/kallsyms | ||
+ | |||
+ | These show: | ||
+ | |||
+ | c0352d88 B __log_buf | ||
+ | |||
+ | In the case of the OSK, this address maps to | ||
+ | 0x10352d88. So I reset the target board and use the following: | ||
+ | |||
+ | OMAP5912 OSK # md 10352d88 | ||
+ | 10352d88: 4c3e353c 78756e69 72657620 6e6f6973 <5>Linux version | ||
+ | 10352d98: 362e3220 2e32322e 612d3631 6e5f706c 2.6.22.16-alp_n | ||
+ | 10352da8: 7428206c 64726962 6d697440 6b736564 l (tbird@timdesk | ||
+ | 10352db8: 2e6d612e 796e6f73 6d6f632e 67282029 .am.sony.com) (g | ||
+ | 10352dc8: 76206363 69737265 33206e6f 342e342e cc version 3.4.4 | ||
+ | 10352dd8: 34232029 45525020 54504d45 65755420 ) #4 PREEMPT Tue | ||
+ | ... | ||
+ | |||
+ | |||
[[Category:Development Tools]] | [[Category:Development Tools]] |
Revision as of 14:33, 12 February 2008
Here are some miscellaneous tips for debugging a kernel:
Accessing the printk buffer after a silent hang on boot
Quinn Jensen writes:
Something I've found handy when the console is silent is to dump the printk buffer from the boot loader. To do it you have to know how your boot loader maps memory compared to the kernel.
Redboot example on a Freescale ADS board
Quinn says: Here's what I do with Redboot on i.MX31:
fgrep printk_buf System.map
this shows the linked address of the printk_buf, e.g.:
c02338f0 b printk_buf.16194
The address "c02338f0" is in kernel virtual, which, in the case of i.MX31 ADS, redboot will have mapped to 0x802338f0. So, after resetting the target board, but without letting it try to boot again, at the redboot prompt,
dump -b 0x802338f0 -l 10000
And you see the printk buffer that never got flushed to the UART. Knowing what's there can be very useful in debugging your console.
U-boot example on an OMAP OSK board
Tim Bird tried these steps and they worked:
grep __log_buf System.map
or
grep __log_buf /proc/kallsyms
These show:
c0352d88 B __log_buf
In the case of the OSK, this address maps to 0x10352d88. So I reset the target board and use the following:
OMAP5912 OSK # md 10352d88 10352d88: 4c3e353c 78756e69 72657620 6e6f6973 <5>Linux version 10352d98: 362e3220 2e32322e 612d3631 6e5f706c 2.6.22.16-alp_n 10352da8: 7428206c 64726962 6d697440 6b736564 l (tbird@timdesk 10352db8: 2e6d612e 796e6f73 6d6f632e 67282029 .am.sony.com) (g 10352dc8: 76206363 69737265 33206e6f 342e342e cc version 3.4.4 10352dd8: 34232029 45525020 54504d45 65755420 ) #4 PREEMPT Tue ...