Hi all,
I am using uboot and montavista kernel for our custom MPC8555CDS board.
I enabled the following options in Kernel for kernel Debugging, CONFIG_BDI_SWITCH=y CONFIG_DEBUG_INFO=y under kernel hacking and MMU XALT in BDI config file. After uboot initialization I fixed break point at start_kernel(0xc02784bc), and then I booted the kernel. Without breaking at start_kernel, it came to login prompt. Please find attached config file with this mail. Could anybody help me to solve this problem?
Thanks in advance,
Saravanan.S
Bangalore.
On Sep 3, 2007, at 7:02 AM, dnl wrote:
Hi all,
I am using uboot and montavista kernel for our custom MPC8555CDS
board.
You should contact MontaVista first, since we really
don't know what your source code looks like. I'm
assuming it's a ppc, not powerpc, although the patch
is similar for either choice. I'd suggest this as a starting
point:
diff -Naru linux-2.6.21/arch/ppc/kernel/head_fsl_booke.S linux-2.6.21-
dbg/arch/ppc/kernel/head_fsl_booke.S
--- linux-2.6.21/arch/ppc/kernel/head_fsl_booke.S 2007-07-05
13:08:16.000000000 -0800
+++ linux-2.6.21-dbg/arch/ppc/kernel/head_fsl_booke.S 2007-07-10
03:45:33.000000000 -0800
@@ -317,6 +322,16 @@
/* clear any residual debug events */
li r2,-1
mtspr SPRN_DBSR,r2
+#else
+ /* Enable BDI200 debugging beyond this point for "normal"
+ * kernel debugging. If you are debugging code prior to this
+ * point, it needs to be done with more specific set up
+ * of configuration files and boot rom.
+ */
+ mfmsr r2
+ ori r2, r2, MSR_DE
+ mtmsr r2
+ isync#endif
Your first breakpoint should be a hard breakpoint
at the label start_kernel. You can then switch to
soft breakpoints and continue your debugging.
Ultimate Solutions have some useful white papers
on kernel debugging with the BDI2000 (that some
people have plagiarized). Check out ultsol.com
Good Luck.
-- Dan
On 9/4/07, dnl [off-list ref] wrote:
I enabled the following options in Kernel for kernel Debugging,
CONFIG_BDI_SWITCH=y CONFIG_DEBUG_INFO=y under kernel hacking and MMU XALT in
BDI config file. After uboot initialization I fixed break point at
start_kernel(0xc02784bc), and then I booted the kernel. Without breaking at
start_kernel, it came to login prompt. Please find attached config file with
this mail. Could anybody help me to solve this problem?
Hi Saravanan,
Try adding this line to your BDI config to clear/invalidate the page
table base address so that the MMU translation works before the MMU
has been initialised.
;; Following is to clear the page table base address
WM32 0x000000f0 0x00000000
Make sure that you reload the BDI config, I use the the BDI "BOOT"
command to do this.
Are you obtaining the start_kernel address from your kernel System.map
file and setting the breakpoint using the BDI command "BI 0xc02784bc"
or are you using a gdb debugger frontend ?
Bill
Hi,
Try adding this line to your BDI config to clear/invalidate the page
table base address so that the MMU translation works before the MMU
has been initialised.
;; Following is to clear the page table base address
WM32 0x000000f0 0x00000000
Did you really need this under any circumstance? To only hit a
breakpoint?
I am asking because recent experiences with BDI debugging showed that
there are some pitfalls that one can fall into (and these are only the
ones that I got aware of):
a) - PTBASE is 0x00 (!) for head_fsl_booke, head_44x,
- PTBASE is 0xf0 for head_4xx
Don't ask me if this makes any sense, but that's how it is right
now.
So for the original poster I would say a PTBASE 0x0 would be in
order.
b) Moreover even with a _wrong_ PTBASE on a 440EPx the BDI translated
start_kernel just fine by only subtracting 0xc0000000 (using a
"default" translation) - it was only later (debugging dynamic
modules) that the wrong PTBASE hit me hard.
What proved very useful for me is the bdi command "phys <addr>" to
check the translation the BDI uses [you can use the command (as all
BDI commands) through gdb with "mon phys <addr>" btw.] - a wrong
PTBASE led to subsequent "JTAG instruction overruns" so I was pretty
sure that this was my real problem.
Best wishes
Detlev
--
The limits of my language stand for the limits of my world.
-- Ludwig Wittgenstein
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
On Sep 5, 2007, at 6:27 AM, Detlev Zundel wrote:
Hi,
quoted
;; Following is to clear the page table base address
WM32 0x000000f0 0x00000000
Did you really need this under any circumstance? To only hit a
breakpoint?
No, you don't. For the identify mapped kernel
space, only the MMU XLAT is required, which
covers nearly all kernel. This is only necessary for
tracking vmalloc()'ed space, like for loadable
modules.
However, this WM32 should not be necessary
in any case, as the page table pointers for
BDI information tracking are set up by the
kernel initialization functions.
I am asking because recent experiences with BDI debugging showed that
there are some pitfalls that one can fall into (and these are only the
ones that I got aware of):
Yes, and I apologize for not allocating the
time to work with Abatron to make this
work better. The page tables changes
that have taken (and still take) place in
2.6 caused our original 2.4 implementation
to not work well. Abatron has made updates
that work well, but there are still some edge
cases that may not work well. I need to find
those and provide some assistance.
The whole of the Linux BDI configuration
has been abused as well, the BDI_SWITCH
should not be used as it is today. That
was not the intention for this particular
configuration option.
So for the original poster I would say a PTBASE 0x0 would be in
order.
It changes a little among the processor variants,
in particular traditional Power versus Book E.
Check the release notes and manuals for the
BDI2000, along with the information from
Ultimate Solutions to determine what is best.
b) Moreover even with a _wrong_ PTBASE on a 440EPx the BDI translated
start_kernel just fine by only subtracting 0xc0000000 (using a
"default" translation) - it was only later (debugging dynamic
modules) that the wrong PTBASE hit me hard.
That's correct. If the BDI firmware can find the
translation in the TLB, it will just use that. In the
case of many processors, this is either a wired
entry or a BAT. If the BDI firmware can't find
a valid translation, it walks the page tables.
For 8xx and some 40x, the PTBASE is required
as there may be no wired entries by default.
Just remember that the values for both MMU XLAT
and PTBASE must match the kernel software and
configuration. This is the only correct answer :-)
Documentation will describe the public source,
default configuration at the time of the writing,
but it's very easy to change and will cause
debugging problems.
Thanks.
-- Dan