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

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

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

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

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

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

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

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

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

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

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

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

• watchdog
• reset
• cpufreq

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

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

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

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

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

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

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

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

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

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

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