This blog post is used asAndroid boot optimization
The sequel of, the previous blog post was rough at the bottom of the investigation. This article is supplemented and provides a method of analyzing the time -consuming time.
Optimize bootloader
- Reduce unnecessary logs. The slow booting problem recently found that the UART LOG is not closed. Generally speaking, it can optimize the time of about 1S. The UART closure changes to the Kernel Config file as follows:
CONFIG_SERIAL_MSM_HSL=n
CONFIG_SERIAL_MSM_HSL_CONSOLE=nIn the, it is also mentioned that some useless Kernel Config can be removed. In order to facilitate Check, a Python script can be written to facilitate the use of useless configs in the project.
#!/usr/bin/env python
'''
@author: azhengye
'''
import difflib
import sys
_DEFAULT_CAN_REMOVE_CONFIG = [
'CONFIG_SCHED_DEBUG\n',
'CONFIG_DEBUG_KMEMLEAK\n',
'CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE\n',
'CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF\n',
'CONFIG_DEBUG_SPINLOCK\n',
'CONFIG_DEBUG_MUTEXES\n',
'CONFIG_DEBUG_ATOMIC_SLEEP\n',
'CONFIG_DEBUG_STACK_USAGE\n',
'CONFIG_DEBUG_LIST\n',
'CONFIG_FAULT_INJECTION_DEBUG_FS\n',
'CONFIG_LOCKUP_DETECTOR\n'
'CONFIG_DEBUG_PAGEALLOC\n',
'CONFIG_PAGE_POISONING\n',
'CONFIG_RMNET_DATA_DEBUG_PKT\n',
'CONFIG_MMC_PERF_PROFILING\n',
'CONFIG_DEBUG_BUS_VOTER\n',
'CONFIG_SLUB_DEBUG\n',
'CONFIG_DEBUG_BUGVERBOSE\n',
'CONFIG_ALLOC_BUFFERS_IN_4K_CHUNK\n',
'CONFIG_SERIAL_CORE\n',
'CONFIG_SERIAL_CORE_CONSOLE\n',
'CONFIG_SERIAL_MSM_HSL\n',
'CONFIG_SERIAL_MSM_HSL_CONSOLE\n',
'CONFIG_MSM_TZ_LOG\n',
'CONFIG_DYNAMIC_DEBUG\n',
'CONFIG_ANDROID_LOGGER\n',
'CONFIG_IMX134\n',
'CONFIG_IMX132\n',
'CONFIG_OV9724\n',
'CONFIG_OV5648\n',
'CONFIG_USB_MON\n',
'CONFIG_USB_STORAGE_DATAFAB\n',
'CONFIG_USB_STORAGE_FREECOM\n',
'CONFIG_USB_STORAGE_ISD200\n',
'CONFIG_USB_STORAGE_USBAT\n',
'CONFIG_USB_STORAGE_SDDR09\n',
'CONFIG_USB_STORAGE_SDDR55\n',
'CONFIG_USB_STORAGE_JUMPSHOT\n',
'CONFIG_USB_STORAGE_ALAUDA\n',
'CONFIG_USB_STORAGE_KARMA\n',
'CONFIG_USB_STORAGE_CYPRESS_ATACB\n',
'CONFIG_SEEMP_CORE\n',
'CONFIG_MSM_SMEM_LOGGING\n',
'CONFIG_IOMMU_DEBUG\n',
'CONFIG_IOMMU_DEBUG_TRACKING\n',
'CONFIG_IOMMU_TESTS\n',
'CONFIG_MOBICORE_DRIVER\n',
'CONFIG_MSDOS_FS\n',
]
def main(argv):
if len(argv) != 2:
print '%s: invalid arguments' % argv[0]
return 2
filename1 = argv[1]
try:
with open(filename1, "r") as f1:
str1 = f1.readlines();
list1 =[]
for string in str1:
if string.startswith('#') or len(string) <= 6:
continue
list1.append(string.split('=')[0]+'\n')
diffs = difflib.unified_diff(
_DEFAULT_CAN_REMOVE_CONFIG, list1)
except Exception as e:
print "something wrong: %s" % e
return 1
status_code = 0
for diff in diffs:
if diff.startswith('+') or diff.startswith('-') or diff.startswith('@'):
continue
sys.stdout.write('follow config can be remove====>')
sys.stdout.write(diff)
status_code = 1
return status_code
if __name__ == '__main__':
sys.exit(main(sys.argv))Special explanation in the lower script _default_can_remove_config is just a universal removable Config list. Before removing, you must link to a specific project.
script usage:
A: First compile the User version of Kernel first, and then go to the out directory to find the generated .config file.
b: Keep the above script as Check-config.py. Run CHECK-config.py .config
Output is as follows as follows:
follow config can be remove====> CONFIG_MMC_PERF_PROFILING
follow config can be remove====> CONFIG_MSM_TZ_LOG- The kernel compilation will generate the ZIMAGE kernel mirror file. Then Bootloader loads Zimage. After that, you need to decompress the zimage. The default compression algorithm is GZIP. The use of the LZ4 compression algorithm can shorten the time. You can refer to the patch [https://patchwork.kernel.org/patch/6810841/]Come to modify. This savings have limited time, less than 1S, after weighing the advantages and disadvantages, there is no time in the actual project. If you are pursuing perfection, you can try it. Risk-taking -_-
BOOT signature verification optimization
This pit that appeared on the new project recently has customized a set of its own signature rules because the project is a Qualcomm platform. When a custom signature problem is wrong, it will re -take Qualcomm’s signature. Stretching the start time. I doubted this before, but I couldn’t find evidence. In the end, I found a clue when I checked a bunch of nodes below/proc.
[730] boot_verifier: Signature decrypt failed! Signature invalid = -1
[790] Your device has loaded a different operating system.
Wait for 5 seconds before proceedingGet this evidence, find a colleague responsible for signing to change this piece, and optimize a lot of time.
At the same time, I also found a good thing/proc/bootprof. I haven’t paid attention to this node before. CAT saw very useful information and listed it to feel it.
----------------------------------------
0 BOOT PROF (unit:msec)
----------------------------------------
953 : preloader
779 : first logo
2671 : lk
----------------------------------------
20.233999 : ON
135.360846 : 1-swapper/0 : initcall: arm64_device_init 49.639539ms
218.746846 : 1-swapper/0 : initcall: event_trace_init 33.785154ms
236.874461 : 1-swapper/0 : probe: probe=platform_drv_probe drv=mt-pmic(ffffffc001076840) 15.639385ms
236.918615 : 1-swapper/0 : initcall: pmic_mt_init 16.109692ms
311.124539 : 1-swapper/0 : initcall: populate_rootfs 71.181924ms
381.334693 : 1-swapper/0 : probe: probe=platform_drv_probe drv=musb-hdrc(ffffffc0010829f0) 17.795231ms
381.360769 : 1-swapper/0 : probe: probe=platform_drv_probe drv=musb-mtu3d(ffffffc001082c30) 17.965769ms
381.861308 : 1-swapper/0 : initcall: mtu3d_driver_init 18.712692ms
1717.001003 : 1-swapper/0 : probe: probe=i2c_device_probe drv=bq25890(ffffffc00110cc58) 1248.854233ms
1717.779465 : 1-swapper/0 : initcall: bq25890_init 1249.733311ms
1828.548927 : 1-swapper/0 : probe: probe=platform_drv_probe drv=mtkfb(ffffffc001096780) 29.705308ms
1829.394927 : 1-swapper/0 : initcall: mtkfb_init 30.689154ms
// omitted contentand/Proc/Bootmsg node is also very useful.
Here just make up for itAndroid boot optimization
The shortcomings of PERFTOOL incan see more at the bottom.
SYSTRACE Debug boot problem
SYSTRACE’s root is the FTRACE of Linux. It can not only analyze the performance problems of the upper layer, but also use the underlying problem, but it is necessary to modify the underlying code. details as follows:
- Modify Frameworks/Native/CMDS/Atrace/Atrace.rc
Open the default turn switch.
- write /sys/kernel/debug/tracing/tracing_on 0
+ #write /sys/kernel/debug/tracing/tracing_on 0- Properly adds the following changes. The reason why it is appropriate, because the compile files of different platforms are different, this needs to be combined with the project code to find the location. The Qualcomm platform can be added to the device/qcom/common/commit.mk file:
PRODUCT_PROPERTY_OVERRIDES += debug.atrace.tags.enableflags=802922- Equally appropriate make files add the following modification, such as boardconfig.mk file
The
BOARD_KERNEL_CMDLINE += trace_buf_size=64M trace_event=sched_wakeup,sched_switch,sched_blocked_reason,sched_cpu_hotplug,block,ext4- project’s init.rc file is modified as follows, the purpose is to end the trace record.
on property:sys.boot_completed=1
start qrngp
+ write /d/tracing/tracing_on 0
+ write /d/tracing/events/ext4/enable 0
+ write /d/tracing/events/block/enable 0After the above modification, the compilation of the mirror file is compiled, and the execution is executed after the start of the power:
adb root && adb shell "cat /d/tracing/trace" > boot_traceand then execute
external/chromium-trace/catapult/tracing/bin/trace2html boot_trace The above command can convert the Trace Log to the SYSTRACE file and open it with the Chrome browser to facilitate analysis.
Summary
Power -on optimization problem involves many modules. Through these two blog posts, the analysis methods and some solutions from the bottom to the upper layer are roughly given. Welcome everyone to discuss and share.