How to debug Android core without UART, JTAG and others
Quite often, the developers of kernels for Android devices are faced with the fact that the kernel assembled from source code simply simply does not work. And at the same time, often the developer who assembled the kernel does not have any special tools for debugging. In this situation, it is quite difficult to do anything without kmsg logs. Of course, in the Linux kernel, there are already several ways to copy the contents of the kmsg buffer into a special area of ​​memory, but if you are interested in learning about one more method, then I ask for a cat.
Recently, I already described one of the capabilities of the LLCON module , which consisted in displaying kmsg logs on an Android device display. Now it is time to describe a similar mechanism for copying kmsg logs, since Displaying logs on the screen is not very convenient for finding all sorts of errors.
To begin with, it is worth noting that in most cases, the Android device’s RAM is not cleared when the SoC is restarted. This feature uses a mechanism that ensures the appearance of the / proc / last_kmsg file. But sometimes for a forced SoC restart, you have to hold the Power button for a long time, which entails either a complete or partial change in the contents of the RAM. In this case, I recommend to connect the device to the PC via a USB cable, so that the contents of the RAM does not change (at least on my device it works).
Therefore, at the very first start, the test core should reserve a certain area of ​​RAM for duplicating the contents of the kmsg buffer into it. I usually allocate 1 MiB of memory for this case, and I use 0x7f200000 as the physical address, since 2 GiB SDRAM is installed on my device.
')
Those. On my Android device, to add this functionality, I add an additional parameter to the kernel command line:
The test core, in which there is an LLCON module, should start this parameter at startup and reserve the specified area of ​​RAM. This will enable a mechanism that will duplicate the kmsg logs in this specially prepared memory area. Moreover, this duplication will be performed inside the call to the printk function (that is, instantly and transparently). This circumstance allows you to get kmsg logs even with an emergency restart of the SoC device under test.
After restarting the SoC, you need to somehow read the contents of this memory area. For this, the bootloader must load something stable working, which may well be TWRP , based on the sink core. But this TWRP should be able to back up the same area in RAM so that its contents remain intact. Those. You must first make and flash a special version of TWRP.
In order for the core used in TWRP to reserve a section 0x7f200000 ... 0x7f2FFFFF in RAM, you need to edit the DeviceTree of this core. The editing process of DeviceTree itself requires writing a separate article, so I’ll just give the change in the dts file itself:
But the TWRP redesign is not complete. You need to add the viewmem utility to ramdisk, which allows you to flush the contents of physical memory to disk. Sources of this utility can be downloaded here: viewmem .
After preparing a special version of the TWRP, you need to pour it into the device. And for testing custom kernels, I advise you to upload this TWRP to the “boot” section, since it is on its contents that the bootloader transfers control by default. I will not begin to describe methods of filling in images of sections here, so that they would not get out of the subject of this publication at all.
First of all, it’s worth trying out the work of the special version of TWRP installed in the device. You can even test the viewmem utility (see the usage example below). I also note that in order to restart this TWRP, select the “System” item in the “Restart” menu section, since TWRP is in the "boot" section.
Now we have a special TWRP and test core with the LLCON module, which either hangs or causes the SoC to rebuild. And this is quite enough to find the reasons for this behavior of the test core. I recommend to upload the image of the tested kernel to the “recovery” section. Therefore, to start testing the problem kernel, select the “Recovery” item in the “Restart” menu. This will mean that when the device is rebooted, the bootloader will transfer control to the contents of the “recovery” section. Next, you should wait for an error to occur in the tested core. If the error itself causes the SoC restart, then nothing needs to be done, since the previously prepared TWRP should automatically load. If the error causes a hang, then hold down the Power button and wait for a hard restart (most importantly, do not forget about the USB cable).
After booting into TWRP, first of all you need to copy kmsg logs from memory to disk using ADB connection:
Now you need to copy the kmsg_llcon.txt file from the SD card and start exploring its contents.
I have already used this debugging method three times:
So when developing Android cores, you can completely do without UART, JTAG , EmbeddedICE DCC and other tools used for debugging.
Note: look for the source code of the LLCON module in my last publication " Replace the boot-animation of Android devices with the flashing Linux kernel logs ".
Recently, I already described one of the capabilities of the LLCON module , which consisted in displaying kmsg logs on an Android device display. Now it is time to describe a similar mechanism for copying kmsg logs, since Displaying logs on the screen is not very convenient for finding all sorts of errors.
To begin with, it is worth noting that in most cases, the Android device’s RAM is not cleared when the SoC is restarted. This feature uses a mechanism that ensures the appearance of the / proc / last_kmsg file. But sometimes for a forced SoC restart, you have to hold the Power button for a long time, which entails either a complete or partial change in the contents of the RAM. In this case, I recommend to connect the device to the PC via a USB cable, so that the contents of the RAM does not change (at least on my device it works).
Therefore, at the very first start, the test core should reserve a certain area of ​​RAM for duplicating the contents of the kmsg buffer into it. I usually allocate 1 MiB of memory for this case, and I use 0x7f200000 as the physical address, since 2 GiB SDRAM is installed on my device.
')
Those. On my Android device, to add this functionality, I add an additional parameter to the kernel command line:
llcondmp=0x7f200000,0x100000 Example of adding the llcondmp parameter to BoardConfig
BOARD_KERNEL_CMDLINE := androidboot.hardware=qcom BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive BOARD_KERNEL_CMDLINE += msm_rtb.filter=0x37 BOARD_KERNEL_CMDLINE += user_debug=31 debug ignore_loglevel BOARD_KERNEL_CMDLINE += llcondmp=0x7f200000,0x100000 The test core, in which there is an LLCON module, should start this parameter at startup and reserve the specified area of ​​RAM. This will enable a mechanism that will duplicate the kmsg logs in this specially prepared memory area. Moreover, this duplication will be performed inside the call to the printk function (that is, instantly and transparently). This circumstance allows you to get kmsg logs even with an emergency restart of the SoC device under test.
After restarting the SoC, you need to somehow read the contents of this memory area. For this, the bootloader must load something stable working, which may well be TWRP , based on the sink core. But this TWRP should be able to back up the same area in RAM so that its contents remain intact. Those. You must first make and flash a special version of TWRP.
In order for the core used in TWRP to reserve a section 0x7f200000 ... 0x7f2FFFFF in RAM, you need to edit the DeviceTree of this core. The editing process of DeviceTree itself requires writing a separate article, so I’ll just give the change in the dts file itself:
/dts-v1/; /memreserve/ 0x7f200000 0x100000; /* */ /include/ "msm8226-v2.dtsi" /include/ "msm8226-qrd.dtsi" But the TWRP redesign is not complete. You need to add the viewmem utility to ramdisk, which allows you to flush the contents of physical memory to disk. Sources of this utility can be downloaded here: viewmem .
Where can I get a ready binar viewmem
If you don’t want to bother with assembling TWRP from source, then I advise you to add the source viewmem to the same project that is used to build the test core. And the ready-made binary file viewmem can be simply embedded into the desired TWRP image.
After preparing a special version of the TWRP, you need to pour it into the device. And for testing custom kernels, I advise you to upload this TWRP to the “boot” section, since it is on its contents that the bootloader transfers control by default. I will not begin to describe methods of filling in images of sections here, so that they would not get out of the subject of this publication at all.
First of all, it’s worth trying out the work of the special version of TWRP installed in the device. You can even test the viewmem utility (see the usage example below). I also note that in order to restart this TWRP, select the “System” item in the “Restart” menu section, since TWRP is in the "boot" section.
Now we have a special TWRP and test core with the LLCON module, which either hangs or causes the SoC to rebuild. And this is quite enough to find the reasons for this behavior of the test core. I recommend to upload the image of the tested kernel to the “recovery” section. Therefore, to start testing the problem kernel, select the “Recovery” item in the “Restart” menu. This will mean that when the device is rebooted, the bootloader will transfer control to the contents of the “recovery” section. Next, you should wait for an error to occur in the tested core. If the error itself causes the SoC restart, then nothing needs to be done, since the previously prepared TWRP should automatically load. If the error causes a hang, then hold down the Power button and wait for a hard restart (most importantly, do not forget about the USB cable).
After booting into TWRP, first of all you need to copy kmsg logs from memory to disk using ADB connection:
adb shell viewmem 0x7f200000 0x100000 > /sdcard/kmsg_llcon.txt exit Now you need to copy the kmsg_llcon.txt file from the SD card and start exploring its contents.
I have already used this debugging method three times:
- creation of a custom kernel version 3.4 for the Innos D10F device (2014);
- creation of a custom kernel version 3.4 for the Innos D9 device (2015);
- Creating a custom kernel version 3.10 for the Innos D10F device (current project).
So when developing Android cores, you can completely do without UART, JTAG , EmbeddedICE DCC and other tools used for debugging.
Note: look for the source code of the LLCON module in my last publication " Replace the boot-animation of Android devices with the flashing Linux kernel logs ".
Source: https://habr.com/ru/post/311264/
All Articles