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

หน้านี้มีเคล็ดลับในการปรับปรุงเวลาเปิดเครื่อง

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • watchdog
  • reset
  • cpufreq

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

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

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

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

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

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

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

  • BOARD_VENDOR_RAMDISK_KERNEL_MODULES รายการโมดูลนี้ที่จะคัดลอกไป Ramdisk
  • BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD รายการโมดูลที่จะโหลดนี้ ในระยะแรก
  • BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD รายการโมดูลสำหรับ จะโหลดเมื่อมีการเลือกการกู้คืนหรือ fastbootd จาก RAM
  • 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 รายการที่กรองจะช่วยให้มั่นใจได้ว่าเวลาในการบูตจะไม่ได้รับผลกระทบจากการโหลดโมดูลอีกครั้ง (ซึ่งเป็นกระบวนการที่สิ้นเปลืองทรัพยากร)

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

คุณสามารถใช้ไฟล์ 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 เราขอแนะนําให้เรียกใช้การโหลดโมดูลเป็นบริการเพื่อไม่ให้บล็อกขั้นตอนการบูต ใช้สคริปต์ 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

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

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

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

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

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

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

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

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

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

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