سلسلة إقلاع لينكس المدمج

July 30, 2026 · – زوار

في المرة السابقة، كتبت عن DFU كوسيلة لبرمجة الفلاش عبر USB. تلك التدوينة تجاوزت سؤالًا يستحق إجابة مستقلة بذاته: ماذا يحدث فعليًا بين الضغط على زر التشغيل وظهور موجّه أوامر (shell prompt)؟ DFU ليس سوى فرع واحد من هذا المسار، لذا يستحق الأمر المرور على المسار بأكمله مرة واحدة.

المراحل

عند رسمها كمخطط Mermaid، تبدو السلسلة (مع موقع DFU ضمنها) كما يلي:

flowchart TD
    A[Power-on / Reset] --> B[Boot ROM<br/>immutable, on-chip]
    B --> C{Valid image on<br/>boot media?}
    C -->|No / forced| D[ROM recovery mode<br/>UART / USB]
    C -->|Yes| E[SPL<br/>first-stage bootloader]
    E --> F[U-Boot<br/>second-stage bootloader]
    F --> G{Enter DFU?}
    G -->|Yes| H[DFU mode<br/>waiting for firmware over USB]
    G -->|No| I[Load kernel + device tree]
    I --> J[Linux kernel]
    J --> K[Mount root filesystem]
    K --> L[init / systemd]

وبعد رسمها بصريًا:

Boot ROM

مغروس داخل السيليكون وقت التصنيع — لا يمكن تغيير أي شيء فيه لاحقًا. مهمته الوحيدة هي إيجاد شيء ما قابل للإقلاع على واحد من مجموعة صغيرة من وسائط الإقلاع (eMMC، SD، فلاش QSPI، وأحيانًا USB) بناءً على دبابيس وضع الإقلاع (boot-mode pins) أو eFuses، ثم القفز إليه. إذا لم يجد أي شيء صالح، فإن معظم الشرائح (SoCs) تنتقل في هذه المرحلة إلى وضع استعادة بسيط عبر UART أو USB — وهو أول موضع يمكنك فيه التواصل مع الشريحة على الإطلاق.

SPL

اختصار لـ Secondary Program Loader (هذا هو المصطلح الذي يستخدمه U-Boot؛ موردون آخرون يسمونه FSBL أو ما شابه). يعمل من كمية صغيرة من ذاكرة SRAM المدمجة في الشريحة، قبل أن تُهيَّأ ذاكرة DRAM أصلًا، لذا يجب أن يكون صغير الحجم للغاية. مهمته الرئيسية هي بالضبط ذلك: تهيئة DRAM، ثم تحميل المرحلة التالية — وهي U-Boot الكامل — داخلها.

U-Boot الكامل

هذا هو المُحمِّل الإقلاعي الذي يقصده معظم الناس عند قولهم "bootloader". يحتوي على تعريفات (drivers)، وموجّه أوامر (shell)، ومتغيرات بيئة، ودعم شبكي، ومفسّر أوامر. وهنا أيضًا يقيم DFU فعليًا — تشغيل الأمر dfu 0 mmc 0 (أو ما شابهه) يُدخل U-Boot في وضع DFU بدلًا من متابعة الإقلاع الطبيعي، وهذا هو الوضع الذي تتواصل معه أداة dfu-util من جهة المضيف. وإلا، فإنه يُحمِّل صورة النواة وملف شجرة الأجهزة (device tree blob) إلى الذاكرة ويقفز إلى النواة.

النواة وفضاء المستخدم

تقوم النواة بفك ضغط نفسها، وتشغيل الطرفية (console)، واستكشاف العتاد باستخدام شجرة الأجهزة التي تسلّمتها، ثم تركيب نظام ملفات جذري — غالبًا نفس بطاقة eMMC أو SD التي أقلع منها المُحمِّل الإقلاعي، وأحيانًا عبر NFS أثناء التطوير. بمجرد تركيب نظام الملفات الجذري، تسلّم النواة التحكم إلى العملية ذات المعرّف PID 1 — عادة systemd في صورة مبنية بواسطة Yocto — وعند تلك النقطة يبدأ "فضاء المستخدم" فعليًا.

لماذا يهم هذا بالنسبة لـ DFU

لا معنى لـ DFU إلا عند رؤية موقعه: إنه التفاف يمكن لـ U-Boot أن يسلكه بدلًا من تحميل النواة، وليس شيئًا منفصلًا مُلحقًا فوقه. ولهذا السبب أيضًا لا يستطيع DFU إنقاذ كل أنماط الأعطال — فإذا لم يستطع boot ROM نفسه إيجاد SPL صالح، فلن تصل إلى U-Boot على الإطلاق، وستكون معتمدًا عندئذ على أي وضع استعادة يدعمه boot ROM (وهذا يختلف كثيرًا حسب المورّد، وهو موضوع جيد لتدوينة أخرى).

قراءات إضافية

• U-Boot: Generic SPL framework — كيفية بناء SPL وما الذي يتحمل مسؤوليته.
• Trusted Firmware-A: Firmware Design — تدفق الإقلاع متعدد المراحل الأكثر تفصيلًا (BL1/BL2/BL31/BL32/BL33) المستخدم في العديد من شرائح Arm الحديثة ذات سلسلة إقلاع آمنة، والذي يقع أسفل U-Boot على تلك المنصات.

قراءات ذات صلة

• ما هي شجرة الأجهزة؟ — كيف يُوصَف العتاد للنواة
• ما هو DFU؟ نظرة عملية على تحديث برامج الأجهزة الثابتة (Device Firmware Update) — كتابة البرنامج الثابت عبر USB حين لا يبقى سبيل آخر