التشغيل الأولي للوحة Linux مخصصة: من خطوط الطاقة إلى التطبيق

لا يكتمل التشغيل الأولي للوحة Linux مخصصة لمجرد ظهور مطالبة تسجيل الدخول. المعلم المفيد هو سلسلة قابلة للتكرار تبدأ بسلوك صحيح للطاقة وإعادة الضبط، وتمر بصورة إقلاع متحقق منها وبرامج تشغيل طرفية تعمل، وتنتهي بتطبيق يستطيع التعافي من الأعطال المتوقعة.

يصف هذا الدليل خطة تشغيل أولي مرحلية للوحات Linux المدمجة القائمة على شجرة الأجهزة، وخصوصًا تصاميم ARM وAArch64. تحدد ROM الإقلاع الفعلية في SoC ودائرة إدارة الطاقة وحزمة تهيئة DDR وحزمة BSP الخاصة بالمورّد تسلسل الخطوات التفصيلي. الاختبارات التالية فحوص هندسية مقترحة، وليست نتائج مقاسة لمنتج معين.

1. جهّز الأدلة ومسار الاستعادة

قبل توصيل الطاقة، اجمع المخططات ومراجعة التجميع واستبدالات قائمة المواد ومعلومات شجرة الطاقة وطوبولوجيا DDR وإعدادات أطراف اختيار الإقلاع وتوزيع أطراف الموصلات. قارن اللوحة المجمعة بالتصميم المرجعي بدل افتراض التكافؤ الكهربائي للتخطيط. تأكد من أطراف التصحيح التي يمكن الوصول إليها فعلًا بعد التجميع.

جهّز مصدر تغذية محدود التيار مناسبًا للوحة وأجهزة قياس ذات تصنيفات جهد مناسبة ومحوّلًا تسلسليًا متحققًا منه وطريقة الاستعادة المدعومة من المورّد. يجب أن تتطابق مستويات UART من نوع TTL مع نطاق جهد اللوحة؛ ومحوّل RS232 ليس بديلًا مكافئًا له. افصل الأحمال غير الخاضعة للتحكم وافحص مسارات التغذية غير المقصودة عبر USB أو موصلات التصحيح.

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

2. تحقق من الطاقة وإعادة الضبط والساعات

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

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

لا تتحايل على مشكلة كهربائية بتأخيرات برمجية اعتباطية. قد يساعد التأخير على تحديد موضع مشكلة تسلسل، لكن المتطلب النهائي يجب أن يسمّي الاعتماد الفعلي وتوقيته المسموح.

3. أثبت عمل المحمل الأول وDDR ووسيط الإقلاع

حدد كل مرحلة قابلة للتنفيذ في سلسلة الإقلاع. قد تحمل ROM، بحسب المنصة، محمل SPL ومهيئ DDR خاصًا بالمورّد وبرمجيات ثابتة آمنة ثم U-Boot. سجّل إصداراتها وإزاحاتها داخل الحزمة. قد تبدو مشكلة اللوحة مشكلة Linux بينما السبب إدراج مكوّن تدريب DDR غير الصحيح في الصورة.

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

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

4. سلّم Linux وصف العتاد الصحيح

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

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

# Run in the configured kernel source tree with its required tooling.
make dt_binding_check
make dtbs_check

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

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

5. افصل جاهزية النواة عن جاهزية نظام الملفات الجذري

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

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

6. شغّل مسار جهاز طرفي واحدًا في كل مرة

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

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

7. اختبر الاستعادة قبل تسليم التطبيق

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

إذا كان تسجيل الانهيارات المستمر يستخدم ramoops، فاحجز الذاكرة المناسبة وتحقق من احتفاظ مسار إعادة الضبط المختار بمحتواها. لا يضمن ramoops عدم فقدان البيانات عند انقطاع الطاقة؛ راجع وثائق ramoops في النواة. ينبغي لأدلة القبول أن توضح ما التُقط وما بقي دون اختبار.

نطاق عملي للتشغيل الأولي للوحة

تصف تهيئة مشروع الطرفية المدمجة RK3566 وتكييف BSP لدى Obeita طرفية مخصصة لشاشة معينة مع أجهزة طرفية موصولة عبر FPC. تميز الصفحة صراحةً بين الواجهات الموصلة على اللوحة والواجهات التي تحتاج إلى مراجعة جديدة للوحة. هذه هي الحدود الصحيحة لخطة التشغيل الأولي، بدل افتراض أن كل ميزة في SoC متاحة في المنتج المجمّع.

لإجراء تقييم عبر خدمة تشخيص البرمجيات الثابتة وحزم دعم اللوحات BSP، قدم مراجعة اللوحة والمخطط وسجل الإقلاع البارد الكامل وبيان الصور وأول مرحلة تفشل. عادة ما توفر حدود المرحلة الواضحة نقطة بدء أسهل للعمل من عبارة «Linux لا يعمل».