تحسين وقت التشغيل

توفّر هذه الصفحة نصائح لتحسين وقت الإقلاع.

إزالة رموز تصحيح الأخطاء من الوحدات

على غرار إزالة رموز تصحيح الأخطاء من النواة على جهاز إنتاج، تأكَّد أيضًا من إزالة رموز تصحيح الأخطاء من الوحدات. تساعد إزالة رموز تصحيح الأخطاء من الوحدات في تحسين وقت الإقلاع من خلال تقليل ما يلي:

• الوقت اللازم لقراءة الملفات الثنائية من ذاكرة الفلاش
• الوقت اللازم لفك ضغط ذاكرة الوصول العشوائي الظاهرية
• الوقت اللازم لتحميل الوحدات

قد تؤدي إزالة رموز تصحيح الأخطاء من الوحدات إلى توفير عدة ثوانٍ أثناء الإقلاع.

تكون ميزة إزالة الرموز مفعّلة تلقائيًا في إصدار نظام Android الأساسي، ولكن لتفعيلها بشكلٍ صريح، اضبط BOARD_DO_NOT_STRIP_VENDOR_RAMDISK_MODULES في الإعدادات الخاصة بجهازك ضمن device/vendor/device.

استخدام ضغط LZ4 للنواة وذاكرة الوصول العشوائي الظاهرية

ينتج برنامج Gzip إخراجًا مضغوطًا أصغر مقارنةً ببرنامج LZ4، ولكن برنامج LZ4 يفك الضغط بشكلٍ أسرع من برنامج Gzip. بالنسبة إلى النواة والوحدات، لا يكون الانخفاض المطلق في حجم التخزين الناتج عن استخدام برنامج Gzip كبيرًا مقارنةً بفائدة وقت فك الضغط التي يقدّمها برنامج LZ4.

تمت إضافة دعم لضغط ذاكرة الوصول العشوائي الظاهرية باستخدام برنامج LZ4 إلى إصدار نظام Android الأساسي من خلال BOARD_RAMDISK_USE_LZ4. يمكنك ضبط هذا الخيار في الإعدادات الخاصة بجهازك. يمكن ضبط ضغط النواة من خلال إعدادات النواة التلقائية.

من المفترض أن يؤدي التبديل إلى برنامج LZ4 إلى تقليل وقت الإقلاع بمقدار يتراوح بين 500 ملي ثانية و1000 ملي ثانية.

تجنُّب التسجيل المفرط في برامج التشغيل

في ARM64 وARM32، تحتاج استدعاءات الدوال التي تبعد أكثر من مسافة معيّنة عن موقع الاستدعاء إلى جدول انتقال (يُعرف باسم جدول ربط الإجراءات أو PLT) لتتمكّن من ترميز عنوان الانتقال الكامل. بما أنّ الوحدات يتم تحميلها ديناميكيًا، يجب إصلاح جداول الانتقال هذه أثناء تحميل الوحدة. تُعرف الاستدعاءات التي تحتاج إلى النقل باسم إدخالات النقل مع عوامل جمع صريحة (أو RELA باختصار) في تنسيق ELF.

تجري نواة Linux بعض التحسينات على حجم الذاكرة (مثل تحسينات ذاكرة التخزين المؤقت) عند تخصيص جدول ربط الإجراءات. باستخدام عملية الإرسال هذه، يتّسم نظام التحسين بالتعقيد O(N^2)، حيث N هو عدد إدخالات RELA من النوع R_AARCH64_JUMP26 أو R_AARCH64_CALL26. لذلك، من المفيد تقليل عدد إدخالات RELA من هذه الأنواع لتقليل مدّة تحميل الوحدة.

أحد أنماط الترميز الشائعة التي تزيد من عدد إدخالات RELA من النوع R_AARCH64_CALL26 أو R_AARCH64_JUMP26 هو التسجيل المفرط في برنامج التشغيل. يضيف كل استدعاء للدالة printk() أو أي نظام تسجيل آخر عادةً إدخال RELA من النوع CALL26/JUMP26. في نص عملية الإرسال في عملية الإرسال، لاحظ أنّه حتى مع التحسين، يستغرق تحميل الوحدات الست حوالي 250 ملي ثانية، وذلك لأنّ هذه الوحدات الست كانت أفضل ست وحدات من حيث مقدار التسجيل.

يمكن أن يؤدي تقليل التسجيل إلى توفير ما بين 100 ملي ثانية و300 ملي ثانية تقريبًا من أوقات الإقلاع، وذلك حسب مدى التسجيل المفرط الحالي.

تفعيل عملية الفحص غير المتزامن بشكلٍ انتقائي

عند تحميل وحدة، إذا كان الجهاز الذي تدعمه قد تم ملؤه من شجرة الأجهزة (devicetree) وإضافته إلى النواة، يتم إجراء فحص الجهاز في سياق استدعاء module_init(). عند إجراء فحص الجهاز في سياق module_init()، لا يمكن أن ينتهي تحميل الوحدة إلا بعد اكتمال الفحص. بما أنّ تحميل الوحدات يتم بشكلٍ متسلسل في الغالب، فإنّ الجهاز الذي يستغرق وقتًا طويلاً نسبيًا لفحصه يؤدي إلى إبطاء وقت الإقلاع.

لتجنُّب أوقات الإقلاع الأبطأ، فعِّل عملية الفحص غير المتزامن للوحدات التي تستغرق وقتًا طويلاً لفحص أجهزتها. قد لا يكون تفعيل عملية الفحص غير المتزامن لجميع الوحدات مفيدًا لأنّ الوقت اللازم لإنشاء سلسلة عمليات وبدء الفحص قد يكون مرتفعًا مثل الوقت اللازم لفحص الجهاز.

يمكن أن تؤدي الأجهزة المتصلة عبر ناقل بطيء مثل I2C، والأجهزة التي تحمّل البرامج الثابتة في دالة الفحص، والأجهزة التي تجري الكثير من عمليات تهيئة الأجهزة إلى حدوث مشكلة في التوقيت. أفضل طريقة لتحديد متى يحدث ذلك هي جمع وقت الفحص لكل برنامج تشغيل وترتيبه.

لتفعيل عملية الفحص غير المتزامن لوحدة، لا يكفي ضبط العلامة PROBE_PREFER_ASYNCHRONOUS في رمز برنامج التشغيل فقط. بالنسبة إلى الوحدات، عليك أيضًا إضافة module_name.async_probe=1 في سطر أوامر النواة أو تمرير async_probe=1 كمعلَمة وحدة عند تحميل الوحدة باستخدام modprobe أو insmod.

يمكن أن يؤدي تفعيل عملية الفحص غير المتزامن إلى توفير ما بين 100 ملي ثانية و500 ملي ثانية تقريبًا من أوقات الإقلاع، وذلك حسب الأجهزة/برامج التشغيل.

فحص برنامج تشغيل CPUfreq في أقرب وقت ممكن

كلما كان فحص برنامج تشغيل CPUfreq مبكرًا، زادت سرعة زيادة تردد وحدة المعالجة المركزية إلى الحد الأقصى (أو الحد الأقصى المحدود حراريًا) أثناء الإقلاع. كلما كانت وحدة المعالجة المركزية أسرع، كان الإقلاع أسرع. ينطبق هذا الإرشاد أيضًا على برامج تشغيل devfreq التي تتحكّم في تردد ذاكرة الوصول العشوائي الديناميكية (DRAM) والذاكرة والربط البيني.

بالنسبة إلى الوحدات، يمكن أن يعتمد ترتيب التحميل على مستوى initcall وترتيب تجميع برامج التشغيل أو ربطها. استخدِم الاسم المستعار MODULE_SOFTDEP() للتأكّد من أنّ برنامج تشغيل cpufreq من بين الوحدات القليلة الأولى التي يتم تحميلها.

بالإضافة إلى تحميل الوحدة مبكرًا، عليك أيضًا التأكّد من أنّ جميع التبعيات اللازمة لفحص برنامج تشغيل CPUfreq قد تم فحصها أيضًا. على سبيل المثال، إذا كنت بحاجة إلى مقبض ساعة أو منظِّم للتحكّم في تردد وحدة المعالجة المركزية، تأكَّد من فحصهما أولاً. أو قد تحتاج إلى تحميل برامج التشغيل الحرارية قبل برنامج تشغيل CPUfreq إذا كان من الممكن أن تصبح وحدات المعالجة المركزية ساخنة جدًا أثناء الإقلاع. لذلك، ابذل قصارى جهدك للتأكّد من فحص برنامج تشغيل CPUfreq وبرامج تشغيل devfreq ذات الصلة في أقرب وقت ممكن.

يمكن أن تكون عمليات التوفير الناتجة عن فحص برنامج تشغيل CPUfreq مبكرًا صغيرة جدًا أو كبيرة جدًا، وذلك حسب مدى سرعة فحص هذه البرامج والتردد الذي يضبطه برنامج الإقلاع لوحدات المعالجة المركزية.

نقل الوحدات إلى مرحلة الإعداد الثانية أو قسم المورّد أو `vendor_dlkm`

بما أنّ عملية الإعداد في المرحلة الأولى تتم بشكلٍ متسلسل، لا تتوفّر فرص كثيرة لتنفيذ عملية الإقلاع بالتوازي. إذا لم تكن الوحدة مطلوبة لإنهاء عملية الإعداد في المرحلة الأولى، انقل الوحدة إلى مرحلة الإعداد الثانية من خلال وضعها في قسم المورّد أو vendor_dlkm.

لا تتطلب عملية الإعداد في المرحلة الأولى فحص عدة أجهزة للوصول إلى مرحلة الإعداد الثانية. لا يلزم سوى إمكانات وحدة التحكّم ووحدة تخزين الفلاش لتدفق الإقلاع العادي.

حمِّل برامج التشغيل الأساسية التالية:

• watchdog
• reset
• cpufreq

بالنسبة إلى وضع الاسترداد ووضع fastbootd في مساحة المستخدم، تتطلب عملية الإعداد في المرحلة الأولى فحص المزيد من الأجهزة (مثل USB) والشاشة. احتفِظ بنسخة من هذه الوحدات في ذاكرة الوصول العشوائي الظاهرية للمرحلة الأولى وفي قسم المورّد أو vendor_dlkm. يتيح ذلك تحميلها في عملية الإعداد في المرحلة الأولى لتدفق الإقلاع في وضع الاسترداد أو fastbootd. ومع ذلك، لا تحمِّل وحدات وضع الاسترداد في عملية الإعداد في المرحلة الأولى أثناء تدفق الإقلاع العادي. يمكن تأجيل وحدات وضع الاسترداد إلى مرحلة الإعداد الثانية لتقليل وقت الإقلاع. يجب نقل جميع الوحدات الأخرى التي ليست مطلوبة في عملية الإعداد في المرحلة الأولى إلى قسم المورّد أو vendor_dlkm.

بالنظر إلى قائمة بأجهزة الأطراف (مثل UFS أو المنفذ التسلسلي)، dev needs.sh يعثر النص البرمجي على جميع برامج التشغيل والأجهزة والوحدات اللازمة لفحص التبعيات أو المورّدين (مثل الساعات أو المنظِّمات أو gpio).

يؤدي نقل الوحدات إلى مرحلة الإعداد الثانية إلى تقليل أوقات الإقلاع بالطرق التالية:

• تقليل حجم ذاكرة الوصول العشوائي الظاهرية
  • يؤدي ذلك إلى عمليات قراءة أسرع من ذاكرة الفلاش عندما يحمّل برنامج الإقلاع ذاكرة الوصول العشوائي الظاهرية (خطوة الإقلاع المتسلسلة).
  • يؤدي ذلك إلى سرعات فك ضغط أسرع عندما تفك النواة ضغط ذاكرة الوصول العشوائي الظاهرية (خطوة الإقلاع المتسلسلة).
• تعمل عملية الإعداد في المرحلة الثانية بالتوازي، ما يخفي وقت تحميل الوحدة مع العمل الذي يتم في مرحلة الإعداد الثانية.

يمكن أن يؤدي نقل الوحدات إلى مرحلة الإعداد الثانية إلى توفير ما بين 500 ملي ثانية و1000 ملي ثانية تقريبًا من أوقات الإقلاع، وذلك حسب عدد الوحدات التي يمكنك نقلها إلى مرحلة الإعداد الثانية.

الخدمات اللوجستية لتحميل الوحدات

يتميّز أحدث إصدار من Android بإعدادات لوحة تحكّم تتحكّم في الوحدات التي يتم نسخها إلى كل مرحلة والوحدات التي يتم تحميلها. يركّز هذا القسم على المجموعة الفرعية التالية:

• BOARD_VENDOR_RAMDISK_KERNEL_MODULES: هذه قائمة بالوحدات التي سيتم نسخها إلى ذاكرة الوصول العشوائي الظاهرية.
• BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD: هذه قائمة بالوحدات التي سيتم تحميلها في عملية الإعداد في المرحلة الأولى.
• BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD: هذه قائمة بالوحدات التي سيتم تحميلها عند اختيار وضع الاسترداد أو fastbootd من ذاكرة الوصول العشوائي الظاهرية.
• BOARD_VENDOR_KERNEL_MODULES: هذه قائمة بالوحدات التي سيتم نسخها إلى قسم المورّد أو vendor_dlkm في الدليل /vendor/lib/modules/.
• BOARD_VENDOR_KERNEL_MODULES_LOAD: هذه قائمة بالوحدات التي سيتم تحميلها في مرحلة الإعداد الثانية.

يجب أيضًا نسخ وحدات الإقلاع والاسترداد في ذاكرة الوصول العشوائي الظاهرية إلى قسم المورّد أو vendor_dlkm في /vendor/lib/modules. يضمن نسخ هذه الوحدات إلى قسم المورّد عدم إخفاء الوحدات أثناء مرحلة الإعداد الثانية، ما يكون مفيدًا لتصحيح الأخطاء وجمع modinfo لتقارير الأخطاء.

يجب ألا يؤدي التكرار إلى استهلاك مساحة صغيرة جدًا على قسم المورّد أو 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 ليتم تحديدها محليًا في ملفات إعداد اللوحة. يعثر النص البرمجي السابق على كل وحدات المجموعة الفرعية ويملأها من وحدات النواة المتاحة المحدّدة، ويترك الوحدات المتبقية لمرحلة الإعداد الثانية.

بالنسبة إلى مرحلة الإعداد الثانية، ننصح بتشغيل تحميل الوحدة كخدمة حتى لا تحظر تدفق الإقلاع. استخدِم نصًا برمجيًا للواجهة لتنظيم تحميل الوحدة حتى يمكن الإبلاغ عن الخدمات اللوجستية الأخرى، مثل معالجة الأخطاء وتخفيفها أو اكتمال تحميل الوحدة، أو تجاهلها إذا لزم الأمر.

يمكنك تجاهل فشل تحميل وحدة تصحيح الأخطاء غير المتوفّرة في إصدارات المستخدم. لتجاهل هذا الفشل، اضبط السمة 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.

لتحسين أوقات الإقلاع الظاهرة، يمكنك اختيار الوحدات بشكلٍ خاص في خدمة تحميل الوحدات التي تكون أكثر ملاءمة للتحميل بعد شاشة الإطلاق. على سبيل المثال، يمكنك تحميل الوحدات الخاصة بفك ترميز الفيديو أو شبكة Wi-Fi بشكلٍ صريح في وقت لاحق بعد محو تدفق إقلاع عملية الإعداد (إشارة سمة Android sys.boot_complete، على سبيل المثال). تأكَّد من أنّ واجهات HAL للوحدات التي يتم تحميلها في وقت لاحق تحظر المدة الكافية عندما لا تكون برامج تشغيل النواة متوفّرة.

بدلاً من ذلك، يمكنك استخدام الأمر wait<file>[<timeout>] في `init` في النص البرمجي لملف rc الخاص بتدفق الإقلاع للانتظار إلى أن تشير إدخالات sysfs المحدّدة إلى أنّ برامج تشغيل الوحدات قد أكملت عمليات الفحص. أحد الأمثلة على ذلك هو الانتظار إلى أن يكتمل تحميل برنامج تشغيل الشاشة في خلفية وضع الاسترداد أو fastbootd، قبل عرض رسومات القائمة.

تهيئة تردد وحدة المعالجة المركزية إلى قيمة معقولة في برنامج الإقلاع

قد لا تتمكّن بعض أنظمة SoC/المنتجات من إقلاع وحدة المعالجة المركزية بأعلى تردد بسبب المشاكل الحرارية أو مشاكل الطاقة أثناء اختبارات حلقة الإقلاع. ومع ذلك، تأكَّد من أنّ برنامج الإقلاع يضبط تردد جميع وحدات المعالجة المركزية المتاحة على أعلى مستوى ممكن بأمان لنظام SoC أو منتج. يُعدّ ذلك مهمًا جدًا لأنه مع نواة معيارية بالكامل، يتم فك ضغط ذاكرة الوصول العشوائي الظاهرية لعملية الإعداد قبل أن يتم تحميل برنامج تشغيل CPUfreq. لذلك، إذا ترك برنامج الإقلاع وحدة المعالجة المركزية في الطرف الأدنى من ترددها، يمكن أن يستغرق وقت فك ضغط ذاكرة الوصول العشوائي الظاهرية وقتًا أطول من نواة تم تجميعها بشكلٍ ثابت (بعد تعديل الفرق في حجم ذاكرة الوصول العشوائي الظاهرية) لأنّ تردد وحدة المعالجة المركزية سيكون منخفضًا جدًا عند إجراء عمل مكثف لوحدة المعالجة المركزية (فك الضغط). ينطبق الأمر نفسه على تردد الذاكرة والربط البيني.

تهيئة تردد وحدة المعالجة المركزية لوحدات المعالجة المركزية الكبيرة في برنامج الإقلاع

قبل تحميل برنامج تشغيل CPUfreq، لا تكون النواة على علم بترددات وحدة المعالجة المركزية ولا تزيد سعة جدولة وحدة المعالجة المركزية لترددها الحالي. قد تنقل النواة سلاسل العمليات إلى وحدة المعالجة المركزية الكبيرة إذا كان الحمل مرتفعًا بدرجة كافية على وحدة المعالجة المركزية الصغيرة.

تأكَّد من أنّ أداء وحدات المعالجة المركزية الكبيرة على الأقل جيد مثل أداء وحدات المعالجة المركزية الصغيرة للتردد الذي يضبطه برنامج الإقلاع. على سبيل المثال، إذا كان أداء وحدة المعالجة المركزية الكبيرة أفضل بمرتين من أداء وحدة المعالجة المركزية الصغيرة للتردد نفسه، ولكن برنامج الإقلاع يضبط تردد وحدة المعالجة المركزية الصغيرة على 1.5 غيغاهرتز وتردد وحدة المعالجة المركزية الكبيرة على 300 ميغاهرتز، سينخفض أداء الإقلاع إذا نقلت النواة سلسلة عمليات إلى وحدة المعالجة المركزية الكبيرة. في هذا المثال، إذا كان من الآمن إقلاع وحدة المعالجة المركزية الكبيرة بتردد 750 ميغاهرتز، عليك إجراء ذلك حتى إذا لم تكن تخطط لاستخدامها بشكلٍ صريح.

يجب ألا تحمّل برامج التشغيل البرامج الثابتة في عملية الإعداد في المرحلة الأولى

قد تكون هناك بعض الحالات التي لا يمكن تجنُّبها والتي يجب فيها تحميل البرامج الثابتة في عملية الإعداد في المرحلة الأولى. ولكن بشكلٍ عام، يجب ألا تحمّل برامج التشغيل أي برامج ثابتة في عملية الإعداد في المرحلة الأولى، خاصةً في سياق فحص الجهاز. يؤدي تحميل البرامج الثابتة في عملية الإعداد في المرحلة الأولى إلى توقف عملية الإقلاع بالكامل إذا لم تكن البرامج الثابتة متوفّرة في ذاكرة الوصول العشوائي الظاهرية للمرحلة الأولى. وحتى إذا كانت البرامج الثابتة متوفّرة في ذاكرة الوصول العشوائي الظاهرية للمرحلة الأولى، فإنّها لا تزال تؤدي إلى تأخير غير ضروري.