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

หน้านี้มีเคล็ดลับในการปรับปรุงเวลาในการบูต

ลบสัญลักษณ์การแก้ไขข้อบกพร่องออกจากโมดูล

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

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

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

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

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

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

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

การเปลี่ยนไปใช้ LZ4 จะช่วยให้เวลาในการบูตเร็วขึ้น 500-1,000 มิลลิวินาที

หลีกเลี่ยงการบันทึกมากเกินไปในไดรเวอร์

ใน 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 RELA คือการบันทึกมากเกินไปในไดรเวอร์ โดยปกติแล้ว การเรียกใช้ printk() หรือรูปแบบการบันทึกอื่นๆ จะเพิ่มรายการ CALL26/JUMP26 RELA ในข้อความคอมมิตในคอมมิตต้นทาง โปรดสังเกตว่าแม้จะมีการเพิ่มประสิทธิภาพแล้ว แต่โมดูลทั้ง 6 ก็ยังใช้เวลาประมาณ 250 มิลลิวินาที ในการโหลด เนื่องจากโมดูลทั้ง 6 เป็นโมดูล 6 อันดับแรกที่มี การบันทึกมากที่สุด

การลดการบันทึกอาจช่วยประหยัดเวลาในการบูตได้ประมาณ 100-300 มิลลิวินาที ขึ้นอยู่กับ ปริมาณการบันทึกที่มีอยู่

เปิดใช้การตรวจสอบแบบไม่พร้อมกันโดยเลือก

เมื่อโหลดโมดูลแล้ว หากอุปกรณ์ที่โมดูลรองรับได้รับการ ป้อนข้อมูลจาก DT (devicetree) และเพิ่มลงในไดรเวอร์หลักแล้ว ระบบจะ ตรวจสอบอุปกรณ์ในบริบทของการเรียก 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 ทำงาน

ย้ายโมดูลไปยังการเริ่มต้นระยะที่ 2, พาร์ติชัน vendor หรือ vendor_dlkm

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

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

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

• watchdog
• reset
• cpufreq

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

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

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

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

การย้ายโมดูลไปยังระยะที่ 2 จะช่วยประหยัดเวลาในการบูตได้ 500-1000 มิลลิวินาที ขึ้นอยู่กับ จำนวนโมดูลที่คุณย้ายไปยัง init ระยะที่ 2 ได้

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

บิลด์ 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 รายการโมดูลที่จะโหลดใน การเริ่มต้นระยะที่ 2

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

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

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

คุณใช้ไฟล์ 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

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

คุณสามารถละเว้นข้อผิดพลาดในการโหลดโมดูลการแก้ไขข้อบกพร่องที่ไม่ได้อยู่ในบิลด์ของผู้ใช้ได้ หากต้องการไม่สนใจความล้มเหลวนี้ ให้ตั้งค่าพร็อพเพอร์ตี้ vendor.device.modules.ready เพื่อทริกเกอร์ขั้นตอนที่เหลือของ init rc สคริปต์ Bootflow เพื่อไปยังหน้าจอเปิดตัว อ้างอิงสคริปต์ตัวอย่างต่อไปนี้ หากคุณมีโค้ดต่อไปนี้ ใน /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 เพื่อแยกโฟลว์การบูตในระยะที่ 2 ออกเป็นส่วนๆ เพื่อรวมการโหลดโมดูลที่ไม่จำเป็นที่เลื่อนออกไป การโหลดโมดูลที่ใช้โดย HAL ที่เฉพาะเจาะจงเท่านั้นสามารถเลื่อนออกไป เพื่อโหลดโมดูลเมื่อ HAL เริ่มทำงานเท่านั้น

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

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

เริ่มต้นความถี่ CPU เป็นค่าที่สมเหตุสมผลใน Bootloader

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

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

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

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

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

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