การเพิ่มประสิทธิภาพเวลาเปิดเครื่อง

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

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

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

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

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

ระบบจะเปิดใช้การลบสัญลักษณ์โดยค่าเริ่มต้นในบิลด์แพลตฟอร์ม 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 ประเภทเหล่านี้น้อยลงจะช่วยในการลดเวลาในการโหลดโมดูล

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

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

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

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

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

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

หากต้องการเปิดใช้การสอดแนมแบบไม่พร้อมกันสําหรับโมดูล ไม่เพียงพอที่จะตั้งค่า Flag 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 ที่เกี่ยวข้องทำการสแกนให้เร็วที่สุด

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

ย้ายโมดูลไปยังพาร์ติชัน init, ผู้ให้บริการ หรือVendor_dlkm ขั้นที่ 2

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

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

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

  • watchdog
  • reset
  • cpufreq

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

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

การย้ายโมดูลไปยังขั้นตอนที่ 2 จะเป็นการลดเวลาเปิดเครื่องตามขั้นตอนต่อไปนี้

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

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

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

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

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

นอกจากนี้ คุณต้องคัดลอกโมดูลการบูตและการกู้คืนในแรมดิสก์ไปยังพาร์ติชันผู้ให้บริการหรือ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 ที่จัดการได้ง่ายกว่าซึ่งจะระบุได้ภายในไฟล์การกำหนดค่าบอร์ด สคริปต์ก่อนหน้าจะค้นหาและเติมเต็มโมดูลย่อยแต่ละรายการจากโมดูลเคอร์เนลที่เลือกอยู่ ซึ่งจะเหลือโมดูลที่เหลือสำหรับ init ขั้นที่ 2

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

คุณละเว้นการโหลดโมดูลแก้ไขข้อบกพร่องที่ไม่ปรากฏในบิลด์ของผู้ใช้ได้ หากต้องการละเว้นความล้มเหลวนี้ ให้ตั้งค่าพร็อพเพอร์ตี้ 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

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

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

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

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

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

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

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

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

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

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