I am studying the camera bring up process in Android with Qualcomm platform. I have searched many bring up tutorial but I just can't figure out one thing: most of the tutorial would focus on the .dtsi setting and the driver porting. But I just can't find out where is the camera sensor boot setting. I can see the i2c booting sequence when I log the kernel message, but where the setting be recorded in BSP? Thanks a lot!
Kernel log of camera sensor booting
If the kernel logs those lines, then the kernel sends the settings to the sensor. Which makes sense: initializing a device is supposed to be done by the device driver, and in Linux device drivers are supposed to be in the kernel.
Looking at your log, it seems like a file named msm_camera_cci_i2c.c does it.
After a basic online search, it looks like it comes from an Android kernel, and that msm_camera_cci_i2c.c is just a utility file whoes functions are used by your actual driver. Thus look into your driver, the initialization data should live there.
To know which driver is being used you can look either in your devicetree or navigate through the /sys directory, e.g. in /sys/bus/i2c/devices/.
Related
I have fully unlocked the Samsung device and I have downloaded the Kernel sources from the Samsung open-source site. I have built the kernel fine with instructions are given in the README_Kernel.txt file included in the source code.
I get the build output at out/arch/arm64/boot/Image.
I have also downloaded the firmware of the device from samfrew: G977PVPU2ASH6
I have extracted the boot.img of the downloaded firmware and patched the Image using AIK-Linux-v3.6
When I have flashed(with Odin v3.14) it then it's failed and stuck on Splash Screen(with information about phone status showing on it which I generally see in the download mode.) as following:
This is the first time, I have built a kernel fine and get output. I have fixed the device by flashing the original boot.img from the downloaded firmware.
I want to understand why the kernel built from the source code failed to flash. I know a few reasons like:
The possibility of Samsung doesn't share the full code because of proprietary reasons.
Wrong toolchain.
How exactly, someone can determine the problem?
Any help/suggestion?
Try G977PVPS3BTA1. The other ones are not labeled QQ, and you have Qualcomm chipset, as seen from the model number and the Qualcomm SecureBoot text at the boot screen. The triangle means custom firmware has been loaded and it might need to be restored with Kies.
Shame on me if I am wrong.
[EDIT: Edited "Snapdragon" to "Qualcomm chipset"]
I am adding another answer because this one is completely different than the other one.
I just found out that Qualcomm locks the bootloader ENTIRELY.
So not only OEM unlocking needed, you need to sign your bootloader in a way that Qualcomm Secure Boot does not get in your way.
You still have to use code I posted on my other reply, but, with the addition of signing.
There is an link on explaining how it works:
https://www.timesys.com/security/secure-boot-snapdragon-410/
[Ignore the old Snapdragon, it is the same Qualcomm Secure Boot thing]
Shame on me if I am wrong.
[EDIT: Official documentation!
https://www.qualcomm.com/media/documents/files/secure-boot-and-image-authentication-technical-overview-v2-0.pdf]
In our project we get ramdumps from other teams which is generated in case of a system crash and need further investigation. I am working on an utility which keeps some board specific data in the ram , which can be later utilized for debugging purpose. In order to better understand the environment/process in which my utility will be used I am trying to figure this information out.
Till now I understand there will be watchdog running (software/hardware), which will get triggered when fed in a particular timeout duration. Once it is triggered it will perform the system reset through some System registers.
Now I am little fuzzy on when the ramdumps are generated , is it before/after reset, or it needs some other tool connected to the board through which ramdumps are captured.
I understand once the ramdumps are available we can run parsers to extract the useful information or can use it in debugger like gdb to further analyse the state leading to the crash.
There are plenty of tools to analyse the ramdump, in other words physical memory dump.
Just imagine after reset what is the condition of RAM. In general, you don't dump the memory after reset you do it before reset in-order to do the memory analysis.
In detail about the RAM-dump in Linux system
Is divided into three sections based on how ramdump is generated, transferred and stored.
The Support in the kernel to enter into ramdump mode when kernel crashes or freezes.
Support in boot-loader to detect ramdump, wait for a host tool to initiate ramdump and send the data to host.
A host tool which can receive data from device and save it on host PC file system.
Later you need to have bootloader support as well, it makes the decision whether to enter into ramdump mode not boot Linux normally.
Ramdump generation during the crash
The kernel panic notifier registered from the ramdump driver will be called by kernel. Ramdump driver do,
Invoke cache sycn api to make sure all the content the ram is coherent.(flush_cache_all(), outer_flush_all())
save core registers to ram
save MMU registers
write MAGIC_CRASH to SRAM regiter.
Then do a reboot. Now boot-loader finds the MAGIC_CRASH in SRAM register and goes to ramdump mode.
Very detailed information about Ramdump Linux inspection.
You can try something like this in fly
$ cat /proc/[your_pid]/maps and the use gdb to inspect
$ gdb --pid [your_pid]
Some tools that can help you.
Go through these lists you will find the information about (FATKit) Foresnic Analysis toolkit.Foriana, etc.
Linux memory analysis tools
How to dump Linux memory?
I have a widget that will tell the user the capacity of a connected USB device, as well as the amount of space used. I have gone through the android.hardware.usb API and I see nothing that can accomplish determining the size of a connected USB device and its usage.
Right now I am capturing Intent.ACTION_MEDIA_MOUNTED and searching in the Dir of the mount point for specific files etc... All of that is working fine, but for the life of me I cannot see how to leverage the API to determine the overall size, and usage, of a connected USB device.
Do any of you fine folks know, or have an article for me to read? Thanks all.
It sounds like your device is actually mounting the connected USB device's file system, which seems like it may be a vendor add-on rather than a stock android capability.
If that is indeed the case, whatever other options you might have you can use the df shell command, or more properly duplicate its functionality in java or a native subroutine.
You can view the source of android's df here:
https://github.com/android/platform_system_core/blob/master/toolbox/df.c
It looks to be a fairly standard implementation - read /proc/mounts to find the filesystems, call statfs() on each one. You'd probably want to filter by those of interest.
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'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.