I sent this to the list earlier, but didn't see it show up. In case my mail server ate it, I'm sending it again.
Sorry if it's a dup. On 07/29/2010 10:47 AM, Danke Xie wrote: > This is quite amazing -- very few know this way of using the D+/D- > pins for debugging. Does the ttyMSM0 device really drive the D+/D- > pins? It seems to be mux'ed with the usb driver? If this indeed works, > the serial cable discussed here may be usable too: > http://www.instructables.com/id/Android-G1-Serial-Cable/ On 07/29/2010 01:53 AM, Sven Killig wrote: >> >> Does the N1 have an exposed serial port? > > > > It seems so: > > http://torvalds-family.blogspot.com/2010/02/happy-camper.html?showComment=1265528826941#c1560421512945796421 After posting, I found this: http://forum.xda-developers.com/showthread.php?t=625434 which should allow you to use the serial console. But it looks like you have to build your own hardware, and also rebuild the kernel with options for serial console and no FIQ (See Brian Swetland's comment on that thread.) In cases where the kernel dies before you even get serial console output, there's CONFIG_DEBUG_LL and printascii, which you can use send output to the serial port before the console is initialized. You may want to check out: http://elinux.org/Kernel_Debugging_Tips#Debugging_early_boot_problems Unfortunately, most of the tips there assume you have access to some kind of interactive prompt in the bootloader, which is not the case for the N1, that I am aware of. Google also added a feature to the kernel which allows seeing the messages from the last kernel boot, when you can successfully load a good kernel on a subsequent run. It depends, IIRC, on the current kernel reading a portion of memory that was saved from the last kernel that ran. (So it likely requires a reset and not a power cycle. But I've done quick power cycles before (under 20 seconds) and still been able to get memory contents from a previous kernel run.) I've never found good documentation on it, but see CONFIG_RAM_CONSOLE in Kconfig and in the code. The last kernel's messages are available at: /proc/last_kmsg. I don't know if this would be useful in this context or not. Finally, if there's a way to toggle an LED from the kernel, then sometimes that's all one needs to be able to work through the code to find the problem. You use it as a "got to here!" marker and keep moving it around in the code to narrow down where the hang is coming from. It can require a brutal number of recompiles, but it works. (The kernel boot code is pretty serial in execution, which makes this possible.) -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment ============================= -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
