Debugging bootloop: Get an information log without ADB? Can an emulator help? Possible Duplicate:
  Android boot-up messages for debugging?  




Related to this post I created:  Does the Android emulator generate some sort of log file I can access if it crashes?

I have been searching and trying to figure out if there is any way at all to get some kind of debugging information or any kind of kernel messages from an Android phone if it gets stuck at a bootloop state?  That means the phone gets stuck at the "Google" splash-screen, then crashes, then goes to that, then crashes.

I know the phone has several stages of bootloading, but for me to even figure out why my system image/modified kernel is making the phone crash, I need to at least know where the phone is crashing?

Is there any kind of log the Android emulator maybe spits out that shows it going through the stages of booting:  i.e. stage 1 bootloader, main stage bootloader, kernel being loaded, initialization process, Zygote, Zygote initializing Dalvik VM, execution of system server, then boot completed (when the ACTION_BOOT_COMPLETE flag/event is raised).

I've tried modifying init.rc to echo commands to a boot log (but it didn't work, though I don't know if the phone makes it to that stage, all I have is a useless splash screen), I've tried any of the ADB stuff but of course ADB doesn't work if the phone doesn't reach a stable state, the Linux dmesg command only works to show that the phone plugged in via USB, and the Android developers have chosen not to at least explain to me that only they hold those kinds of developer tools. Can anyone give me some guidance of what I can do to debug the boot process?  There has to be some kind of log you can access with the emulator at least.

In other words, how does anyone get any kind of log from their phone/emulator if gets stuck in a bootloop?

Further information, my kernel version I believe I have downloaded for my phone build is Linux kernel release 3.x (stock kernel pulled from the tuna folder and using the "omap" project), for Android Galaxy Nexus (maguro), with the platform being Android 4.0.3 ICS.
You will know if the kernel has hung, the led light stays on and not go further. 

As for your question, you need to be more clearer and specific as we do not know and since you posted a similar question before. You have not stated, what device is it, what android version is it, what kernel is it, all those are left out and thusly playing a guessing game here.


Is it the ramdisk not created correctly? 
Is it the address used for booting incorrect? 
Is the ROM built for VMSPLIT 3G and the kernel is built with VMSPLIT 2G or vice versa? 
What chipset is it? ARMv7 kernel with ROM compiled for ARMv6... 
Is the kernel actually booting? if yes, how do you know?


Far too many things here to speculate.

Edit: 

This bit is related to kernel level debugging.

The only way you can know if the kernel is indeed booting in the first place is to use a USB to Serial TTY cable with JTAG pinouts on a small circuit board clipped/soldered to the back of the device in question, and having the serial driver compiled into the kernel and treating the console as a tty device, and reading from it via minicom or hyperterminal to see the boot up sequence. 

As for bootloops,

The cause of boot-loops are down to the ROM itself, the initialization sequence is crashing somewhere. Now be careful :), the kernel in itself, can boot-loop also due to malfunctioning driver, panic's and reboots itself. 

So the question is, which is it?, Is it the kernel that keeps rebooting itself or has it got passed that stage and started loading the ROM? If its at the stage of loading the ROM, then something in the initialization is crashing, when the ROM crashes, it sends a signal to shutdown SurfaceFlinger, AudioFlinger, adb daemon, MedaServices etc. 

What you can do is this - in the init.rc, where you have this:

service console /system/bin/sh
    console
    disabled
    user shell


Change disabled to enabled, the next time, Android will dump you into the console, i.e. no familiar graphical interface.

Also, look for the  lines containing servicemanager, if the adbd daemon is listed there, take it out as what happens is the directive clause critical and onrestart will cause you to not have any adb facility!