I'm trying to do kernel debugging for my Nexus One, and have been following instructions from http://bootloader.wikidot.com/android:kgdb. I was wondering if someone has actually got this to work? And has anyone done a more up to date solution for using KGDB to debug the kernel?
I found this post when I was looking for information of KGDB on Android so, despite it being a few years old, I thought it worth posting a link to some work I did to get this up and running on the Nexus 6.
http://www.contextis.com/resources/blog/kgdb-android-debugging-kernel-boss/
I hope this helps anyone else looking for similar answers.
Edited following feedback (thanks all):
To get this working I had to make a UART debug cable based on this Accuvant blog. This is quite a simple circuit which consists of a FTDI 3.3v basic breakout (available from SparkFun at the time of writing), as well as 4 resistors (2 x 1K Ohm, 1 x 1.2K Ohm and 1 x 100Ohm), and a 4-element Tip-Ring-Ring-Sleeve (TRRS) headphone jack. The resistors are essentially providing a voltage divider to reduce the 3.3v down to something a little safer for your phone. By inserting the audio jack with the other end connected to your circuit board, the audio subsystem recognises that a voltage (~2.8V) on the one of the pins and it knows to provide a UART interface via that cable. The FTDI breakout plugs into your PC via USB and from here you can access console messages via a terminal emulator like minicom. However, you now have a serial interface through the same mechanism and that's what we can use for a KGDB connection.
So at this point some relatively minor changes are required to the Nexus 6's serial driver (msm_serial_hs_lite.c) to support KGDB (specifically, the ability to perform atomic character I/O operations). I just ported these changes from the Linux Kernel mainline code as a chap called Stephen Boyd had done the hard work to the full MSM (Qualcomm) serial driver msm_serial.c. His changes can be found here or just search for "msm_serial: add support for poll_" on Google. The port wasn't difficult and my code can be found on github.
Aside from that you need to be able to build a custom kernel for your N6 which google provides lots of information on. You then need to create a boot image which contains the KGDB modifications in the github repo. I took the stock kernel from https://developers.google.com/android/nexus/images, extracted it (using abootimg -x) and then used the following command to repack it with my custom kernel (zImage-dtb) and additional command line params to ensure KGDB would be loaded and point to my serial port like so:
abootimg -u boot.img -k zImage-dtb -c 'cmdline=console=ttyHSL0,115200,n8 kgdboc=ttyHSL0,115200 kgdbretry=4'
With my boot.img created I could boot into it using the command fastboot boot boot.img, open an adb shell and then trigger a breakpoint in the Android kernel using the command:
echo -n g > /proc/sysrq-trigger
It is worth mentioning for completeness that you need superuser privileges to access /proc/sysrq-trigger so you need to have root.
With the phone halted, and your debug cable connected, launch a version of GDB for ARM on your host PC with your uncompressed kernel as an argument (e.g. arm-eabi-gdb ./vmlinux). Note: I'm running Ubuntu 14.04 and using arm-eabi-gdb from the 'prebuilts' directory in my AOSP source repository. Finally, enter the following commands:
set remoteflow off
set remotebaud 115200
target remote /dev/ttyUSB0
All being well this should immediately break into the kgdb breakpoint (that your write to /proc/sysrq-trigger produced) and you can start debugging.
I know that you've already asked a question at the Android Kernel Dev list and got no answers, but did you search through the archives for posts about kgdb and debugging?: http://groups.google.com/group/android-kernel/search?group=android-kernel&q=kgdb&qt_g=Search+this+group
In particular, you might want to look at this post: http://groups.google.com/group/android-kernel/browse_thread/thread/5233e03391867c98/320beef11e737a62
Here's a few other random links that might be helpful:
http://www.cs.gmu.edu/~astavrou/courses/ISA_673/Android_Debugging/Android_GDB.pdf
http://www.cs.columbia.edu/~nieh/teaching/w4118/ubb/Forum6/HTML/000122.html
http://wiki.ncl.cs.columbia.edu/wiki/AndroidVirt:Guides:Kernel_Debugging
http://source.android.com/porting/debugging_gdb.html
Anyhow, this is an interesting question, and I'm really having a hard time finding anything on it. You might want want to try hopping on IRC sometime (#android-dev or #android-root on freenode) and asking some people there for pointers (please post up what you find here), or maybe asking on the xda-developers Android forums.
Related
I am doing some investigation of a closed-source app using ADB. I would like to log the commands this app is making, the ADB binaries it uses are in the same directory. Would I be able to sniff the commands by faking an ADB device or maybe modding the source code of the build tools to include a log?
Best regards.
I tried using some apps on a physical android device to log the incoming packets, though I got nowhere. I expect to be able to know what this closed source app is doing on my device.
PS: I am sorry if this sounds dumb, I know ADB is open source, part of the Android Open Source Project, but I made this post to make sure I am not missing some small detail. I am not an expert in the ADB protocol so excuse my clumsiness.
Answer:
Copied from this answer to How to fetch ADB shell traffic?
It is as simple as listening on the ADB server's port through Wireshark (TCP port 5037) since all the commands pass through the adb server/daemon before going to USB.
It is also possible to sniff the USB traffic using USBPcap, as it also is unencrypted.
I have A Samsung Galaxy Win Duos mobile and I'm using AT Command terminal on it. I tried several AT-Commands some got me the answer and some didn't.
As an example of commands that worked:ATand AT+CSQ
but a lot of commands didn't work like:AT!GSMINFO?
I want to know the commands that's suit my modem.
I tried AT+CLAC but it didn't work at all.(That's mean the program stopped)
I enteredATI to know the kind of modem and it got me:
Manufacturer: QUALCOMM INCORPORATED
Model: 4086
Revision: 8x25Q-QSOSKOLYM-3030 1 [Jan 29 2013 07:00:00]
IMEI: XXXXXXXXXXXXXXXXX
+GCAP: +CGSM,+FCLASS,+DS
Could you get me these command or help me to find a way for knowing them
You can find the standardized AT commands in the 3GPP spec here. Most modem manufacturers will add their own AT commands in addition to the 3GPP specification. Some manufacturers will give just about anybody a copy of their AT commands, some will not give it away without an NDA. You might also try joining the "developer program" at your manufacturer's website, assuming they have a developer program.
I've bought a tablet recently. It's a SysTrade's Plug 10.1 (Chinese product of local company). It features a reasonable CPU and quite nice GPU, so I thought it would be great to hardware debug my applications. However, this feature seems not to work on my device...
At beginning I lacked the required vendor id so after a few phone calls to SysTrade I received one. But that code didn't work. So I've written a small app and got all 2-byte numbers which I copy-pasted to /etc/udev/rules.d/51-android.rules. The problem is that adb still can't see my device. What's important my HTC Wildfire is successfully recognized so rules are written well.
I know none who owns this tablet so I don't have a possibility to check whether all Plugs or only mine are affected. Any ideas would be highly appreciated...
PS. I'm developing on Linux (Ubuntu 12.10).
PS2. When I connect the device to PC it shows that hardware debugging is turned on, but adb doesn't see my device.
I've managed to successfully resolve the issue without rooting the device. The only needed action is to manually add an entry for the device vendorid in ~/.android/adb_usb.ini.
Normally it should be generated based on /etc/udev/rules.d/51-android.rules by android update adb command but it seems that this application failed. What's important, vendorid must be given in hex number specific format, which is: 0x(2-BYTE HEX) for example 0x2207.
Try running adb on root.
If that doesn't work you can still try to root your device(This may void warranty) and use app like adbWifi. I'm using the latter for debugging and it works: I can run my apps on my M-tech aTAB7t.
I'm adapting a Gingerbread kernel for my custom board. I'm trying to replace a resistive touch screen that uses an on-chip ADC controller (S5PV210 processor from Samsung). In my design, I need a capacitive controller supported by eGalaxyTouch driver. It's connected to the USB. The driver can be easily enabled from the "make xconfig" menu. It somewhat works since I added some traces on the serial console and I can see it installing during the kernel boot and I see it install and uninstall itself when connecting/disconnecting the USB cable. But it doesn't do anything in the Android user interface. It is an HID type device. The problem is it does not hook-up to the proper Android touchscreen software layer. I must have miss something. There must be something else to call to force this HID to be connected to another software layer managing the touchscreen.
The touchscreen drivers are located at kernel/drivers/input/touchscreen. There is also some code straight in kernel/drivers/input.
Any clues on how to link that HID device to the Android Touchscreen layer? I look how they did the old resistive one and it is not done through an HID because it's a "custom made" device with ADCs integrated in the CPU and it's not going through USB.
I succeeded to integrate the touchscreen driver. Here is a rough idea of the steps just to give an idea of how it works for the others who would face the same kind of problem.
First remove the original touchscreen driver to prevent conflict (make xconfig)
Originally, I had a driver that doesn't work eventhough it was provided by the touchscreen manufacturer. I decided to try the eGalax touchscreen driver already in the Kernel tree. This is a module driver.
It is not enough to enable "module device drivers" in the make xconfig. Yes, it will allow to compile the .ko files. but it will not tell the building script what to do with the file.ko and they will not end up going with the kernel in the target system. So you have to take action by adding stuff to the build script or manually copy the file.ko in the proper root/modules location and add the loading of the module with the "insmod /modules/file.ko" command in the init.rc file. Don't forget to set the proper privileged to /modules and modules/file.ko with chmod command.
After that it basically worked, except for some minor problems not related to that question (the driver was for a slightly different chip with bits placed differently, easy to fix).
I was using earlier adb to debug Android applications over wifi, usb - it was great.
Right now I am wondering if it is possible to connect phone with adb via bluetooth.
I did a quick research but didn't find anything - have you tried it already ?
It is not supported by the current adb software, however you could probably make it possible if you have a rooted device (or possibly even if not - see below) either by modifying adb or by using bluetooth to tunnel a channel it does support, such as tcp.
You would need to obtain the source for the adb program - the same source is used to build both the PC and the device versions. First step is to just build it with unmodified functionality, which may take a fair amount of build system modification unless you do so as a part of a complete android source build (the way it was intended to be done)
Then you would modify it to add a bluetooth channel as an option and install it on the device (why you need root) and in your path on the PC. You'd think you could run it from an alternate location on the PC, and you likely can as long as you use it from the command line, but if your fire up DDMS it may kill off the running adb server and launch a new one using the default in the path, so ultimately you'll have to put your modified version there.
IF you can already get your device to accept adb connections over tcp (possible with root, perhaps possible in some cases without) there is another option, which is to not modify ADB (or at least not modify the device side) and instead come up with something running on the device which accepts bluetooth connections and forwards the traffic via local loopback to the tcp port on which the stock adb is operating. This would save the trouble of having to rebuild adb.
If you have some kind of tethering or similar network-over-bluetooth solution, you might even be able to leverage that to carry adb-over-tcp-over-bluetooth without writing any code.
Finally note that it is not 100% essential that the adb daemon run as a more privileged userid or be installed in place of the official one - you can run an adb daemon as an ordinary application and do many of the expected things with it. However, whichever adb daemon is running first will grab the unix domain java debug socket, and so only that adb daemon will be able to provide the full java debug services. More primitive things like logcat, shell, running process list, push/pull, etc will at least partially work without this, provided that your adb daemon doesn't quit (modification may be required) when it is unable to claim the debug socket. If you can kill the official adb daemon and exploit a race condition, you may be able to get an unofficial one started before it restarts - you would probably need to have a script or program to do this and run it with setsid from the official adb shell, meaning you'd need to connect via USB first. At that point, you'd also be able to start your unofficial adb daemon running as the same userid as the official one.
You may want to spend some time estimating or testing if the performance (speed) will be satisfactory before investing in a lot of time setting this up for real.
I know this is a bit old but I seem to have found a post that does this. All credit goes to the author of fomori.org for finding this and making the information available. Today it helped me, maybe tomorrow I'll help you by making it easier to find.
Source