how to debug Linux kernel boot process after turn MMU on stage [ I tried linux-arm-kernel mailing list arch workaround but issue]

[Tryout check]

Hello,
Thanks for your response.

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.
Can you please suggest any method to debug this, except JTAG.

Thank & Regards
Girish

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