در این مقاله رسیدن به Bootloader اصلی حالت های مختلف Boot Fastboot و Fastbootd A/B Slots تحویل کنترل به Kernel

در دو مقاله قبل مسیر را از ROM داخل SoC تا Bootloaderهای اولیه در Qualcomm و MediaTek دنبال کردیم. در این مرحله DRAM و Storage قابل استفاده شده اند و سیستم دیگر در محیط بسیار محدود Boot ROM قرار ندارد. حالا نوبت Bootloader کامل تری است که باید تصمیم بگیرد دستگاه دقیقا با چه حالتی بالا بیاید و چه Imageهایی اجرا شوند. 

Boot ROM
   ↓
Early Bootloader
   ↓
Main Bootloader        ← موضوع این مقاله
   ↓
Linux Kernel
   ↓
Android

رسیدن به Bootloader اصلی، نقطه تصمیم گیری قبل از Linux

اصطلاح Bootloader در Android همیشه به یک فایل واحد اشاره نمی کند. قبل از رسیدن به این مرحله چند Boot Stage اجرا شده اند، اما چیزی که اینجا Bootloader اصلی می نامیم محیطی است که اطلاعات کافی برای انتخاب مسیر Boot، بررسی Imageهای Android و آماده کردن Kernel دارد.

در یک دستگاه امروزی این Bootloader معمولا چند کار اصلی انجام می دهد:

  • تشخیص حالت Boot موردنیاز دستگاه
  • انتخاب Slot مناسب در دستگاه های A/B
  • بررسی Imageها با Android Verified Boot
  • خواندن ساختار boot image و Imageهای مرتبط
  • قرار دادن Kernel، ramdisk و Device Tree در RAM
  • آماده کردن پارامترهای لازم برای Kernel
  • و در نهایت پرش به نقطه شروع Linux Kernel
در این مرحله
کنترل در اختیار Bootloader اصلی است. هنوز Linux اجرا نشده، اما Bootloader حالا می تواند تصمیم بگیرد دستگاه با چه Mode و چه مجموعه Imageهایی بالا بیاید.

یک Bootloader، چند مسیر متفاوت

همه روشن شدن های گوشی قرار نیست به Home Screen ختم شوند. Bootloader می تواند با توجه به وضعیت دستگاه، کلیدهای فشرده شده، فرمان قبلی سیستم یا اطلاعات ذخیره شده در پارتیشن های کنترلی، مسیر متفاوتی را انتخاب کند. 

Main Bootloader
   ├─ Normal Boot
   ├─ Recovery
   ├─ Fastboot
   └─ other vendor modes

Normal Boot، مسیر معمول بالا آمدن Android

در Normal Boot، Bootloader Slot مناسب را انتخاب می کند، Imageهای لازم را Verify می کند، Kernel و ramdisk را در RAM قرار می دهد و در نهایت کنترل را به Kernel می دهد. اگر همه چیز درست باشد کاربر فقط لوگوی Boot و بعد Android را می بیند، اما پشت صحنه چند تصمیم امنیتی و فنی قبل از اجرای Kernel گرفته شده است.

Recovery، یک محیط جدا از Android معمولی

Recovery برای نگهداری، Update و بازیابی دستگاه استفاده می شود. بسته به نسل دستگاه ممکن است Recovery پارتیشن مستقل خودش را داشته باشد یا اجزای آن داخل ramdiskهای Boot جدید قرار گرفته باشند.

نکته مهم این است که Recovery هنوز یک مسیر Boot کنترل شده است. Bootloader به جای محیط عادی Android، Kernel و ramdisk مناسب Recovery را انتخاب می کند.

Fastboot، وقتی Bootloader مستقیما با PC صحبت می کند

Fastboot یک Protocol و Mode در سطح Bootloader است. وقتی دستگاه وارد Fastboot می شود، Android معمولی اجرا نشده و Bootloader مستقیما از طریق USB با ابزار روی PC ارتباط برقرار می کند.

فرمان هایی مثل getvar، flash، boot و reboot از همین مسیر استفاده می کنند، البته اینکه هر فرمان اجازه اجرا داشته باشد به وضعیت Lock و سیاست سازنده بستگی دارد.

🛠 Fastboot یک سرنخ مهم برای عیب یابی است

اگر Fastboot بالا می آید می دانیم Boot ROM، Bootloaderهای اولیه، بخشی از Initialization سخت افزار و خود Bootloader اصلی تا حد قابل توجهی سالم هستند. این با حالتی مثل EDL یا BROM فرق دارد که بسیار پایین تر از Fastboot قرار می گیرد. 

Fastboot
   ↑
Main Bootloader
   ↑
Early Boot Stages
   ↑
PBL / BROM

Fastbootd، اسم مشابه ولی جای متفاوت

Fastbootd همان Fastboot داخل Bootloader نیست. Fastbootd در یک محیط Userspace مبتنی بر Recovery اجرا می شود و برای کار با ساختارهای جدیدتر Android مثل Dynamic Partitions مناسب است. 

Bootloader Fastboot
       ↓
boot / recovery environment
       ↓
Fastbootd
       ↓
logical partitions inside super

از دید کاربر هر دو با ابزار fastboot روی PC کار می کنند، اما محل اجرا و توانایی هایشان یکسان نیست.

A/B Slots، آپدیت بدون خراب کردن نسخه در حال اجرا

در دستگاه های A/B، بعضی پارتیشن های Boot critical دو نسخه دارند، برای نمونه Slot A و Slot B. وقتی سیستم روی A در حال اجرا است Update می تواند روی B نوشته شود. بعد از Reboot، Bootloader تلاش می کند Slot جدید را بالا بیاورد. 

Running Slot A
      ↓
Update writes Slot B
      ↓
Reboot
      ↓
Bootloader selects B
      ↓
Successful boot → mark B successful

اگر Boot جدید موفق نباشد، Boot control logic می تواند بر اساس سیاست دستگاه به Slot قبلی برگردد. این ساختار یکی از پایه های Seamless Update در Android است.

🔍 عمیق تر بشویم، GBL و تلاش Google برای استانداردتر کردن Bootloader

Google پروژه Generic Bootloader یا GBL را برای استانداردتر کردن بخش بیشتری از منطق Boot Android توسعه داده است. GBL می تواند وظایفی مثل تشخیص Boot Mode، انتخاب Slot، بارگذاری Imageها و Fastboot را در یک پیاده سازی مشترک تر انجام دهد.

در 2026 Buildهای رسمی Android 17 برای GBL منتشر شده اند، اما این به معنی حذف فوری تمام Bootloaderهای Vendor نیست. Firmware اولیه و بخش هایی از Platform Boot همچنان وابسته به SoC و سازنده باقی می مانند.

آخرین کار Bootloader، آماده کردن صحنه برای Linux

وقتی Mode و Slot مشخص شدند و بررسی های امنیتی با موفقیت انجام شدند، Bootloader اجزای لازم را در RAM قرار می دهد. این اجزا با نسل Android و ساختار دستگاه فرق می کنند، اما معمولا شامل Kernel، ramdiskهای لازم، Device Tree و پارامترهای Boot هستند. 

select mode / slot
      ↓
verify boot images
      ↓
load kernel
load ramdisk
load DTB / DTBO
prepare cmdline / bootconfig
      ↓
jump to Kernel entry

از لحظه پرش به Kernel entry نقش Bootloader عملا تمام می شود و Linux کنترل CPU را در دست می گیرد. مقاله های بعدی قبل از رسیدن به این پرش، خود زنجیره اعتماد و Imageهایی را که Bootloader بارگذاری می کند دقیق تر بررسی می کنند.

⭐ چیزی که از این مقاله باید بماند

Bootloader اصلی آخرین محیط تصمیم گیری پیش از Linux است. Mode، Slot و Imageهای Boot را انتخاب و بررسی می کند، سپس Kernel و اطلاعات موردنیازش را در RAM می گذارد و کنترل را به Linux تحویل می دهد.

واژه نامه کوتاه

Fastboot
Protocol و Mode در سطح Bootloader برای ارتباط مستقیم با PC.
Fastbootd
پیاده سازی Fastboot در Userspace و محیط Recovery برای کارهایی مثل Dynamic Partitions.
Recovery
محیط Boot جدا برای Update، Maintenance و Recovery.
A/B Slots
دو مجموعه از بعضی پارتیشن های Boot critical برای Update امن تر و امکان بازگشت.
GBL
Generic Bootloader، پروژه Google برای استانداردتر کردن منطق اصلی Bootloader Android.

منابع رسمی برای مطالعه بیشتر