Re: [U-Boot] Debugging into the kernel from u-boot
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.
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?
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...
Do you think, that there's maybe a hardware issue because of the timing errors in the call trace?
Is this the reason for the strange behaviour of the gdb when trying to step thru the code?
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?
Thanks! Matthias
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
participants (2)
-
Dunda, Matthias -
Wolfgang Denk