nearology
fc45c88708
6.1 KiB
فلش و تست دستگاه Amin Pardaz Asia v1.5
workflow اصلی flash-aminpa-V1.5.yml با push به شاخهٔ main اجرا می‌شود.
workflow تست نرم‌افزاری برای اجرا پس از موفقیت آن و همچنین اجرای دستی تعریف شده است.
متغیرهای Gitea برای شبکهٔ U-Boot و TFTP
این متغیرها را در تنظیمات مخزن، بخش Actions → Variables تعریف کنید. workflow تنظیم شبکه و workflow اصلی فلش از آن‌ها استفاده می‌کنند.
| نام متغیر | کاربرد | پیش‌فرض |
|---|---|---|
UBOOT_DEVICE_IP |
IP دستگاه در U-Boot؛ مقدار ipaddr |
192.168.75.100 |
TFTP_SERVER_IP |
IP سرور TFTP؛ مقدار serverip و مقصد ping بررسی شبکه |
192.168.75.247 |
هر دو مقدار باید IPv4 معتبر و بدون CIDR باشند. اگر متغیر تعریف نشود،
مقدار پیش‌فرض استفاده می‌شود. مقدار تنظیم‌شده روی برد بازخوانی و بررسی می‌شود.
UBOOT_DEVICE_IP مربوط به مرحلهٔ فلش است؛ TEST_DEVICE_IP مربوط به دستگاه
پس از بوت سیستم‌عامل است و می‌تواند متفاوت باشد.
نمونهٔ اجرای مستقیم:
/usr/bin/python3 deployment/serial/serial_command.py configure \
--device-ip 192.168.75.100 \
--tftp-server-ip 192.168.75.247
متغیرهای Gitea برای تست نرم‌افزاری
متغیرها را در تنظیمات مخزن Gitea، بخش Actions → Variables تعریف کنید. نام متغیرها باید دقیقاً مطابق جدول باشد.
| نام متغیر | کاربرد | پیش‌فرض | الزامی |
|---|---|---|---|
TEST_INTERFACE |
نام کارت شبکهٔ میزبان runner برای تست | eno1 |
خیر |
TEST_HOST_IP |
آدرس IPv4 میزبان runner روی کارت شبکهٔ تست | 192.168.75.15 |
خیر |
TEST_DEVICE_IP |
آدرس IPv4 دستگاه فلش‌شده که باید به ping پاسخ دهد | ندارد | بله |
TEST_HOST_IP آدرس میزبان است، نه دستگاه هدف. مقدار TEST_DEVICE_IP باید
با آن متفاوت باشد و با IP دستگاه پس از بوت سیستم‌عامل مطابقت داشته باشد؛
این مقدار لزوماً همان ipaddr موقت در U-Boot نیست.
IP میزبان باید از قبل روی کارت شبکهٔ انتخاب‌شده تنظیم شده باشد و مسیر رسیدن به دستگاه از همان کارت شبکه عبور کند. اسکریپت تنظیمات شبکهٔ میزبان را تغییر نمی‌دهد. مقادیر IP به‌صورت آدرس IPv4 وارد می‌شوند، نه رنج یا CIDR.
اسکریپت با پایتون سیستم و ابزارهای سیستم ip و ping اجرا می‌شود.
پس از بررسی تنظیمات میزبان، حداکثر ۱۸۰ ثانیه منتظر پاسخ ping دستگاه می‌ماند؛
اولین پاسخ موفق نتیجهٔ PASS دارد. نبود پاسخ تا پایان مهلت یا خطای تنظیمات
باعث FAIL و شکست workflow می‌شود.
نمونهٔ اجرای دستی روی runner با جایگزین‌کردن IP واقعی دستگاه:
/usr/bin/python3 deployment/serial/software_test.py \
--interface eno1 \
--host-ip 192.168.75.15 \
--device-ip <DEVICE_IP>
برای محل فایل‌های firmware و نقشهٔ فلش، راهنمای firmware را ببینید.
ساختار استقرار
اسکریپت‌های اجرایی در deployment/serial/ قرار دارند:
serial_command.py: کنترل U-Boot، فلش و راه‌اندازی برد از طریق سریال.software_test.py: بررسی پاسخ ping دستگاه پس از بوت.
workflowهای اصلی امین‌پرداز و ورودی‌های workflowهای کمکی در
.gitea/workflows/ باقی می‌مانند و اسکریپت‌ها را از مسیر جدید اجرا می‌کنند.
فایل‌های باینری همچنان در پوشهٔ firmware/ ریشهٔ مخزن قرار می‌گیرند.
تست ترتیب بوت از طریق Serial
workflow دستی init test از فایل .gitea/workflows/init-test.yml اجرا می‌شود.
رمز دستگاه را با نام RUTBS_PASSWORD در Actions → Secrets مخزن تعریف کنید؛
رمز در سورس یا متغیرهای عمومی قرار نمی‌گیرد. رانر به pyserial و دسترسی
به پورت /dev/ttyUSB0 نیاز دارد.
برای اجرای مستقیم، رمز را بدون نمایش در ترمینال دریافت کنید:
read -rs -p 'RUTBS password: ' RUTBS_PASSWORD
export RUTBS_PASSWORD
python3 deployment/serial/init_test.py
unset RUTBS_PASSWORD
برای پورت دیگر، گزینهٔ --port /dev/ttyUSB1 را اضافه کنید.
هنگام اجرای تست، برد باید در پرامپت U-Boot یعنی => باشد.
اسکریپت ابتدا با ارسال Enter پرامپت را تازه می‌کند و پس از تشخیص آن،
دستور res را برای ریبوت می‌فرستد؛ سپس مراحل بوت را به‌ترتیب بررسی می‌کند.
این تست باید پیام‌های انتخاب سطح دیباگ و فعال‌سازی کنسول را ببیند و
با workflow دیگری که همان پورت Serial را استفاده می‌کند هم‌زمان اجرا نشود.
از شروع تست، مهلت مشترک مراحل ۱۸۰ ثانیه است. تنها پس از ورود و دریافت
خروجی دقیق Linux از uname -s، پیام BOOT TEST: PASS و کد خروج صفر
برگردانده می‌شود. خطا کد خروج غیرصفر دارد. لاگ Serial با حذف رمز در
artifacts/boot.log ذخیره و حتی در شکست تست به‌صورت آرتیفکت بارگذاری می‌شود.