پشتیبانی از صدای باکیفیت و زمان‌بندی CPU در نسخه ۷.۱ آساهی لینوکس برای

تصور کنید لبهٔ سخت‌افزاری اپل را در اختیار دارید، اما باید برای داشتن یک صدای ساده، سال‌ها منتظر بمانید. با انتشار نسخه ۷.۱ در ۳۰ ژوئن ۲۰۲۶، آساهی لینوکس (Asahi Linux) بالاخره خروجی صدای باکیفیت و زمان‌بندی هوشمند CPU را برای دستگاه‌های سری M3 به ارمغان آورد و گامی بلند در جهت عملکرد کامل این تراشه‌ها برداشت. این به‌روزرسانی در کنار سایر بهبودهای هسته قرار می‌گیرد، به‌طوری که برای مثال لینوکس ۷.۱ سرعت نوشتن داده‌های NTFS را نیز به‌طور چشمگیری افزایش داده است تا تجربه کاربری در محیط‌های چند-سیستمی بهبود یابد.

این پروژه سال‌ها بر روی این فرضیه شرط‌بندی کرده بود که اپل برای کاهش هزینه‌ها، طراحی داخلی سخت‌افزار را در نسل‌های مختلف ثابت نگه می‌دارد. طراحی و اعتبارسنجی پلتفرم‌های کامپیوتری و مدارات مجتمع بسیار گران و زمان‌بر است؛ بنابراین تیم آساهی پیش‌بینی می‌کرد که اپل از تغییرات ساختاریِ گسترده پرهیز کند. طبق گزارش‌های فنی تیم، این ریسک به‌طور کلی موفقیت‌آمیز بود و آن‌ها توانستند ویژگی‌های تراشه‌های M1 و M2 را با کمترین اصطکاک به M3 منتقل کنند؛ به‌جز بلوک‌های بزرگی مثل GPU که تقریباً در هر نسل تغییر می‌کنند. در حال حاضر، کاربران سیستمی را تجربه می‌کنند که تعادل بین توان مصرفی و عملکرد را بسیار بهینه‌تر از نسخه‌های پیشین مدیریت می‌کند.

بحران بوت در macOS 27

به نقل از گزارش asahilinux.org، انتشار بتای توسعه‌دهندگان macOS 27 Golden Gate باعث بروز یک باگ بحرانی شد. کاربران گزارش دادند که پارتیشن‌های لینوکس آن‌ها به‌طور کامل از منوی انتخاب بوت (Boot Picker) و اپلیکیشن Startup Disk ناپدید شده است، هرچند که این پارتیشن‌ها هنوز روی دیسک موجود بودند.

برای درک علت این اتفاق، باید بدانید که ابزارهای بوت اپل تنها با آنچه «نصب معتبر macOS» در یک کانتینر APFS تلقی کنند، کار می‌کنند. برای جلوگیری از اینکه کاربران مجبور شوند هر بار هنگام بوت دستورات پیچیده‌ای را در حالت Recovery اجرا کنند، نصب‌کننده‌ی آساهی یک کانتینر کوچک ۲.۵ گیگابایتی APFS می‌سازد. این کانتینر حاوی مقدار محدودی از macOS است تا ابزارهای اپل را متقاعد کند که با یک نصب واقعی مواجه‌اند و از m1n1 به عنوان کرنل خود استفاده می‌کند. این سازوکار از macOS 12 تا macOS 26 بدون تغییر کار می‌کرد. اپل حتی برخی باگ‌ها را در ابزارهای خود که هنگام بوت کردن باینری‌های خام (که کرنل‌های واقعی XNU نبودند) رخ می‌داد، برطرف کرده بود. این تلاش‌ها برای سازگاری با ساختارهای اپل، مشابه رویکردی است که در همگام‌سازی بومی دایرکتوری Home در کانتینرهای اپل برای رفع محدودیت‌های محیط‌های مجازی‌سازی به کار گرفته شد.

بررسی‌های توسعه‌دهنده‌ای به نام chaos_princess فاش کرد که اپل در macOS 27 یک «پرچم متادیتا» (Metadata Flag) جدید در APFS معرفی کرده است. نصب‌کننده‌ی macOS این متادیتا را پیش از ری‌بوت تنظیم می‌کند تا یک ولوم را به عنوان «قابل بوت» علامت‌گذاری کند. تا پیش از macOS 27، ابزارهای بوت اپل صرفاً این پرچم را نادیده می‌گرفتند. اما چون کانتینر کوچک آساهی فاقد این پرچم خاص بود، دیگر توسط Boot Picker شناسایی نمی‌شد.

تیم آساهی برای حل این مشکل سه راهکار ارائه داد:

• حالت جدید نصب‌کننده: این حالت به‌طور خودکار پرچم بوت را برای نصب‌های موجود فعال می‌کند. به کاربران بتای توسعه‌دهندگان macOS 27 توصیه شده است که نصب‌کننده را مجدداً اجرا کرده و گزینه «Fix macOS 27 boot picker compatibility» را انتخاب کنند.
• برنامه‌ی مستقل لینوکسی: ابزاری که توسط chaos_princess توسعه یافته و مستقیماً از داخل لینوکس اجرا می‌شود تا این مشکل را رفع کند. تیم در حال حاضر در جستجوی یک دور تست نهایی از طریق یک مخزن خاص گیت‌هاب است تا اطمینان حاصل کند ابزار قابل اعتماد است و پیش از استقرار خودکار، باعث تخریب سیستم‌فایل‌ها نمی‌شود.
• اعتبارسنجی جامعه: کاربران تشویق شده‌اند تا این اصلاحیه را تست کرده و نتایج را از طریق کانال‌های Matrix یا OFTC گزارش دهند، به‌ویژه اگر ولوم آساهی همچنان به عنوان هدف بوت قابل انتخاب باقی بماند.

شکست‌های توان و تغییرات فیرم‌ور

به گزارش تیم توسعه، macOS 27 فیرم‌ور SMC (کنترل‌کننده‌ی مدیریت سیستم) را به‌روز کرد. SMC مسئول مدیریت کلی تجهیزات جانبی و مدیریت باتری است. درایور منبع تغذیه در لینوکس برای دریافت داده‌های حیاتی با SMC ارتباط برقرار می‌کند، از جمله:

• وضعیت فعلی شارژ
• سطوح ولتاژ
• زمان باقی‌مانده تا تخلیه کامل باتری
• سلامت کلی باتری
• پیکربندی آستانه‌های شروع و توقف شارژ برای افزایش طول عمر باتری

اپل یکی از این رابط‌های مدیریت باتری را تغییر داد و خروجی آن را از یک عدد ۳۲ بیتی به یک تک‌بایت (Single Byte) تبدیل کرد. این تفاوت سه بایتی باعث شد درایور لینوکس دچار سردرگمی شود. در شرایط خاص، درایور داده‌ها را اشتباه تفسیر می‌کرد، باتری را «خراب» تشخیص می‌داد و برای محافظت از سیستم، دستور خاموش شدن اضطراری (Emergency Shutdown) صادر می‌کرد.

این مشکل در نسخه ۷.۰.۱۲ کرنل با شناسایی هر دو مدل ABI قدیمی و جدید برطرف شد و اکنون درایور منبع تغذیه قادر است با هر دو نسخه فیرم‌ور سازگار باشد.

گسترش پشتیبانی سخت‌افزاری M3

فعال‌سازی سخت‌افزارهای M3 به دلیل استفاده مجدد اپل از قطعات قدیمی، راحت‌تر از حد انتظار بود. تیم متوجه شد که کنترل‌کننده‌ی I2S (یک باس مبتنی بر I2C که برای داده‌های صوتی بهینه شده) و نوسان‌ساز کنترل‌شده‌ی عددی (NCO) که منبع ساعت پایدار برای نرخ‌های داده صوتی است، از زمان M1 تغییری نکرده‌اند.

علاوه بر این، اپل از تراشه‌های تقویت‌کننده‌ی بلندگو و هدفون یکسانی در تقریباً تمام دستگاه‌های Apple Silicon استفاده کرده است. این ثبات به chaos_princess اجازه داد تا پشتیبانی از صدای باکیفیت بلندگوها و جک هدفون را تنها با افزودن فایل‌های پیکربندی ساده به Devicetree و تنظیمات مربوط به asahi-audio و speakersafetyd فعال کند.

بهبودهای دیگر در M3 عبارتند از:

• مدیریت CPU: زمان‌بندی صحیح وظایف در معماری big.LITTLE که باعث می‌شود پردازش‌ها به‌طور هوشمند بین هسته‌های کم‌مصرف (Efficiency) و پرقدرت (Performance) توزیع شوند. همچنین تغییر فرکانس CPU اکنون فعال است، زیرا اپل از زمان M2 پایه روش کار این سیستم را تغییر نداده است. این امر اجازه می‌دهد هسته‌ها بر اساس بار کاری، فرکانس خود را بالا و پایین ببرند و در عین بهبود عملکرد، در انرژی صرفه‌جویی شود.
• حسگرها: پشتیبانی از حسگرهای سخت‌افزاری SMC از طریق تغییرات ساده در Devicetree اضافه شد، زیرا فیرم‌ور SMC در این دستگاه‌ها تفاوت Materialی ندارد.
• درایورهای اصلی: دسترسی به درایورهای فعال برای PCIe، WiFi، بلوتوث، NVMe، کیبورد و ترک‌پد اکنون فراهم است. بخش بزرگی از این کار مدیون تلاش‌های توسعه‌دهنده‌ای به نام Yureka است که زمان زیادی را صرف هک کردن m1n1 و لینوکس با استفاده از سخت‌افزار سری M3 کرد.

با وجود فعال بودن درایورهای اصلی، تیم اشاره کرد که هنوز راه زیادی تا فعال‌سازی رسمی و کامل پشتیبانی از M3 در نصب‌کننده آساهی (Asahi Installer) دارند.

مهندسی معکوس رمزگشای ویدیو

یکی از پیچیده‌ترین دستاوردها، پیشرفت در رمزگشای ویدئوی اپل (AVD) است. اکثر سخت‌افزارهای اپل از فیرم‌ورهای مبتنی بر RTKit یا لایه‌ی انتزاعی EPIC (که توسط DCP و AOP استفاده می‌شود) بهره می‌برند، اما AVD متفاوت است و از یک «چیز سوم محرمانه» استفاده می‌کند.

سخت‌افزار AVD در واقع یک هسته ARM Cortex-M3 است که واحدهای با عملکرد ثابت (Fixed-function units) را برای رمزگشایی AVC (H.264)، HEVC (H.265)، VP9 و AV1 (در SoCهای جدیدتر) کنترل می‌کند. به‌طور معمول، یک بلوک فیرم‌ور رابطی را برای XNU فراهم می‌کند تا به داده‌های ویدئویی اشاره کند. با این حال، اپل هم فیرم‌ور و هم توده‌ای از داده‌های پیکربندی را در داخل kext مربوط به AVD بسته‌بندی می‌کند. چون هر SoC نسخه متفاوتی از AVD دارد، ردیابی این آفست‌ها برای نصب‌کننده آساهی یک کابوس لجستیکی بود.

برای دور زدن این مشکل، تیم متوجه شد که هسته CM3 فیرم‌وری را که بارگذاری می‌کند، اعتبارسنجی نمی‌کند و صرفاً از Reset Vector اجرا می‌شود. توسعه‌دهنده‌ای به نام sofus یک فیرم‌ور سفارشی و بدون وضعیت (Stateless) برای AVD ساخت. این فیرم‌ور به جای مدیریت پیچیده، صرفاً:

• هندلرهای وقفه (Interrupt Handlers) را برای بلوک‌های سخت‌افزاری نصب می‌کند.
• مجموعه‌ی تنظیمات خاص هر مدل را اعمال می‌کند (با بازپخوانی نوشتن‌های MMIO که توسط XNU انجام می‌شد).

این رویکرد منجر به ایجاد یک درایور V4L2 فعال برای سخت‌افزار AVC شد که اکنون قابلیت‌های زیر را دارد:

• رمزگشایی ویدئوهای ۱۰ بیتی AVC.
• پشتیبانی از رزولوشن تا 4K.
• سازگاری با نرم‌افزارهایی که از V4L2 Request API استفاده می‌کنند.

تیم امیدوار است با بدون-وضعیت نگه داشتن فیرم‌ور و سپردن تجزیه داده‌های ویدئویی به کرنل و فضای کاربری، در نهایت از VA-API و Vulkan Video پشتیبانی کند. البته کار بر روی پشتیبانی از VP9، HEVC و AV1 و همچنین رفع نقص‌های خاص هر دستگاه پیش از انتشار عمومی همچنان ادامه دارد.

m1n1 نسخه ۱.۶.۰ و اهداف آینده

بروزرسانی m1n1 1.6.0 نقطه‌ی عطفی برای توزیع‌هاست؛ زیرا برای اولین بار در مرحله دوم ساخت (Stage 2) به زبان Rust نیاز دارد. پیش از این، Rust تنها برای پشتیبانی از Chainloading مورد نیاز بود.

مرحله اول m1n1 جایگزین کرنل XNU در ابزارهای بوت اپل می‌شود تا پارتیشن سیستم EFI را مونت کرده و مرحله دوم را بارگذاری کند. یک تغییر حیاتی در ۱.۶.۰، انتقال مقداردهی اولیه GPU به درون m1n1 است. این کار نیاز درایور کرنل به مدیریت اعداد ممیز شناور در داده‌های مقداردهی سخت‌افزاری اپل را حذف کرده و پیوندهای Devicetree را ساده‌تر می‌کند. در نتیجه، آخرین درایور GPU که به Mailing List کرنل لینوکس ارسال می‌شود، برای این مقداردهی اولیه به m1n1 متکی خواهد بود.

جزئیات فنی m1n1 1.6.0:

• پیاده‌سازی با Rust: کد تحلیل Apple Device Tree به Rust منتقل شده است. از آنجایی که این کد هدف aarch64-none-softfloat دارد و از no_std Rust استفاده می‌کند، کاربران می‌توانند برای ساخت Core و Alloc بدون نیاز به Toolchain کامل softfloat، گزینه BUILDSTD=1 را به make پاس دهند.
• بهبودهای M3: افزودن پشتیبانی از کنترل‌کننده‌ی SPMI و مقداردهی اولیه PCIe.
• عیب‌یابی: امکان تونل کردن UART سخت‌افزاری SoC مستقیماً روی DebugUSB با استفاده از kisd که مشابه عملکردهای Central Scrutiniser است.

تیم اکنون در حال آماده‌سازی برای پشتیبانی از M4 و A18 Pro (MacBook Neo) است. این مسیر شامل مدیریت بهتر حالت‌های بوت غیر-macOS اپل و یکپارچه‌سازی متادیتای دامنه‌های توان (Power Domain) جدید است که در Apple Device Tree یافت شده است.

این پیشرفت سریع تأیید می‌کند که توانایی جامعه در مهندسی معکوس سیلیکون اپل سریع‌تر از همیشه است. با این حال، تیم آساهی هشدار می‌دهد که نصب بتای توسعه‌دهندگان روی دستگاه‌های اصلی ریسک بالایی دارد، زیرا آپدیت‌های فیرم‌ور جهانی تقریباً دائمی هستند و بازگشت از آن‌ها تنها از طریق DFU Restore ممکن است. تیم آساهی سخت‌افزارهای قربانی (Sacrificial Hardware) را برای تست این آپدیت‌ها نگه می‌دارد تا کاربران مجبور نباشند سخت‌افزارهای گران‌قیمت و داده‌های مهم خود را به خطر بیندازند.

گام بعدی شما

• اگر از بتای macOS 27 استفاده می‌کنید، نصب‌کننده آساهی را مجدداً اجرا کرده و گزینه «Fix macOS 27 boot picker compatibility» را انتخاب کنید.
• برای تست ابزار جدید رفع مشکل بوت، به مخزن گیت‌هاب chaos_princess مراجعه کنید.
• در صورت استفاده از M3، درایورهای جدید m1n1 را برای تجربه پایداری بیشتر در مدیریت توان به‌روزرسانی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است؛ اثر این تغییرات بر عملکرد گرافیکی در گزارش‌های بعدی بررسی خواهیم کرد.