Hello, I am working on a custom kernel, and I would like to add the necessary support to enable it to boot with qemu. In order to achieve that I am trying to debug it inside qemu by attaching a gdb to it. I still can't figure where the boot process is getting stuck with step-by-step execution, but it seems that the last function called is "delay_loop" from arch/x86/lib/delay.c. That function contains some assembly code, does someone know what it is supposed to do ? Beside, do you have any advice on the way I should proceed to get the necessary information to port the kernel ? Thanks. -- Apelete
On 06/29/11 16:14, Apelete Seketeli wrote:
Hello,
I am working on a custom kernel, and I would like to add the necessary support to enable it to boot with qemu. When you say "debug inside qemu", do you run gdb qemu or gdb vmlinux In order to achieve that I am trying to debug it inside qemu by attaching a gdb to it. you do this by adding -S -s to the qemu boot parameters. the from the gdb shell, target remote :1234. I still can't figure where the boot process is getting stuck with step-by-step execution, but it seems that the last function called is "delay_loop" from arch/x86/lib/delay.c. Have you run the backtrace (bt) command from the gdb shell? That should tell you what function is calling the __delay. That function contains some assembly code, does someone know what it is supposed to do ? Probably wait a specific amount of time. Since a compiler optimizes C you can't write an accurate delay in C. The compiler wont optimize the inline assembly. Beside, do you have any advice on the way I should proceed to get the necessary information to port the kernel ? You should find an existing board and tweak it to get started, or post the backtrace output.
Thanks.
Have you had any luck with a google search along the lines of "qemu gdb kernel"?
On 29-Jun-11, Christopher Harvey wrote:
On 06/29/11 16:14, Apelete Seketeli wrote:
Hello,
I am working on a custom kernel, and I would like to add the necessary support to enable it to boot with qemu. When you say "debug inside qemu", do you run gdb qemu or gdb vmlinux
"gdb vmlinux" actually. The focus is on the kernel, to know what going on during the boot process (since it doesn't boot in qemu).
In order to achieve that I am trying to debug it inside qemu by attaching a gdb to it. you do this by adding -S -s to the qemu boot parameters. the from the gdb shell, target remote :1234.
"qemu -S -kernel bzImage", then, using the monitor inside qemu I start a gdbserver to which I connect to debug the kernel.
I still can't figure where the boot process is getting stuck with step-by-step execution, but it seems that the last function called is "delay_loop" from arch/x86/lib/delay.c. Have you run the backtrace (bt) command from the gdb shell? That should tell you what function is calling the __delay.
I didn't, will try that and see if it helps.
That function contains some assembly code, does someone know what it is supposed to do ? Probably wait a specific amount of time. Since a compiler optimizes C you can't write an accurate delay in C. The compiler wont optimize the inline assembly.
Okay, so I really need to know which function is calling the delay and go down from there.
Have you had any luck with a google search along the lines of "qemu gdb kernel"?
Running gdb with qemu caused me some headache, but I got it, as said before. Thanks for the tips, I'll try and see if I can get something useful. -- Apelete
On Wed, 29 Jun 2011 23:27:41 +0200, Apelete Seketeli wrote:
On 29-Jun-11, Christopher Harvey wrote:
On 06/29/11 16:14, Apelete Seketeli wrote:
I still can't figure where the boot process is getting stuck with step-by-step execution, but it seems that the last function called is "delay_loop" from arch/x86/lib/delay.c. Have you run the backtrace (bt) command from the gdb shell? That should tell you what function is calling the __delay.
I didn't, will try that and see if it helps.
That command is your bread and butter. If you type "up" into gdb it will take you to the line that called __delay. Keep typing up to see exactly what series of functions were called to get to the __delay.
On Wed, Jun 29, 2011 at 10:14:41PM +0200, Apelete Seketeli wrote:
Hello,
I am working on a custom kernel, and I would like to add the necessary support to enable it to boot with qemu. In order to achieve that I am trying to debug it inside qemu by attaching a gdb to it. I still can't figure where the boot process is getting stuck with step-by-step execution, but it seems that the last function called is "delay_loop" from arch/x86/lib/delay.c. That function contains some assembly code, does someone know what it is supposed to do ? Beside, do you have any advice on the way I should proceed to get the necessary information to port the kernel ?
Does a stock kernel work in your setup? If so, try using its config, most distributions put it into /boot as config-`uname -r` or something. HTH, Jonathan Neuschäfer
participants (3)
-
Apelete Seketeli -
Christopher Harvey -
Jonathan Neuschäfer