امبدد لینوکس – قسمت چهاردهم – Bootloader

از قسمت قبل که در آن با انواع روش‌های بیلد کردن، کراس کامپایل و چالش‌های آن آشنا شدیم و حال قرار است با Bootloader آشنا شویم، زمان زیادی می‌گذرد امیدواریم عذرخواهی ما رو بابت این تأخیر و فاصله پیش‌آمده پذیرا باشید. در این مدت دوستان زیادی لطف کردند و با پیام‌های خودشان و پیگیری باعث دلگرمی شدند. امیدواریم در کنار هم باز این مقالات را ادامه بدهیم و باهم به آخرین مقاله فصل آخر برسیم.

فصل سوم: Bootloader، یار قدیمی

همه ما میدانیم (یا بدونید) خیلی از میکروکنترلرها مثل خانواده‌های STM32، بوت لودر Bootloader در ROM خودشان دارند. خیلی از ما هم ممکنه در پروژه‌های میکروکنترلری از بوت لودر (Bootloader) استفاده کرده باشیم. اما داستان در اینجا یکم متفاوت‌تر هست. اگر در پروژه‌های میکروکنترلری یه وقتایی خوب بود باشه واسه یه سری کارها مثل آپدیت کردن فریمور اینجا واجبه که باشه! چرا؟

چه میکنه این Bootloader

بوت لودر Bootloader دومین بخش از امبدد لینوکس ما میشه و کرنل سیستم‌عامل رو واسه ما لود میکنه. در حقیقت Bootloader دو تا وظیفه داره: راه‌اندازی اولیه سخت‌افزارها در حدی که بشه سیستم‌عامل رو اجرا کرد و بعدش اجرای سیستم‌عامل. بعد از روشن شدن پردازنده و یا ریست شدن آن سیستم ما خیلی منابع کمی داره هنوز نه رم خارجی راه‌اندازی شده، نه حافظه‌های خارجی مثل NAND فلش یا کارت حافظه و نه سایر سخت‌افزارها! درواقع فقط یک هسته از پردازنده هست و یک حافظه داخلی و ثابت همون پردازنده! به خاطر همین فرآیند بوت شدن شامل چند مرحله میشه که در هر مرحله منابع سخت‌افزاری جدیدی راه‌اندازی میشه و به سیستم اضافه میشه.

آخرین کار آماده سازی محیط لازم و اجرای کرنل هست.

توالی بوت

قدیما که همه‌چیز گل‌وبلبل بود (نبودا ولی همه میگن ما هم گفتیم فقط!) معمولاً از حافظه‌های NOR Flash استفاده می‌شد و این حافظه‌ها رو مستقیم مپ می‌کرد، فرآیند بوت خیلی ساده بود ولی با پردازنده‌ها و حافظه‌های الان فرآیند بوت چندمرحله‌ای شده و خیلی وابسته به SoC هست ولی معمولاً مراحلی می‌شه که در ادامه می‌گوییم.

مرحله یک: اجرای کد ROM

به نظرتون وقتی‌که پردازنده تازه روشن میشه یا بلافاصله بعد از ریست شدنش، چه کدی باید لود بشه و از کجا؟ دقت کنید هنوز نه رم خارجی داریم نه حافظه‌های خارجی راه‌اندازی شدن. اولین کد از حافظه فقط خواندنی خود SoC اجرا می‌شه که در زمان تولید در این حافظه ذخیره‌شده. از اونجایی که راه‌اندازی DRAM ها خیلی به مدل DRAM وابسته هست، راه‌اندازی این حافظه‌ها در کد ROM نیست و این کد فقط می‌تونه از SRAM استفاده کنه که نیازی به کنترلر نداره.

اگه مشخصات SoC ها رو دیده باشید همشون یه حافظه SRAM دارن با ظرفیت چند کیلو تا چند ده کیلوبایت. وجود این حافظه دقیقاً واسه همین هست. معمولاً کد ROM این توانایی رو داره که یک مقدار مشخص کد رو از یک محل مشخص در یک حافظه خارجی مشخص توی SRAM لود کنه و اگه این کد پیدا نشه معمولاً میتونه یک استریم رو از USB یا USART یا Ethernet بخونه. حالت آخر معمولاً برای نوشتن کد در حافظه‌های خارجی به هنگام تولید کاربرد داره.

به این مشخص‌ها دقت کنید، اطلاعات کشف کردنی نیستن! اطلاعات دیتاشیتی هستن و بسته به هر پردازنده یا شرکت تولیدکننده متفاوت هستن. مثلاً پردازنده‌های راک چیپ Rock Chip اول سکتور 0x40 کارت حافظه SD رو چک می‌کنند بعدش eMMC بعدش SPI Flash و آگه هیچ کدوم فایل idbloader.img رو نداشت میرن تو مؤدی که از طریق USB میشه حافظه‌های خارجی متصل به پردازنده رو پروگرام کرد.

یا پردازنده‌های سیتارا تگزاس TI Sitara اول سراغ NAND Flash میرن بعدش SPI Flash بعدش SD و درنهایت eMMC. معمولاً چون حجم SRAM خیلی کم هست کد ROM نمی‌تونه یک بوت لودر Bootloader کامل رو توش کپی کنه و یک لودر مقدماتی که بش Secondary Program Loader یا به‌اختصار SPL میگن رو لود میکنه توی SRAM و بقیه کارها رو میسپاره به اون.

SPL into SROM

مرحله دوم: SPL

SPL کنترلر حافظه رو راه‌اندازی میکنه و Tertiary Program Loader (TPL) رو توی حافظه SDRAM کپی می‌کنه و کار رو به اون می‌سپاره. SPL ممکنه اپشن سورس باشه و یا به‌صورت یه فایل باینری از طرف شرکت سازنده SoC بهتون داده بشه.

مرحله سوم: TPL

آری رسد سیستم به‌جایی که بتواند یک Bootloader کامل را اجرا کند! این Bootloader کامل میتونه گزینه‌های بسیاری باشه ولی چیزی که مرسوم‌تر و پرکاربردتر هست U-Boot هست. این بوت لودرها Bootloader معمولاً یک خط فرمان Command Line ساده دارن که با آن‌ها یک سری کارها رو میشه انجام داد. عکس زیر نشون می‌ده که در مرحله سه چه اتفاق‌هایی می‌افته. معمولاً در پایان مرحله سه اثری از Bootloader نیست.

از Bootloader تا کرنل

وقتی‌که Bootloader سیستم رو داره میسپاره دست کرنل یک سری اطلاعات رو به کرنل می‌ده، این اطلاعات میتونه چیزهای مختلفی مانند machine number یا kernel command line و … باشه. پردزانده‌های ARM که بیشتر موردبحث و استفاده ما هستند امروزه تمام اطلاعات رو در غالب Device Tree به کرنل تحویل می‌دن. با Device Tree در فصل بعد که به کرنل می‌پردازیم آشنا خواهید شد. به‌پایان این بخش رسیدیم در بخش بعدی با یوبوت U-Boot آشنا می‌شیم و اون رو برای بردهامون Compile می‌کنیم.