การเพิ่มประสิทธิภาพเวลาบูต

หน้านี้ประกอบด้วยชุดเคล็ดลับที่คุณสามารถเลือกได้ เพื่อปรับปรุงเวลาบูต

ตัดสัญลักษณ์การดีบักออกจากโมดูล

เช่นเดียวกับการถอดสัญลักษณ์การดีบักออกจากเคอร์เนลบนอุปกรณ์ที่ใช้งานจริง ตรวจสอบให้แน่ใจว่าคุณได้ตัดสัญลักษณ์การดีบักออกจากโมดูลด้วย การแยกสัญลักษณ์ดีบักออกจากโมดูลจะช่วยลดเวลาในการบูตโดยลดสิ่งต่อไปนี้:

• เวลาที่ใช้ในการอ่านไบนารีจากแฟลช
• เวลาที่ใช้ในการคลายการบีบอัด ramdisk
• เวลาที่ใช้ในการโหลดโมดูล

การแยกสัญลักษณ์ดีบักออกจากโมดูลอาจประหยัด เวลาหลายวินาทีระหว่างการบู๊ต

การแยกสัญลักษณ์ถูกเปิดใช้งานโดยค่าเริ่มต้นในรุ่นแพลตฟอร์ม Android แต่หากต้องการเปิดใช้งานอย่างชัดเจน ให้ตั้งค่า BOARD_DO_NOT_STRIP_VENDOR_RAMDISK_MODULES ในการกำหนดค่าเฉพาะอุปกรณ์ของคุณภายใต้อุปกรณ์/ vendor / device

ใช้การบีบอัด LZ4 สำหรับเคอร์เนลและ ramdisk

Gzip สร้างเอาต์พุตที่ถูกบีบอัดน้อยกว่าเมื่อเทียบกับ LZ4 แต่ LZ4 จะขยายขนาดได้เร็วกว่า Gzip สำหรับเคอร์เนลและโมดูล การลดขนาดพื้นที่จัดเก็บข้อมูลสัมบูรณ์จากการใช้ Gzip นั้นไม่สำคัญมากนัก เมื่อเทียบกับข้อดีด้านเวลาในการคลายการบีบอัดของ LZ4

เพิ่มการรองรับการบีบอัด ramdisk LZ4 ให้กับแพลตฟอร์ม Android ที่สร้างผ่าน BOARD_RAMDISK_USE_LZ4 คุณสามารถตั้งค่าตัวเลือกนี้ได้ในการกำหนดค่าเฉพาะอุปกรณ์ของคุณ การบีบอัดเคอร์เนลสามารถตั้งค่าได้ผ่านเคอร์เนล defconfig

การเปลี่ยนไปใช้ LZ4 ควรให้ เวลาบูตเร็วขึ้น 500ms ถึง 1,000ms

หลีกเลี่ยงการเข้าสู่ระบบไดรเวอร์ของคุณมากเกินไป

ใน ARM64 และ ARM32 การเรียกใช้ฟังก์ชันที่มากกว่าระยะทางที่กำหนดจากไซต์การโทรจำเป็นต้องมีตารางข้าม (เรียกว่าตารางการเชื่อมโยงขั้นตอนหรือ PLT) เพื่อให้สามารถเข้ารหัสที่อยู่การกระโดดแบบเต็มได้ เนื่องจากโมดูลถูกโหลดแบบไดนามิก ตารางการข้ามเหล่านี้จึงต้องได้รับการแก้ไขในระหว่างการโหลดโมดูล การเรียกที่ต้องการการย้ายตำแหน่งเรียกว่ารายการการย้ายตำแหน่งที่มีรายการเพิ่มอย่างชัดเจน (หรือ RELA โดยย่อ) ในรูปแบบ ELF

เคอร์เนล Linux ทำการเพิ่มประสิทธิภาพขนาดหน่วยความจำบางอย่าง (เช่น การเพิ่มประสิทธิภาพการเข้าถึงแคช) เมื่อจัดสรร PLT ด้วย การส่งต้นน้ำ นี้ รูปแบบการปรับให้เหมาะสมมีความซับซ้อน O(N^2) โดยที่ N คือจำนวน RELA ประเภท R_AARCH64_JUMP26 หรือ R_AARCH64_CALL26 ดังนั้นการมี RELA ประเภทเหล่านี้น้อยลงจึงมีประโยชน์ในการลดเวลาในการโหลดโมดูล

รูปแบบการเข้ารหัสทั่วไปรูปแบบหนึ่งที่เพิ่มจำนวน R_AARCH64_CALL26 หรือ R_AARCH64_JUMP26 RELAs คือการเข้าสู่ระบบไดรเวอร์มากเกินไป การเรียกแต่ละครั้งไปยัง printk() หรือรูปแบบการบันทึกอื่นๆ โดยทั่วไปจะเพิ่มรายการ CALL26 / JUMP26 RELA ใน ข้อความคอมมิตในการคอมมิตอัปสตรีม โปรดสังเกตว่าแม้จะมีการปรับให้เหมาะสมแล้ว โมดูลทั้งหกก็ใช้เวลาประมาณ 250 มิลลิวินาทีในการโหลด นั่นเป็นเพราะว่าหกโมดูลนั้นเป็นโมดูลหกอันดับแรกที่มีจำนวนการบันทึกมากที่สุด

การลดการบันทึกสามารถบันทึกได้ประมาณ 100 - 300ms ในเวลาบูต ขึ้น อยู่กับว่าการบันทึกที่มีอยู่มากเกินไปเพียงใด

เปิดใช้งานการตรวจสอบแบบอะซิงโครนัสแบบเลือก

เมื่อมีการโหลดโมดูล หากอุปกรณ์ที่รองรับนั้นถูกเติมจาก DT (แผนผังอุปกรณ์) และเพิ่มลงในแกนไดรเวอร์แล้ว โพรบอุปกรณ์จะเสร็จสิ้นในบริบทของการเรียก module_init() เมื่อโพรบอุปกรณ์เสร็จสิ้นในบริบทของ module_init() โมดูลจะไม่สามารถโหลดจนเสร็จสิ้นได้จนกว่าโพรบจะเสร็จสิ้น เนื่องจากการโหลดโมดูลส่วนใหญ่จะเป็นแบบซีเรียลไลซ์ อุปกรณ์ที่ใช้เวลาค่อนข้างนานในการตรวจสอบจึงทำให้เวลาบูตช้าลง

เพื่อหลีกเลี่ยงไม่ให้เวลาบูตช้าลง ให้เปิดใช้งานการตรวจสอบแบบอะซิงโครนัสสำหรับโมดูลที่ใช้เวลาสักครู่ในการตรวจสอบอุปกรณ์ การเปิดใช้งานการตรวจสอบแบบอะซิงโครนัสสำหรับโมดูลทั้งหมดอาจไม่เป็นประโยชน์ เนื่องจากเวลาที่ใช้ในการแยกเธรดและเริ่มต้นโพรบอาจสูงเท่ากับเวลาที่ใช้ในการตรวจสอบอุปกรณ์

อุปกรณ์ที่เชื่อมต่อผ่านบัสที่ช้า เช่น I2C อุปกรณ์ที่โหลดเฟิร์มแวร์ในฟังก์ชันโพรบ และอุปกรณ์ที่เตรียมใช้งานฮาร์ดแวร์จำนวนมากอาจทำให้เกิดปัญหาเรื่องเวลาได้ วิธีที่ดีที่สุดในการระบุว่าเหตุการณ์นี้เกิดขึ้นเมื่อใดคือการรวบรวมเวลาโพรบสำหรับไดรเวอร์ทุกตัวแล้วจัดเรียง

หากต้องการเปิดใช้งานการตรวจสอบแบบอะซิงโครนัสสำหรับโมดูล การตั้งค่าสถานะ PROBE_PREFER_ASYNCHRONOUS ในรหัสไดรเวอร์นั้น ไม่ เพียงพอ สำหรับโมดูล คุณต้องเพิ่ม module_name .async_probe=1 ในบรรทัดคำสั่งเคอร์เนล หรือส่ง async_probe=1 เป็นพารามิเตอร์โมดูลเมื่อโหลดโมดูลโดยใช้ modprobe หรือ insmod

การเปิดใช้งานการตรวจสอบแบบอะซิงโครนัสสามารถประหยัด เวลาบูตได้ประมาณ 100 - 500 มิลลิวินาที ขึ้นอยู่กับฮาร์ดแวร์/ไดรเวอร์ของคุณ

ตรวจสอบไดรเวอร์ CPUfreq ของคุณโดยเร็วที่สุด

ยิ่งไดรเวอร์ CPUfreq ของคุณตรวจพบเร็วเท่าไร คุณก็จะขยายความถี่ของ CPU ให้เป็นค่าสูงสุด (หรือค่าสูงสุดที่จำกัดอุณหภูมิ) ในระหว่างการบูตได้เร็วยิ่งขึ้นเท่านั้น ยิ่ง CPU เร็วเท่าไร การบูตก็จะเร็วขึ้นเท่านั้น แนวทางนี้ยังใช้กับไดรเวอร์ devfreq ที่ควบคุม DRAM หน่วยความจำ และความถี่ในการเชื่อมต่อระหว่างกันด้วย

สำหรับโมดูลต่างๆ การเรียงลำดับโหลดอาจขึ้นอยู่กับระดับ initcall และลำดับการคอมไพล์หรือลิงก์ของไดรเวอร์ ใช้นามแฝง MODULE_SOFTDEP() เพื่อให้แน่ใจว่าไดรเวอร์ cpufreq เป็นหนึ่งในโมดูลแรกๆ ที่จะโหลด

นอกเหนือจากการโหลดโมดูลตั้งแต่เนิ่นๆ แล้ว คุณยังต้องตรวจสอบให้แน่ใจว่าการขึ้นต่อกันทั้งหมดในการโพรบไดรเวอร์ CPUfreq นั้นได้โพรบแล้วด้วย ตัวอย่างเช่น หากคุณต้องการนาฬิกาหรือที่จับตัวควบคุมเพื่อควบคุมความถี่ของ CPU ของคุณ ตรวจสอบให้แน่ใจว่าได้รับการตรวจสอบก่อน หรือคุณอาจต้องโหลดไดรเวอร์ระบายความร้อนก่อนไดรเวอร์ CPUfreq หากเป็นไปได้ที่ CPU ของคุณจะร้อนเกินไประหว่างการบู๊ตเครื่อง ดังนั้น ทำสิ่งที่คุณทำได้เพื่อให้แน่ใจว่า CPUfreq และไดรเวอร์ devfreq ที่เกี่ยวข้องจะตรวจสอบโดยเร็วที่สุด

การประหยัดจากการตรวจสอบไดรเวอร์ CPUfreq ของคุณตั้งแต่เนิ่นๆ อาจมีขนาดเล็กมากไปจนถึงมากได้ ขึ้นอยู่กับว่าคุณจะนำสิ่งเหล่านี้ไปตรวจสอบได้เร็วแค่ไหน และความถี่ที่โปรแกรมโหลดบูตปล่อยให้ CPU เข้ามา

ย้ายโมดูลไปยังพาร์ติชัน init ขั้นที่สอง ผู้ขาย หรือ vendor_dlkm

เนื่องจากกระบวนการเริ่มต้นระยะแรกเป็นแบบอนุกรม จึงไม่มีโอกาสที่จะทำให้กระบวนการบูตขนานกันมากนัก หากไม่จำเป็นต้องใช้โมดูลเพื่อให้ init ระยะแรกเสร็จสิ้น ให้ย้ายโมดูลไปยัง init ระยะที่สองโดยวางไว้ในพาร์ติชัน vendor หรือ vendor_dlkm

การเริ่มต้นระยะแรกไม่จำเป็นต้องตรวจสอบอุปกรณ์หลายตัวเพื่อเข้าสู่ระยะเริ่มต้นที่สอง จำเป็นต้องใช้ฟังก์ชันคอนโซลและที่เก็บข้อมูลแฟลชเท่านั้นสำหรับขั้นตอนการบูตปกติ

โหลดไดรเวอร์ที่จำเป็นต่อไปนี้:

• สุนัขเฝ้าบ้าน
• รีเซ็ต
• ความถี่ซีพียู

สำหรับโหมด fastbootd การกู้คืนและพื้นที่ผู้ใช้ การเริ่มต้นระยะแรกจำเป็นต้องมีอุปกรณ์เพิ่มเติมในการตรวจสอบ (เช่น USB) และแสดงผล เก็บสำเนาของโมดูลเหล่านี้ไว้ใน ramdisk ระยะแรกและในพาร์ติชัน vendor หรือ vendor_dlkm ซึ่งช่วยให้สามารถโหลดได้ในขั้นตอนแรกสำหรับการกู้คืนหรือขั้นตอนการบูต fastbootd อย่างไรก็ตาม อย่าโหลดโมดูลโหมดการกู้คืนในขั้นตอนแรกระหว่างขั้นตอนการบูตปกติ โมดูลโหมดการกู้คืนสามารถเลื่อนไปยังขั้นตอนที่สอง init เพื่อลดเวลาการบูต โมดูลอื่น ๆ ทั้งหมดที่ไม่จำเป็นใน init ระยะแรกควรถูกย้ายไปยังพาร์ติชัน vendor หรือ vendor_dlkm

เมื่อพิจารณารายการอุปกรณ์ลีฟ (เช่น UFS หรือซีเรียล) สคริปต์ dev needs.sh จะค้นหาไดรเวอร์ อุปกรณ์ และโมดูลทั้งหมดที่จำเป็นสำหรับการขึ้นต่อกันหรือซัพพลายเออร์ (เช่น นาฬิกา ตัวควบคุม หรือ gpio ) เพื่อสอบสวน

การย้ายโมดูลไปยังขั้นตอนที่สอง init จะช่วยลดเวลาการบูตด้วยวิธีต่อไปนี้:

• การลดขนาด Ramdisk
  • ซึ่งจะทำให้อ่านแฟลชได้เร็วขึ้นเมื่อ bootloader โหลด ramdisk (ขั้นตอนการบูตแบบอนุกรม)
  • สิ่งนี้ทำให้ความเร็วในการคลายการบีบอัดเร็วขึ้นเมื่อเคอร์เนลคลายการบีบอัด ramdisk (ขั้นตอนการบูตแบบอนุกรม)
• init ขั้นที่สองทำงานคู่ขนาน ซึ่งจะซ่อนเวลาในการโหลดของโมดูลพร้อมกับงานที่กำลังทำในขั้นที่สอง init

การย้ายโมดูลไปยังระยะที่สองสามารถประหยัด เวลาบูตได้ 500 - 1,000 มิลลิวินาที ขึ้นอยู่กับจำนวนโมดูลที่คุณสามารถย้ายไปยังระยะเริ่มต้นที่สองได้

โลจิสติกส์การโหลดโมดูล

บิลด์ Android ล่าสุดมีการกำหนดค่าบอร์ดที่ควบคุมโมดูลที่จะคัดลอกไปยังแต่ละขั้นตอน และโมดูลใดที่โหลด ในส่วนนี้เน้นที่ชุดย่อยต่อไปนี้:

• BOARD_VENDOR_RAMDISK_KERNEL_MODULES รายการโมดูลนี้ที่จะคัดลอกลงใน ramdisk
• BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD รายการโมดูลที่จะโหลดในขั้นตอนแรกนี้
• BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD รายการโมดูลที่จะโหลดเมื่อเลือกการกู้คืนหรือ fastbootd จาก ramdisk
• BOARD_VENDOR_KERNEL_MODULES รายการโมดูลนี้ที่จะคัดลอกลงในพาร์ติชัน vendor หรือ vendor_dlkm ที่ไดเร็กทอรี /vendor/lib/modules/
• BOARD_VENDOR_KERNEL_MODULES_LOAD รายการโมดูลที่จะโหลดในขั้นที่สอง init

โมดูลการบูตและการกู้คืนใน ramdisk จะต้องถูกคัดลอกไปยังผู้ขายหรือพาร์ติชัน vendor_dlkm ที่ /vendor/lib/modules การคัดลอกโมดูลเหล่านี้ไปยังพาร์ติชันของผู้จำหน่ายทำให้มั่นใจได้ว่าโมดูลจะไม่สามารถมองเห็นได้ในระหว่างการเริ่มต้นระยะที่สอง ซึ่งมีประโยชน์สำหรับการดีบักและการรวบรวม modinfo สำหรับรายงานจุดบกพร่อง

การทำสำเนาควรใช้พื้นที่น้อยที่สุดบนพาร์ติชัน vendor หรือ vendor_dlkm ตราบใดที่ชุดโมดูลการบูตถูกย่อให้เล็กสุด ตรวจสอบให้แน่ใจว่าไฟล์ modules.list ของผู้ขายมีรายการโมดูลที่กรองแล้วใน /vendor/lib/modules รายการที่กรองช่วยให้มั่นใจว่าเวลาบูตจะไม่ได้รับผลกระทบจากการโหลดโมดูลอีกครั้ง (ซึ่งเป็นกระบวนการที่มีราคาแพง)

ตรวจสอบให้แน่ใจว่าโมดูลโหมดการกู้คืนโหลดเป็นกลุ่ม การโหลดโมดูลโหมดการกู้คืนสามารถทำได้ทั้งในโหมดการกู้คืนหรือที่จุดเริ่มต้นของขั้นตอนที่สองในการเริ่มต้นแต่ละขั้นตอน

คุณสามารถใช้ไฟล์ Board.Config.mk ของอุปกรณ์เพื่อดำเนินการเหล่านี้ดังที่เห็นในตัวอย่างต่อไปนี้:

# All kernel modules
KERNEL_MODULES := $(wildcard $(KERNEL_MODULE_DIR)/*.ko)
KERNEL_MODULES_LOAD := $(strip $(shell cat $(KERNEL_MODULE_DIR)/modules.load)

# First stage ramdisk modules
BOOT_KERNEL_MODULES_FILTER := $(foreach m,$(BOOT_KERNEL_MODULES),%/$(m))

# Recovery ramdisk modules
RECOVERY_KERNEL_MODULES_FILTER := $(foreach m,$(RECOVERY_KERNEL_MODULES),%/$(m))
BOARD_VENDOR_RAMDISK_KERNEL_MODULES += \
     $(filter $(BOOT_KERNEL_MODULES_FILTER) \
                $(RECOVERY_KERNEL_MODULES_FILTER),$(KERNEL_MODULES))

# ALL modules land in /vendor/lib/modules so they could be rmmod/insmod'd,
# and modules.list actually limits us to the ones we intend to load.
BOARD_VENDOR_KERNEL_MODULES := $(KERNEL_MODULES)
# To limit /vendor/lib/modules to just the ones loaded, use:
# BOARD_VENDOR_KERNEL_MODULES := $(filter-out \
#     $(BOOT_KERNEL_MODULES_FILTER),$(KERNEL_MODULES))

# Group set of /vendor/lib/modules loading order to recovery modules first,
# then remainder, subtracting both recovery and boot modules which are loaded
# already.
BOARD_VENDOR_KERNEL_MODULES_LOAD := \
        $(filter-out $(BOOT_KERNEL_MODULES_FILTER), \
        $(filter $(RECOVERY_KERNEL_MODULES_FILTER),$(KERNEL_MODULES_LOAD)))
BOARD_VENDOR_KERNEL_MODULES_LOAD += \
        $(filter-out $(BOOT_KERNEL_MODULES_FILTER) \
            $(RECOVERY_KERNEL_MODULES_FILTER),$(KERNEL_MODULES_LOAD))

# NB: Load order governed by modules.load and not by $(BOOT_KERNEL_MODULES)
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \
        $(filter $(BOOT_KERNEL_MODULES_FILTER),$(KERNEL_MODULES_LOAD))

# Group set of /vendor/lib/modules loading order to boot modules first,
# then the remainder of recovery modules.
BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD := \
    $(filter $(BOOT_KERNEL_MODULES_FILTER),$(KERNEL_MODULES_LOAD))
BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD += \
    $(filter-out $(BOOT_KERNEL_MODULES_FILTER), \
    $(filter $(RECOVERY_KERNEL_MODULES_FILTER),$(KERNEL_MODULES_LOAD)))

ตัวอย่างนี้แสดงชุดย่อยที่ง่ายต่อการจัดการของ BOOT_KERNEL_MODULES และ RECOVERY_KERNEL_MODULES ที่จะระบุในเครื่องในไฟล์การกำหนดค่าของบอร์ด สคริปต์ก่อนหน้าค้นหาและเติมโมดูลย่อยแต่ละโมดูลจากโมดูลเคอร์เนลที่เลือกไว้ที่มีอยู่ โดยปล่อยให้โมดูลการขุดซ้ำสำหรับการเริ่มต้นระยะที่สอง

สำหรับการเริ่มต้นระยะที่ 2 เราขอแนะนำให้เรียกใช้การโหลดโมดูลเป็นบริการ เพื่อไม่ให้บล็อกโฟลว์การบูต ใช้เชลล์สคริปต์เพื่อจัดการการโหลดโมดูลเพื่อให้สามารถรายงานย้อนกลับ (หรือละเว้น) ลอจิสติกส์อื่นๆ เช่น การจัดการและการบรรเทาข้อผิดพลาด หรือการเสร็จสิ้นการโหลดโมดูล หากจำเป็น

คุณสามารถละเว้นความล้มเหลวในการโหลดโมดูลดีบักที่ไม่มีอยู่บนบิลด์ผู้ใช้ได้ หากต้องการเพิกเฉยต่อความล้มเหลวนี้ ให้ตั้งค่าคุณสมบัติ vendor.device.modules.ready เพื่อทริกเกอร์ขั้นตอนภายหลังของการเริ่มต้นสคริปต์ init rc เพื่อดำเนินการต่อไปยังหน้าจอเรียกใช้งาน อ้างอิงสคริปต์ตัวอย่างต่อไปนี้ หากคุณมีโค้ดต่อไปนี้ใน /vendor/etc/init.insmod.sh :

#!/vendor/bin/sh
. . .
if [ $# -eq 1 ]; then
  cfg_file=$1
else
  # Set property even if there is no insmod config
  # to unblock early-boot trigger
  setprop vendor.common.modules.ready
  setprop vendor.device.modules.ready
  exit 1
fi

if [ -f $cfg_file ]; then
  while IFS="|" read -r action arg
  do
    case $action in
      "insmod") insmod $arg ;;
      "setprop") setprop $arg 1 ;;
      "enable") echo 1 > $arg ;;
      "modprobe") modprobe -a -d /vendor/lib/modules $arg ;;
     . . .
    esac
  done < $cfg_file
fi

ในไฟล์ rc ของฮาร์ดแวร์ สามารถระบุบริการ one shot ด้วย:

service insmod-sh /vendor/etc/init.insmod.sh /vendor/etc/init.insmod.<hw>.cfg
    class main
    user root
    group root system
    Disabled
    oneshot

การปรับให้เหมาะสมเพิ่มเติมสามารถทำได้หลังจากโมดูลย้ายจากระยะที่หนึ่งไปยังระยะที่สอง คุณสามารถใช้ฟีเจอร์รายการบล็อกของ modprobe เพื่อแยกโฟลว์การบูตขั้นที่สองเพื่อรวมการโหลดโมดูลที่เลื่อนออกไปของโมดูลที่ไม่จำเป็น การโหลดโมดูลที่ใช้โดย HAL โดยเฉพาะสามารถเลื่อนออกไปเพื่อโหลดโมดูลได้เฉพาะเมื่อ HAL เริ่มทำงานเท่านั้น

เพื่อปรับปรุงเวลาบูตที่ชัดเจน คุณสามารถเลือกโมดูลในบริการโหลดโมดูลโดยเฉพาะซึ่งเอื้อต่อการโหลดหลังจากหน้าจอเรียกใช้งานมากกว่า ตัวอย่างเช่น คุณสามารถโหลดโมดูลสำหรับตัวถอดรหัสวิดีโอหรือ wifi ล่าช้าได้อย่างชัดเจน หลังจากที่โฟลว์การบูต init ได้รับการล้างแล้ว (เช่น สัญญาณคุณสมบัติ sys.boot_complete Android) ตรวจสอบให้แน่ใจว่า HAL สำหรับโมดูลการโหลดล่าช้าบล็อกนานเพียงพอเมื่อไม่มีไดรเวอร์เคอร์เนล

หรือคุณสามารถใช้คำสั่ง init's wait<file>[<timeout>] ในสคริปต์ rc ของกระแสการบูตเพื่อรอรายการ sysfs ที่เลือกเพื่อแสดงว่าโมดูลไดรเวอร์ได้เสร็จสิ้นการดำเนินการโพรบแล้ว ตัวอย่างนี้กำลังรอให้ไดรเวอร์จอแสดงผลโหลดในพื้นหลังของการกู้คืนหรือ fastbootd จนเสร็จสิ้นก่อนที่จะนำเสนอกราฟิกเมนู

เริ่มต้นความถี่ CPU ให้เป็นค่าที่เหมาะสมใน bootloader

SoC/ผลิตภัณฑ์บางรุ่นอาจไม่สามารถบูต CPU ที่ความถี่สูงสุดได้ เนื่องจากปัญหาด้านความร้อนหรือพลังงานในระหว่างการทดสอบลูปการบูต อย่างไรก็ตาม ตรวจสอบให้แน่ใจว่าโปรแกรมโหลดบูตตั้งค่าความถี่ของ CPU ออนไลน์ทั้งหมดให้สูงที่สุดเท่าที่เป็นไปได้อย่างปลอดภัยสำหรับ SoC/ผลิตภัณฑ์ สิ่งนี้สำคัญมากเพราะด้วยเคอร์เนลแบบโมดูลาร์เต็มรูปแบบ การบีบอัด ramdisk init จะเกิดขึ้นก่อนจึงจะสามารถโหลดไดรเวอร์ CPUfreq ได้ ดังนั้น หาก bootloader ปล่อย CPU ไว้ที่ความถี่ล่างสุด เวลาคลายการบีบอัด ramdisk อาจใช้เวลานานกว่าเคอร์เนลที่คอมไพล์แบบคงที่ (หลังจากปรับตามความแตกต่างของขนาด ramdisk) เนื่องจากความถี่ของ CPU จะต่ำมากเมื่อใช้งาน CPU อย่างเข้มข้น งาน (การบีบอัด) เช่นเดียวกับหน่วยความจำ/ความถี่ในการเชื่อมต่อระหว่างกัน

เริ่มต้นความถี่ CPU ของ CPU ขนาดใหญ่ใน bootloader

ก่อนที่จะโหลดไดรเวอร์ CPUfreq เคอร์เนลจะไม่ทราบความถี่ของ CPU เพียงเล็กน้อยและขนาดใหญ่ และไม่ได้ปรับขนาดความจุตามกำหนดการของ CPU สำหรับความถี่ปัจจุบัน เคอร์เนลอาจย้ายเธรดไปยัง CPU ขนาดใหญ่ หากโหลดบน CPU ตัวเล็กสูงเพียงพอ

ตรวจสอบให้แน่ใจว่า CPU ขนาดใหญ่มีประสิทธิภาพอย่างน้อยเท่ากับ CPU ตัวเล็กสำหรับความถี่ที่โปรแกรมโหลดบูตทิ้งไว้ ตัวอย่างเช่น หาก CPU ขนาดใหญ่มีประสิทธิภาพมากกว่า CPU ตัวเล็กถึง 2 เท่าในความถี่เดียวกัน แต่โปรแกรมโหลดบูตจะตั้งค่า ความถี่ของ CPU เล็กน้อยถึง 1.5 GHz และความถี่ของ CPU ขนาดใหญ่ถึง 300 MHz ดังนั้นประสิทธิภาพการบูตจะลดลงหากเคอร์เนลย้ายเธรดไปยัง CPU ขนาดใหญ่ ในตัวอย่างนี้ หากสามารถบูต CPU ขนาดใหญ่ที่ 750 MHz ได้อย่างปลอดภัย คุณควรทำเช่นนั้นแม้ว่าคุณจะไม่ได้วางแผนที่จะใช้งานอย่างชัดเจนก็ตาม

ไดรเวอร์ไม่ควรโหลดเฟิร์มแวร์ในขั้นตอนแรก

อาจมีบางกรณีที่หลีกเลี่ยงไม่ได้ที่จะต้องโหลดเฟิร์มแวร์ในระยะแรก แต่โดยทั่วไปแล้ว ไดรเวอร์ไม่ควรโหลดเฟิร์มแวร์ใดๆ ในขั้นตอนแรก โดยเฉพาะอย่างยิ่งในบริบทของการตรวจสอบอุปกรณ์ การโหลดเฟิร์มแวร์ในระยะแรกจะทำให้กระบวนการบู๊ตทั้งหมดหยุดทำงานหากไม่มีเฟิร์มแวร์ใน ramdisk ระยะแรก และแม้ว่าเฟิร์มแวร์จะอยู่ใน ramdisk ระยะแรก แต่ก็ยังทำให้เกิดความล่าช้าโดยไม่จำเป็น