As much as I despise Qualcomm's lock down practices, I must admit that the Qualcomm processor is pretty darn solid. There aren't too many problems with Qualcrapp 
. However, that's now and I've got some information which may help some of you out in the future.
I did some hacking last night on a live stream with a few other XDA members from this and other forums. The goal was to find the UART location on the AT&T Galaxy S3.
Why, you might ask, would this be useful? During kernel and bootloader development, sometimes the device won't boot to the point where you can obtain logs to determine the problem. UART can provide the realtime eyes-on that you need to troubleshoot such problems.
So the process was as follows... On a rooted device, pull the kernel. Extract it. Add command line parameters to enable UART.
Recompress into a boot.img. upload with Heimdall. Teardown the device. Adb shell into the device. Execute the following code so you push data through the UART port and know if the device has locked up.
After that, you can locate the UART port by probing at 115200bps.
The TX from the board (your RX lead] is placed 2nd from the bottom on the battery side of the board. RX is either the one above that or middle on the other side.
Video:
In the video, at about 5 minutes in, I said I didn't know what the 31 value was... and the kmesg logs were pretty thin.. Well, turns out they are the kernel message levels. For full logging, change that to 987654321. Samsung usually uses the 9 identifier to represent shell access.
So, I hope this helps. UART provides eyes before any other method of debugging (aside from JTAG) begins to work. UART is the first thing to do in order to make a device into a development board.
. However, that's now and I've got some information which may help some of you out in the future.I did some hacking last night on a live stream with a few other XDA members from this and other forums. The goal was to find the UART location on the AT&T Galaxy S3.
Why, you might ask, would this be useful? During kernel and bootloader development, sometimes the device won't boot to the point where you can obtain logs to determine the problem. UART can provide the realtime eyes-on that you need to troubleshoot such problems.
So the process was as follows... On a rooted device, pull the kernel. Extract it. Add command line parameters to enable UART.
Code:
console=ttyHSL0,115200n8 loglevel=9
Code:
su
while [ 0 ]; do date| tee /dev/ttyHSL0; busybox sleep .5; doneThe TX from the board (your RX lead] is placed 2nd from the bottom on the battery side of the board. RX is either the one above that or middle on the other side.
Video:
In the video, at about 5 minutes in, I said I didn't know what the 31 value was... and the kmesg logs were pretty thin.. Well, turns out they are the kernel message levels. For full logging, change that to 987654321. Samsung usually uses the 9 identifier to represent shell access
.So, I hope this helps. UART provides eyes before any other method of debugging (aside from JTAG) begins to work. UART is the first thing to do in order to make a device into a development board.
