Preface: For fingerprint debugging, we only need to pay attention to the kernel, hal, and ta to light it. Qualcomm uses its own tee environment, while MTK needs to use a third-party tee OS. The integrated debugging of the three-party tee usually has the cooperation of manufacturers, mainly debugging. spi ta, I won't elaborate here, the following focuses on the fingerprint bring up.
1. Drive debugging
Driver debugging is divided into two aspects, power-on, reset, irq, pinctrl and porting driver code to debug the driver node in dts.
1.dts configuration
Generally, Qualcomm and MTK platform codes will have a fingerprint integrated by default. You only need to copy and change gpio. If pinctrl is useful, change the pinctrl name to be the same as the name in the driver.
kernel/msm-4.9/arch/arm64/boot/dts/qcom/ (corresponding to the dts of your own project)
fpc1020 {
compatible = "fpc,fpc1020";
interrupt-parent = <&tlmm>;
interrupts = <48 0>;
fpc,gpio_rst = <&tlmm 124 0x0>;
fpc,gpio_irq = <&tlmm 48 0>;
vcc_spi-supply = <&pm8953_l5>;
vdd_io-supply = <&pm8953_l5>;
vdd_ana-supply = <&pm8953_l5>;
pinctrl-names = "fpc1020_reset_reset",
"fpc1020_reset_active",
"fpc1020_irq_active";
pinctrl-0 = <&fpc_reset_low>;
pinctrl-1 = <&fpc_reset_high>;
pinctrl-2 = <&fpc_int_low>;
};
The above dts section needs to be modified when we migrate to a new project:
(1) Compatible: The probe function will be used only after the device_id in the driver code matches the compatible here.
static const struct of_device_id fpc1020_of_match[] = {
{ .compatible = "fpc,fpc1020", },
{}
};(2) GPIO: Change reset, irq, interrupt number, etc. to your own project.
(3) Power on: Since the fingerprint can unlock the bright screen even when the screen is off and in sleep mode, the fingerprint should generally be set to long power supply. The example shown is LDO power supply. According to the schematic diagram, confirm which LDO you use, if This power supply is not a long-term power supply and can be modified at the rpm side.
(4) pinctrl: If the manufacturer-driven driver does not use pinctrl to operate gpio, no configuration is required. If the manufacturer-driven driver requires the use of pinctrl, find the pinctrl.dtsi of the corresponding project, as shown in the figure below.
fpc_reset_int {
fpc_reset_low: reset_low {
mux {
pins = "gpio124";
function = "fpc_reset_gpio_low";
};
config {
pins = "gpio124";
drive-strength = <2>;
bias-disable;
output-low;
};
};
fpc_reset_high: reset_high {
mux {
pins = "gpio124";
function = "fpc_reset_gpio_high";
};
config {
pins = "gpio124";
drive-strength = <2>;
bias-disable;
output-high;
};
};
fpc_int_low: int_low {
mux {
pins = "gpio48";
};
config {
pins = "gpio48";
drive-strength = <2>;
bias-pull-down;
input-enable;
};
};
};(A) To check whether gpio belongs to its own project, the subordinate label such as fpc_reset_low matches with pinctrl-0 = <&fpc_reset_low> in dtsi.
(b) In the check item dts, pinctrl-names = "fpc1020_reset_reset",
"fpc1020_reset_active",
"fpc1020_irq_active";
When parsing dts with the driver probe function, whether the name is uniform, if not uniform, it may crash, and you need to grasp the serial port for analysis.
rc = select_pin_ctl(fpc1020, "fpc1020_reset_reset");
rc = select_pin_ctl(fpc1020, "fpc1020_irq_active");2. Drive driver migration
(1) Create a new fingerprint/fpc folder under kernel/driver/input, put the driver code provided by the manufacturer in kernel/driver/input/fingerprint/fpc, and write Kconfig and Makefile files at the same time.
Kconfig:
menu "FingerprintCard fingerprint driver"
config FINGERPRINT_FPC
default n
tristate "FPC_BTP fingerprint sensor support"
depends on SPI_MASTER
endmenuMakefile:
obj-$(FINGERPRINT_FPC) += fpc1020.o(2) Kconfig and Makefile are called recursively from the top level in the kernel, so the newly added ones must be included in the Kconfig and Makefile of the upper-level directory. I won't repeat them here. Those who have done the driver will know.
(3) Find the deconfig and perf-deconfig corresponding to your project in the kernel/arch/arm64/configs/ directory, and add
CONFIG_FINGERPRINT_FPC=y
Note: Here FINGERPRINT_FPC should be consistent with Kconfig and Makefile in (1)
After the above is completed, single-program boot and dtbo, and verify by flashing separately to confirm whether it can be booted and whether the device node is generated. (The fingerprints of most manufacturers here cannot confirm whether the dts is correctly parsed through serial log printing, because the dts analysis of the fingerprints of these manufacturers is parsed by the manufacturer's ca issued commands, and you have to wait for the ca to be integrated.)
Two, hal layer transplantation
1.so library
Generally, manufacturers release the so library, and very few manufacturers release semi-open source code for you, which requires debugging and compiling by yourself. So generally has fingerprint.default.so and manufacturers such as Goodix's gf_hal, gf_ca, and mold related so.
Release with the so library: place so in the corresponding directory, and include so in the project's mk file for version compilation, for example:
PRODUCT_COPY_FILES+= vendor/fingerprint/goodix/fingerprint.default.so:vendor/lib64/hw/fingerprint.default.so
Non-so library release: just write Android.mk
So as long as it is compiled, it can be pushed separately.
2.hal service
(1) It is necessary to check whether the [email protected] related so and bin files are compiled in the out directory. Generally, they are not available by default. If not, you should include this part in the compilation, or you can compile push separately.
(2) You need to confirm whether the so library opened in the hardware/interfaces/biometrics/fingerprint/2.1/default/BiometricsFingerprint.cpp openhal function matches the name you debugged. FINGERPRINT_HARDWARE_MODULE_ID defaults to fingerpritn.default.so, if Inconsistent, define FINGERPRINT_HARDWARE_MODULE_ID as your own.
(3) Include [email protected] in the compilation and configure the service to start automatically after booting
(4) Hidl modification
Android P and later need to be modified in three places:
device/$product/manifest.xml
hardware/interfaces/compatibility_matrices/...
device/qcom/common/vendor_framework_compatibility_matrix.xml
<hal format="hidl" optional="true">
<name>android.hardware.biometrics.fingerprint</name>
<version>2.1</version>
<interface>
<name>IBiometricsFingerprint</name>
<instance>default</instance>
</interface>
</hal>Note: The syntax is different. When adding in device/$product/manifest.xml, you need to remove optional="true" in the above figure.
Three, TA transplantation
This transplantation process can be transplanted step by step according to the documentation given by the manufacturer, this will not be repeated here, and the finally compiled ta can also be pushed separately for verification in the debugging stage.
Four, other configurations
(1) Modify node permissions in init rc
chown system system dev/goodix_fp
chmod 0664 /dev/goodix_fp(2) Open the fingerprint option in the setting
PRODUCT_COPY_FILES := frameworks/native/data/etc/android.hardware.fingerprint.xml:vendor/etc/permissions/android.hardware.fingerprint.xml (3) Confirm the spi number, check whether the port configuration in the dts is correct on the kernel side, and modify the spi number to be used for fingerprints on the tz side.
Five, module compatibility
In order to reduce the risk of general mobile phone peripheral devices, modules will have more materials, usually different ICs. If it is the same IC but different modules, we don't need to do anything by ourselves. The IC manufacturer will burn it in the otp to recognize it. We will focus on the compatibility of different ICs below.
Method 1: Compatible hardware ID
Generally, the hardware will reserve ID pin, one ID pin can be compatible with two high and low, and two ID pins can be compatible with four.
1. Read the fp_id pin value in the lk stage
gpio_get_value（unsigned gpio）//这个是返回寄存器的值 ，需要换算成二进制，再结合数据手册看下gpio哪一位是表示高低电平的2. Use cmdline to transfer the value from lk to the kernel
3. The kernel reads the saved_command_line value, creates a node and writes the value
4. In hal, load the so of different manufacturers by reading the node value
Method 2: Polling and loading compatibility
1. The driver only creates device nodes and does not apply to configure GPIO and interrupts
2. Polling and loading fingerprint.default.so in the openhal function of BiometricsFingerprint.cpp
3. Configure GPIO in ca, the supplier will complete ID detection in so, and return when the fingerprint module is not detected
Six, selinux permissions
The above is to turn off the selinux permission debugging on the userdebug version. You need to debug the selinux permission to ensure that the fingerprint is still available when selinux is turned on.
Debugging method:
adb shell getenforce //View selinux permission status, enforcing is on, permissive is off
adb shell setenforce 0 //Close selinux permissions
adb shell setenforce 1 //Open selniux permission
adb shell stop //The above will be opened again after closing and restarting. You can execute stop start after closing the selinux permission, so that after the device is restarted, selinux will not be opened again, which is convenient for debugging
adb shell start
There are a lot of information on the Internet about how to configure selinux permissions, so I won't go into details here.
Seven, common problems
1. crash
Common reasons:
(1) There is a problem with the dts configuration: Generally, it is caused by the mismatch of the name introduced above. Grab the serial port log, and add the log line by line to the probr=e function to parse the dts code to confirm the error and modify it.
(2) tz memory: After transplanting ta, you need to expand the tz memory, otherwise it is very likely to cause a crash. The modification method of each platform is different. You can ask the platform for the document and compare the document modification.
For Android P Qualcomm platform, please refer to: https://blog.csdn.net/dshine_/article/details/85101887
(3) Pointer exception: Find the abnormal address, use add2line to parse out which file and line of code it is and then analyze.
2. The sensor ID cannot be read
Common reasons:
(1) Power on: Does the power supply meet the manufacturer's datasheet requirements under the voltmeter measurement?
(2) Spi fails: check whether the port number configuration on the tz side is correct, and whether the spi port number is used by the tz side. (If it is on the AP side, it needs to be modified)
3. Ta load can't get up
99% is that there is a problem with the tz memory. If you insist that you have modified it according to the platform documentation, then please check whether your modification has taken effect
4. There is no fingerprint option in setting
Check if the manifest.xml and android.hardware.fingerprint.xml are in the mobile phone, the fingerprint option will be displayed only if both are configured.
8. Summary
During the fingerprint debugging process, the driver, so, ta, rc can be individually flashed or pushed, but the memory and manifest.xml (some platforms can be pushed separately, in the vendor/etc/vintf directory, but some platforms are pushed It will crash, so it is not recommended to push separately) This requires full compilation to take effect, so you must first compile a version that has been configured and can boot normally before the three major pieces are lit up and start debugging.
In addition, other fingerprints may be messed up if they are pushed separately. If you forget which one to push, come back and grab the log to view, it will be very time-consuming and laborious, so it is recommended to compile the first version before debugging, so, ta, 2.1 related first , Rc, etc. are all preset first, and if there is any problem in the later stage, push and replace them separately.