Hello,<br>Thanks for your response. <br><br>But can you suggest me a way to debug the start_kernel function because i am not getting any console output or printk present in start_kernel function. Because of this i debug the kernel startup procedure through serial port. And here i am getting logs till mmu on stage.<br>
Can you please suggest any method to debug this, except JTAG.<br><br>Thank & Regards<br>Girish<br><br>On Monday, September 24, 2012, Russell King - ARM Linux <<a href="mailto:linux@arm.linux.org.uk">linux@arm.linux.org.uk</a>> wrote:<br>
> On Mon, Sep 24, 2012 at 02:32:49PM +0530, Tryout check wrote:<br>>> Hi,<br>>><br>>><br>>> I am trying to Boot Linux kernel 3.0.1 on a custom hardware.<br>>><br>>> I am able to debug the Linux Kernel 3.0.1 boot process till<br>
>> __enable_mmufunction defined in head.S, using serial port.<br>>><br>>> But as soon as __turn_mmu_on function is performed I am not able to debug<br>>> the boot process.<br>>><br>>> I have gone through linux-arm-kernel mailing list archives & i have tried<br>
>> their printascii() work around. But still I am not able to see any boot<br>>> logs on serial console after __turn_mmu_on.<br>>><br>>> Here I am able to get logs before __turn_mmu_on so my serial console port<br>
>> is working fine.<br>>><br>>> And one more thing - I don't have JTAG.<br>>><br>>> Can anyone provide the solution how to debug Linux kernel Boot process<br>>> after turn MMU on?<br>
>><br>>> Thank you for the support.<br>><br>> Please post to the linux-arm-kernel list.<br>><br>> Debugging in this area is extremely fraught to the extreme.  Most peoples<br>> attempts at debugging this result in total failure (as yours is) because<br>
> their debugging code creates more problems than it solves.<br>><br>> Moreover, using debuggers in this area also seems to cause more problems.<br>><br>> The advice I've always given people is: remove all your debugging, and<br>
> check whether you get into the C code - start_kernel().  Most people who<br>> do that are surprised, because they find that they are getting there.<br>><br>> That's because the early assembly code has been well tested over the<br>
> years and is almost never a problem.  To reiterate the point - most<br>> problems in this code come down to people modifying it through their<br>> own "debugging" attempts.<br>>