paint-brush
Donanım Yazılımının Sırları Yolculuğu: BIOS/UEFI'den İşletim Sistemineile@tristejoursoir
476 okumalar
476 okumalar

Donanım Yazılımının Sırları Yolculuğu: BIOS/UEFI'den İşletim Sistemine

ile Aleksandr Goncharov20m2024/08/22
Read on Terminal Reader

Çok uzun; Okumak

Geleneksel BIOS'tan modern UEFI aygıt yazılımına evrimi keşfedin, önyükleme dizilerinin nasıl yönetildiğini anlayın ve önyükleme hizmetleri ile çalışma zamanı hizmetlerinin rollerini keşfedin. İşletim sistemi önyükleme yükleyicilerinin karmaşıklıklarına dalın ve aygıt yazılımının artık gelişmiş özellikleri ve uygulamaları nasıl desteklediğini görün.
featured image - Donanım Yazılımının Sırları Yolculuğu: BIOS/UEFI'den İşletim Sistemine
Aleksandr Goncharov HackerNoon profile picture
0-item
1-item


Bilgisayarınızın güç düğmesine bastığınız anda ne olduğunu hiç merak ettiniz mi? Ekranınız aydınlanmadan önceki o kısa duraklamanın ardında karmaşık bir dizi işlem gerçekleşmektedir. Bu makale , önyükleme işlemi sırasında farklı bileşenlerin nasıl etkileşime girdiğini inceleyerek, aygıt yazılımının büyüleyici dünyasına dalacaktır.


Bu bağlantıları anlayarak, sisteminizi hayata geçiren temel unsurlar hakkında daha net bir resim elde edeceksiniz. Öncelikli odak noktamız Intel x86 mimarisi olacak, ancak birçok ilke diğer mimarilerde de geçerlidir.


Serimizin ilk bölümünü kaçırdıysanız, yetişmek için buraya tıklayın . Şimdi, donanım yazılımının ardındaki gizemleri ortaya çıkaralım.

İçindekiler:

  • Tanımlar
  • Genel Ürün Yazılımı Mimarisi
  • Birinci Aşama Önyükleyici (FSBL)
    • BIOS (POST aşaması)
    • UEFI Platform Başlatma (PI)
    • çekirdek önyükleme
    • Diğer çözümler
  • İkinci Aşama Önyükleyici (SSBL)
    • BİYOGRAFİ
    • UEFİ
  • İşletim Sistemi Önyükleyicisi


Tanımlar

  • Sabit yazılım : Donanıma yerleştirilen, düşük düzeyde kontrol sağlayan ve donanımın doğru şekilde çalışmasını ve diğer sistem bileşenleriyle etkileşime girmesini sağlayan özel bir yazılım türüdür.


  • Temel Giriş/Çıkış Sistemi (BIOS) : Platform açıldıktan sonra donanım başlatmadan sorumlu eski bir aygıt yazılımı (aslen IBM PC için yaratılmıştır). Günümüzde, genellikle belirsiz bir şekilde tam aygıt yazılımı seti olarak anılır.


  • Önyükleyici : Bir bilgisayarı başlatmaktan sorumlu olan aygıt yazılımı için genel bir ad. BIOS yerine modern bir kavram olarak kullanılır, genellikle işlemciyi ve yonga setini başlatmak için önyükleme kodu içeren bir çerçeve ve üçüncü taraflara (örneğin, anakart geliştiricileri) platforma özgü başlatmayı gerçekleştirmeleri için arayüzler sağlar.


  • Yük : Önyükleyici çıktığında çalıştırılacak bir yazılım. İkinci aşama bir önyükleyici, İşletim Sistemi, BIOS/UEFI uygulaması vb. olabilir. Genellikle aygıt yazılımı tasarımına göre önyükleme akışını halleder.


  • BIOS ve önyükleyici terimlerinin kullanımı kafa karıştırıcı olabilir, çünkü anlamları bağlama göre değişir. Ancak, birisi firmware , BIOS veya önyükleyiciden bahsettiğinde, genellikle işletim sistemi ile donanım arasında çalışan tüm firmware setinden bahsediyor demektir.


  • EFI ve UEFI : Genişletilebilir Ürün Yazılımı Arayüzü (EFI), Intel tarafından geliştirilen orijinal spesifikasyondu. Birleşik Genişletilebilir Ürün Yazılımı Arayüzü (UEFI) , UEFI Forumu tarafından orijinal spesifikasyonu standartlaştırmak ve genişletmek için oluşturulan EFI'nin halefidir. Çoğu durumda, EFI ve UEFI birbirinin yerine kullanılır.

Genel Ürün Yazılımı Mimarisi

Ürün yazılımı bileşenlerinin nasıl etkileşime girdiğini anlamak için, tüm mimariyi tüm bağlı parçalarıyla birlikte inceleyeceğiz. Aşağıdaki diyagramda gösterilen yürütme akışı, Birinci Aşama Önyükleyicisinin bir parçası olan sıfırlama vektöründen başlar. Buradan, çeşitli ürün yazılımı aşamalarından geçer:



Donanım yazılımı veya BIOS genellikle iki ana bölüme ayrılabilir ve bunlar arasında genellikle asgari bir arayüz bulunur:


  1. Donanım Başlatma : Sistemin donanım bileşenlerinin başlatılmasından sorumludur.
  2. İşletim Sistemi ve Kullanıcı Arayüzü : İşletim sistemine ve kullanıcıya gerekli arayüzleri sağlar.


Platform aygıt yazılımının tasarımı, donanım başlatma ve önyükleme işlevselliğini birleştiren monolitik olabilir veya modüler ve aşamalı bir önyükleme akışını takip edebilir. Tasarım seçimi sistem gereksinimlerine bağlıdır ve belirli cihazlar için tercih edilebilir.


Aşağıdaki diyagram, farklı donanım yazılımı bileşenlerinin nasıl etkileşime girdiğini ve önyükleme sürecini desteklemek için birlikte nasıl kullanılabileceğini göstermektedir (oklar yürütme sırasını göstermektedir):



Bu diyagramlar şimdi karmaşık görünüyorsa endişelenmeyin. Bu makaleyi okuduktan sonra tekrar inceleyin, daha net olacaklar.

Birinci Aşama Önyükleyici (FSBL)

Bu donanım yazılımı parçası, bilgisayarları ve gömülü sistemleri asgari donanım başlatmaya odaklanarak başlatmak için tasarlanmıştır: yalnızca kesinlikle ihtiyaç duyulanı yapmak, ardından işletim sistemini başlatmak için kontrolü İkinci Aşama Önyükleyiciye geçirmek. FSBL, flash çip dışındaki depolama ortamlarından işletim sistemleri yüklemez. Yalnızca altta yatan donanımı başlattığı ve sabit diskler, SSD'ler veya USB flash sürücüler gibi önyükleme ortamlarını işlemediği için, bir işletim sistemini gerçekten başlatmak için başka bir yazılım parçası gerekir.


FSBL'nin Temel Sorumlulukları :


  1. CPU : 16-bit Gerçek Moddan 32-bit Korumalı Moda geçiş ( not : BIOS durumunda Sanal 8086 modunda ).
  2. Önbellek Kullanımı : C ortamı için Önbellek-RAM olarak yapılandırmak üzere FSP-T'yi çağırma.
  3. Hata Ayıklama Bağlantı Noktası : Yapılandırılmış hata ayıklama bağlantı noktasını, karta özgü başlatma yöntemlerini çağırarak başlatma.
  4. Bellek Başlatma : Sistemin ana belleğini başlatmak ve önemli sistem belleği bilgilerini kaydetmek için FSP-M'yi çağırma.
  5. GPIO : Harici cihazlarla arayüz oluşturmak için Genel Amaçlı Giriş/Çıkış (GPIO) pinlerini yapılandırma.
  6. Silicon : Erken platform başlatma işlemini gerçekleştiriyor ve yonga seti, CPU ve IO denetleyicisi başlatma işlemini tamamlamak için FSP-S'yi kullanıyor.
  7. PCI Numaralandırması : PCI aygıtlarını numaralandırma ve bellek adresleri ve IRQ'lar gibi kaynakları tahsis etme.
  8. Yük Hazırlığı : Yüke geçirilmesi gereken hazırlık bilgilerini (coreboot tabloları, HOB'lar) içeren SMBIOS ve ACPI tablolarının kurulması.
  9. Yükleme ve Devir : Yükleme ve kontrolün faydalı yüke aktarılması.

BIOS (POST Aşaması)

Bilgisayarcılığın ilk zamanlarında, açık kaynaklı yazılımlar yaygın olarak popüler değildi ve çoğu BIOS uygulaması tescilliydi. BIOS POST kaynak kodu sağlayan yalnızca birkaç açık çözüm mevcuttur, örneğin Super PC/Turbo XT BIOS ve GLaBIOS . Bu projeler IBM 5150/5155/5160 sistemlerinde ve çoğu XT klonunda çalışmak üzere tasarlanmıştı.


Ancak, OpenBIOS ve SeaBIOS gibi daha iyi bilinen açık kaynaklı BIOS uygulamaları, çıplak donanımda çalışmak üzere tasarlanmadıkları için donanım başlatma işlemi gerçekleştirmezler. Ancak İkinci Aşama Önyükleyiciler olarak yaygın olarak kullanılırlar ve QEMU ve Bochs gibi sanal ortamlarda doğal olarak çalışırlar.


Her durumda, bu erken BIOS'larla doğrudan çalışmanız veya bunların ayrıntılarına derinlemesine inmeniz gerekme ihtimali çok düşüktür. Ancak keşfetmekle ilgileniyorsanız, belirtilen depolar iyi bir başlangıç noktasıdır.


Mevcut geliştirme eğilimlerine bakıldığında, tescilli BIOS çözümlerinin devam eden bir geliştirme süreci olmadığı ve bu tür projelerin modern alternatifler karşısında geçersiz hale geldiği görülmektedir.

UEFI Platform Başlatma (PI)

Önyükleme süreci, bir sonraki şekilde soldan başlayıp sağa doğru ilerleyen aşamalı bir akışı takip eder. Platform önyükleme sürecinin zaman çizelgesi, sarı kutularla gösterildiği gibi aşağıdaki ifadelere bölünmüştür:



  • Güvenlik (SEC) : Sıfırlama vektöründen sonraki ilk aşamadır, birincil işlevi Geçici RAM'i (CPU Cache-As-RAM veya SRAM) ayarlamak.
  • Ön EFI Başlatma (PEI) : Bu faz , Ön EFI Başlatma Modülleri (PEIM'ler) adı verilen özel sürücüleri dağıtır. Bu modüller, CPU ve yonga setini yapılandırma ve ana belleği (DRAM) ayarlama gibi temel donanım başlatma işlemlerini gerçekleştirir.
  • Sürücü Yürütme Ortamı (DXE) : Bu aşamada, sistemin geri kalan başlatma işlemleri gerçekleştirilir. DXE aşaması, UEFI hizmetleri sağlar ve sistemin çalışması için gerekli çeşitli protokolleri ve sürücüleri destekler.
  • Önyükleme Aygıtı Seçimi (BDS) : Bu aşama, platform önyükleme politikasını uygular, önyükleme sırasını belirler ve uygun önyükleme aygıtını/yükleyiciyi seçer.
  • Geçici Sistem Yüklemesi (TSL) : Bu aşamada sistem, işletim sistemini hazırlamak için UEFI hizmetlerini kullanarak uygulamaları çalıştırır. UEFI ortamından işletim sistemine geçişi içerir ve ExitBootServices() çağrısıyla sonlanır.
  • Çalışma Zamanı (RT) : Bu aşamada işletim sistemi tam olarak çalışır durumdadır ve sistemi kendi kontrolü altında yönetmektedir.
  • After Life (AL) : Bu aşama, donanımın veya işletim sisteminin çöktüğü/kapandığı/yeniden başlatıldığı senaryolarla ilgilenir. Ürün yazılımı kurtarma eylemleri deneyebilir, ancak UEFI PI Belirtimi bu aşama için belirli gereksinimleri veya davranışları tanımlamaz.


Bu süreç ve yürütme aşamaları UEFI Platform Başlatma (PI) Spesifikasyonu tarafından ele alınır. Ancak, önceki belgenin bir parçası olmayan ve UEFI Spesifikasyonu'nda açıklanan UEFI Arayüzü (resimde kalın mavi çizgiyle gösterilmiştir) de vardır. UEFI'nin adları ve sık kullanımı kafa karıştırıcı olabilse de, bu iki belgenin farklı odak noktaları vardır:


  • UEFI PI Özellikleri : Düşük seviyeli aygıt yazılımı bileşenleri arasındaki arayüzlere odaklanır ve bu modüllerin platformu başlatmak için nasıl etkileşime girdiğini ayrıntılarıyla açıklar.


  • UEFI Spesifikasyonu : İşletim Sistemi (OS) ile aygıt yazılımı arasındaki etkileşim için arayüzleri tanımlar. Bu , İkinci Aşama Önyükleyici bağlamında daha ayrıntılı olarak ele alınacaktır. UEFI Spesifikasyonunun PI Spesifikasyonuna dayandığını unutmayın.


Esasen, her iki şartname de arayüzlerle ilgilidir, ancak farklı düzeylerde. Ayrıntılı bilgi için, her iki şartnameye de UEFI Forum web sitesinden erişebilirsiniz.


UEFI PI başlangıçta, birinci aşama ve ikinci aşama önyükleyiciler arasındaki ayrımı dikkate almadan birleşik bir aygıt yazılımı çözümü olarak tasarlanmıştı. Ancak, UEFI'yi Birinci Aşama Önyükleyici olarak adlandırdığımızda, SEC , PEI ve erken DXE aşamalarını içerir. DXE'yi erken ve geç aşamalar olarak ayırmamızın nedeni, başlatma sürecindeki farklı rolleridir.


Erken DXE aşamasında, sürücüler genellikle temel CPU/PCH/kart başlatma işlemini gerçekleştirir ve ayrıca DXE aşamasını platforma özgü donanımdan izole etmeye yardımcı olan DXE Mimari Protokolleri (AP'ler) üretir. AP'ler platforma özgü ayrıntıları kapsülleyerek geç DXE aşamasının donanım özelliklerinden bağımsız olarak çalışmasına olanak tanır.



Çekirdek önyükleme

Coreboot'un nasıl çalıştığına dair detaylı makaleler yakında geliyor. Sosyal medyamı takip edin – çok yakında yayınlanacaklar!

Diğer çözümler

  • Intel Slim Bootloader (SBL) : yalnızca çekirdek donanım bileşenlerinin başlatılmasını sağlayan ve ardından yükü yükleyen saf birinci aşama önyükleyici. Ancak, yalnızca Intel x86 platformlarında çalışır ve AMD x86 veya diğer mimarileri desteklemez.
  • Das U-Boot : hem birinci hem de ikinci aşama önyükleyici. Ancak, platformun x86 sıfırlama vektöründen doğrudan önyükleme desteği (çıplak mod olarak bilinir) diğer aygıt yazılımlarına kıyasla sınırlıdır. Gömülü sistemlerde ve ARM tabanlı aygıtlarda daha popülerdir. İkinci aşama önyükleyici olarak U-Boot, UEFI'nin bir alt kümesini uygular ancak gömülü sistemlere odaklanır.

İkinci Aşama Önyükleyici (SSBL)

İlk donanım kurulumu tamamlandıktan sonra ikinci aşama devreye girer. Birincil rolü , işletim sistemi ile platform donanım yazılımı arasında bir yazılım arayüzü kurmak ve işletim sisteminin sistem kaynaklarını yönetebilmesini ve donanım bileşenleriyle etkileşime girebilmesini sağlamaktır.


SSBL, donanım farklılıklarını mümkün olduğunca gizlemeyi , donanım düzeyindeki arayüzlerin çoğunu ele alarak işletim sistemi ve uygulama geliştirmeyi basitleştirmeyi hedefler. Bu soyutlama, geliştiricilerin altta yatan donanım farklılıkları hakkında endişelenmeden daha yüksek düzeyli işlevlere odaklanmasını sağlar.


SSBL'nin Temel Sorumlulukları :


  1. Platform Bilgi Alma : Birinci Aşama Önyükleyiciden bellek eşlemesi, SMBIOS, ACPI tabloları, SPI flash vb. dahil olmak üzere platforma özgü bilgileri alır.


  2. Platform Bağımsız Sürücüleri Çalıştırın : SMM, SPI, PCI, SCSI/ATA/IDE/DISK, USB, ACPI, ağ arayüzleri vb. için sürücüler içerir.


  3. Hizmet Uygulaması (diğer adıyla Arayüz) : İşletim sistemi ile donanım bileşenleri arasındaki iletişimi kolaylaştıran bir dizi hizmet sağlar.


  4. Kurulum Menüsü : Sistem yapılandırması için bir kurulum menüsü sunar ve kullanıcıların önyükleme sırası, donanım tercihleri ve diğer sistem parametreleriyle ilgili ayarları düzenlemelerine olanak tanır.


  5. Önyükleme Mantığı : Mevcut önyükleme ortamından yükü (muhtemelen işletim sistemini) bulup yükleme mekanizması.

BİYOGRAFİ

BIOS'taki arayüz BIOS hizmetleri/işlevleri/kesinti çağrıları olarak bilinir. Bu işlevler donanım erişimi için bir dizi rutin sağlar, ancak sistemin belirli donanımında nasıl yürütüldüklerine dair belirli ayrıntılar kullanıcıdan gizlenir.


16-bit Gerçek Mod'da , INT x86 montaj dili talimatı aracılığıyla bir yazılım kesintisi çağırarak bunlara kolayca erişilebilir. 32-bit Korumalı modda , segment değerlerinin işlenme şeklinin farklı olması nedeniyle neredeyse tüm BIOS hizmetleri kullanılamaz.




Bu arayüzün nasıl kullanılabileceğine dair bir örnek olarak , Silindir Kafalı Sektör (CHS) adreslemesini kullanarak sektör tabanlı sabit disk ve disket okuma ve yazma hizmetleri sağlayan Disk Hizmetleri'ni ( INT 13h ) ele alalım. 2 sektörü (1024 bayt) okumak ve bunları 0x9020 bellek adresine yüklemek istediğimizi varsayalım, o zaman aşağıdaki kod çalıştırılabilir:


 mov $0x02, %ah # Set BIOS read sector routine mov $0x00, %ch # Select cylinder 0 mov $0x00, %dh # Select head 0 [has a base of 0] mov $0x02, %cl # Select sector 2 (next after the # boot sector) [has a base of 1] mov $0x02, %al # Read 2 sectors mov $0x00, %bx # Set BX general register to 0 mov %bx, %es # Set ES segment register to 0 mov $0x9020, %bx # Load sectors to ES:BX (0:0x9020) int $0x13 # Start reading from drive jmp $0x9020 # Jump to loaded code


Bu servisin SeaBios'ta nasıl yazıldığını merak ediyorsanız src/disk.c dosyasına bakın.

BOOT aşaması

  • Aygıtlardan ilk 512 baytlık sektörü (sektör sıfır) okuyarak önyüklenebilir bir aygıt (sabit disk, CD-ROM, disket vb. olabilir) aramaya başlar.


  • BIOS'taki önyükleme dizisi, bulduğu ilk geçerli Ana Önyükleme Kaydı'nı (MBR) bilgisayarın fiziksel belleğine 0x7C00 fiziksel adresine yükler (İpucu: 0x0000:0x7c00 ve 0x7c0:0x0000 aynı fiziksel adresi ifade eder).


  • BIOS kontrolü yükün ilk 512 baytına aktarır. Tüm yük kodunu içeremeyecek kadar küçük olan bu yüklenen sektör , yükün geri kalanını önyüklenebilir aygıttan yükleme amacına hizmet eder. Bu noktada, yük BIOS tarafından ortaya çıkarılan arayüzü kullanabilir.


BIOS spesifikasyonlarının ilk günlerde var olmaması dikkat çekicidir. BIOS fiili bir standarttır - 1980'lerde gerçek IBM PC'lerde çalıştığı şekilde çalışır. Diğer üreticiler sadece tersine mühendislik uyguladı ve IBM uyumlu BIOS'lar üretti. Sonuç olarak, BIOS üreticilerinin yeni BIOS işlevleri icat etmesini veya çakışan işlevlere sahip olmasını engelleyecek bir düzenleme yoktu.

Birleşik Genişletilebilir Ürün Yazılımı Arayüzü (UEFI)

Daha önce de belirtildiği gibi, UEFI'nin kendisi yalnızca bir spesifikasyondur ve birçok uygulaması vardır. En yaygın kullanılanı, UEFI ve PI spesifikasyonlarının açık kaynaklı bir referans uygulaması olan TianoCore EDK II'dir . EDKII tek başına tam işlevli bir önyükleme yazılımı oluşturmak için yeterli olmasa da, çoğu ticari çözüm için sağlam bir temel sağlar.


Farklı Birinci Aşama Önyükleyicileri desteklemek ve bir UEFI arayüzü sağlamak için UEFI Payload projesi kullanılır. Sistemi UEFI ortamına hazırlamak için yapılan ilk kuruluma ve önyükleme yazılımı tarafından sağlanan platform bilgilerine güvenir.


UEFI Payload, platformdan bağımsız olacak şekilde tasarlanmış DXE ve BDS aşamalarını kullanır. Farklı platformlara uyum sağlayabilen genel bir payload sunar. Çoğu durumda, herhangi bir özelleştirme veya platforma özgü ayarlama gerektirmez ve First-Stage Bootloader'dan platform bilgilerini tüketerek olduğu gibi kullanılabilir.


UEFI Payload'un Varyantları :


  1. Eski UEFI Yükü : Gerekli uygulamaya özgü platform bilgilerini çıkarmak için bir ayrıştırma kitaplığı gerektirir. Önyükleyici API'sini güncellerse, yükün de güncellenmesi gerekir.



  2. Evrensel UEFI Yükü : Yürütülebilir ve Bağlanabilir Biçim (ELF) veya Düz Görüntü Ağacı'nı (FIT) ortak bir görüntü biçimi olarak kullanarak Evrensel Ölçeklenebilir Ürün Yazılımı (USF) Spesifikasyonunu takip eder. Bunları kendisi ayrıştırmak yerine, yük girişinde Elden Çıkarma Bloklarını (HOB'ler) almayı bekler.


Legacy UEFI Payload iyi çalışırken, EDK2 topluluğu endüstriyi Evrensel UEFI Payload'a doğru kaydırmaya çalışıyor. Payload'lar arasındaki seçim, donanım yazılımı bileşenlerinize bağlıdır. Örneğin, Legacy Payload'ı benim yamam olmadan Slim Bootloader'da SMM desteğiyle çalıştırmak mümkün değildir. Öte yandan, Universal Payload'ı coreboot ile kullanmak, coreboot tablolarını HOB'lara çevirmek için bir shim katmanı gerektirir; bu özellik yalnızca StarLabs EDK2 çatalında mevcuttur.

Arayüz

Her UEFI uyumlu sistem, UEFI ortamında çalışan her koda (sürücüler, uygulamalar, işletim sistemi yükleyicileri) geçirilen bir Sistem Tablosu sağlar. Bu veri yapısı, bir UEFI yürütülebilir dosyasının ACPI , SMBIOS ve bir dizi UEFI hizmeti gibi sistem yapılandırma tablolarına erişmesine olanak tanır.



Tablo yapısı MdePkg/Include/Uefi/UefiSpec.h dosyasında açıklanmıştır:


 typedef struct { EFI_TABLE_HEADER Hdr; CHAR16 *FirmwareVendor; UINT32 FirmwareRevision; EFI_HANDLE ConsoleInHandle; EFI_SIMPLE_TEXT_INPUT_PROTOCOL *ConIn; EFI_HANDLE ConsoleOutHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *ConOut; EFI_HANDLE StandardErrorHandle; EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr; // // A pointer to the EFI Runtime Services Table. // EFI_RUNTIME_SERVICES *RuntimeServices; // // A pointer to the EFI Boot Services Table. // EFI_BOOT_SERVICES *BootServices; UINTN NumberOfTableEntries; EFI_CONFIGURATION_TABLE *ConfigurationTable; } EFI_SYSTEM_TABLE;


Hizmetler şu türleri içerir: Önyükleme Hizmetleri , Çalışma Zamanı Hizmetleri ve Protokoller tarafından sağlanan hizmetler .


UEFI, UEFI Protokollerini ayarlayarak aygıta erişimi soyutlar. Bu protokoller, işlev işaretçileri içeren veri yapılarıdır ve diğer modüllerin bunları bulmasına ve kullanmasına olanak tanıyan Küresel Benzersiz Tanımlayıcı (GUID) ile tanımlanır. Önyükleme Hizmetleri aracılığıyla keşfedilebilirler.


Bir UEFI sürücüsü bu protokolleri üretir ve gerçek işlevler (işaretçiler değil!) sürücünün kendisinde bulunur. Bu mekanizma, UEFI ortamındaki farklı bileşenlerin birbirleriyle iletişim kurmasını sağlar ve işletim sisteminin kendi sürücülerini yüklemeden önce cihazlarla etkileşime girebilmesini sağlar.



Bazı protokoller önceden tanımlanmış ve UEFI spesifikasyonunda açıklanmış olsa da, aygıt yazılımı satıcıları bir platformun işlevselliğini genişletmek için kendi özel protokollerini de oluşturabilirler .


Önyükleme Hizmetleri

Yalnızca önyükleme sırasında kullanılabilen işlevler sağlayın. Bu hizmetler, EFI_BOOT_SERVICES.ExitBootServices() işlevi çağrılana kadar kullanılabilir kalır ( MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c ).


Tüm önyükleme hizmetlerine ait işaretçiler Önyükleme Hizmetleri Tablosunda ( MdePkg/Include/Uefi/UefiSpec.h ) saklanır:


 typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_MEMORY_MAP GetMemoryMap; EFI_ALLOCATE_POOL AllocatePool; EFI_FREE_POOL FreePool; ... EFI_HANDLE_PROTOCOL HandleProtocol; ... EFI_EXIT_BOOT_SERVICES ExitBootServices; ... } EFI_BOOT_SERVICES;


Çalışma Zamanı Hizmetleri

İşletim Sistemi çalışırken hala erişilebilir olan asgari bir hizmet kümesi vardır. Önyükleme Hizmetlerinin aksine, bu hizmetler herhangi bir yük (örneğin, işletim sistemi önyükleyicisi) EFI_BOOT_SERVICES.ExitBootServices() çağrısı yoluyla platformun kontrolünü ele geçirdikten sonra bile geçerlidir.


Tüm çalışma zamanı hizmetlerine ait işaretçiler Çalışma Zamanı Hizmetleri Tablosunda ( MdePkg/Include/Uefi/UefiSpec.h ) saklanır:


 typedef struct { EFI_TABLE_HEADER Hdr; ... EFI_GET_TIME GetTime; EFI_SET_TIME SetTime; ... EFI_GET_VARIABLE GetVariable; EFI_GET_NEXT_VARIABLE_NAME GetNextVariableName; EFI_SET_VARIABLE SetVariable; ... EFI_GET_NEXT_HIGH_MONO_COUNT GetNextHighMonotonicCount; EFI_RESET_SYSTEM ResetSystem; ... } EFI_RUNTIME_SERVICES;


Aşağıdaki resim önyükleme ve çalışma zamanı hizmetlerinin zaman çizelgesini gösterir, böylece her birinin tam olarak ne zaman etkin olduğunu görebilirsiniz.



Önyükleme Aygıtı Seçimi (BDS) Aşaması

UEFI spesifikasyonu , UEFI önyükleme yöneticisi adı verilen bir önyükleme politikası motoru tanımlar. UEFI uygulamalarını belirli bir sırayla yüklemeye çalışacaktır. Bu sıra ve diğer ayarlar, küresel NVRAM (uçucu olmayan rastgele erişimli bellek) Değişkenleri değiştirilerek yapılandırılabilir. Bunlardan en önemlilerini tartışalım:


  • Boot#### ( #### benzersiz bir onaltılık değerle değiştirilir) — bir önyükleme/yükleme seçeneği.
  • BootCurrent — şu anda çalışan sistemi başlatmak için kullanılan önyükleme seçeneği.
  • BootNext — yalnızca bir sonraki önyükleme için önyükleme seçeneği. Bu, yalnızca bir önyükleme için BootOrder değiştirir ve ilk kullanımdan sonra önyükleme yöneticisi tarafından silinir. Bu, BootOrder değiştirmeden bir sonraki önyükleme davranışını değiştirmenize olanak tanır.
  • BootOrder — sıralı önyükleme seçeneği yükleme listesi. Önyükleme yöneticisi bu listedeki ilk etkin seçeneği önyüklemeye çalışır. Başarısız olursa, bir sonraki seçeneği dener ve bu böyle devam eder.
  • BootOptionSupport — önyükleme yöneticisi tarafından desteklenen önyükleme seçeneklerinin türleri.
  • Timeout — aygıt yazılımının önyükleme yöneticileri, BootNext veya BootOrder başlatma değerini otomatik olarak seçmeden önce saniyeler cinsinden zaman aşımına uğrar.


Bu değişkenler efibootmgr(8) kullanılarak Linux'tan kolayca elde edilebilir:


 [root@localhost ~]# efibootmgr BootCurrent: 0000 Timeout: 5 seconds BootOrder: 0000,0001,2001,2002,2003 Boot0000* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi) Boot0001* Windows Boot Manager HD(1,GPT,6f185443-09fc-4f15-afdf-01c523565e52,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)57a94e544f5753000100000088900100780000004200430044039f0a42004a004500430054003d007b00390064006500610038003600320063002d1139006300640064002d0034006500370030102d0061006300630031002d006600330032006200330034003400640034003700390035007d00000033000300000710000000040000007fff0400 Boot0002* ARCHLINUX HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000) Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC


Yukarıdaki kod parçasına güvenerek önyüklemeye bir göz atalım. UEFI, BootOrder listesini yinelemeye başlayacaktır. Listedeki her giriş için, karşılık gelen bir Boot#### değişkeni arar — 0000 için Boot0000 , 2003 için Boot2003 , vb. Değişken yoksa, bir sonraki girişe devam eder. Değişken varsa, değişkenin içeriğini okur. Her önyükleme seçeneği değişkeni, değişken uzunluktaki alanlardan oluşan bayt paketli bir arabellek olan bir EFI_LOAD_OPTION tanımlayıcısı içerir (sadece veri yapısıdır).


Veri yapısı [MdePkg/Include/Uefi/UefiSpec.h] adresinde açıklanmıştır [ https://github.com/tianocore/edk2/blob/edk2-stable202405/MdePkg/Include/Uefi/UefiSpec.h#L2122 ]


 typedef struct _EFI_LOAD_OPTION { /// The attributes for this load option entry. UINT32 Attributes; /// Length in bytes of the FilePathList. UINT16 FilePathListLength; /// The user readable description for the load option. /// Example: 'ARCHLINUX' / 'Windows Boot Manager' / `EFI USB Device` // CHAR16 Description[]; /// A packed array of UEFI device paths. /// Example: 'HD(5,GPT,d03ca3cf-1511-d94e-8400-c7a125866442,0x40164000,0x100000)/File(\EFI\ARCHLINUX\grubx64.efi)' // EFI_DEVICE_PATH_PROTOCOL FilePathList[]; /// The remaining bytes in the load option descriptor are a binary data buffer that is passed to the loaded image. /// Example: '57a9...0400' in Boot0001 variable // UINT8 OptionalData[]; } EFI_LOAD_OPTION;


Bu noktada, aygıt yazılımı bir Aygıt Yolunu ( EFI_DEVICE_PATH_PROTOCOL ) inceleyecektir. Çoğu durumda, bilgisayarımız bir depolama aygıtından (Sabit Sürücü/SSD/NVMe/vb.) başlatılır. Bu nedenle, Aygıt yolu HD(Partition Number, Type, Signature, Start sector, Size in sectors) düğümünü içerecektir.


  • TürMBR (1) veya GPT (2) anahtar sözcükleriyle bölümleme şeması için kullanılan biçimi belirtir.
  • İmza — Tür MBR ise 4 baytlık bir MBR imzası veya Tür GPT ise 16 baytlık bir UUID .


Not : Diğer yolların nasıl çevrileceğiyle ilgileniyorsanız, UEFI Spesifikasyonu v2.10, 10.6.1.6 Metin Aygıtı Düğüm Referansı'nı okuyun.


UEFI diske bakacak ve düğümle eşleşen bir bölümü olup olmadığına bakacaktır. Varsa, onu EFI Sistem Bölümü (ESP) olarak işaretleyen belirli bir Küresel Benzersiz Tanımlayıcı (GUID) ile etiketlenmelidir. Bu, FAT dosya sisteminin belirli sürümüne dayalı bir dosya sistemiyle biçimlendirilmiştir ve EFI Dosya Sistemi olarak adlandırılmıştır; aslında, bu yalnızca normal bir FAT12/16/32'dir .


  • Yerel önyükleme : Aygıt Yolu, File(\Path\To\The\File.efi) dosyasına açık bir yol içeriyorsa, UEFI o belirli dosyayı arayacaktır. Örneğin, Boot0000 seçeneği File(\EFI\ARCHLINUX\grubx64.efi) içerir.
  • Geri dönüş önyüklemesi : Aygıt Yolu basitçe bir diske işaret ediyorsa, bu gibi durumlarda, aygıt yazılımı mimariye dayalı bir geri dönüş önyükleme yolu kullanacaktır — \EFI\BOOT\BOOT{arch}.EFI ( amd64 için BOOTx64.EFI veya i386 / IA32 için BOOTia32.EFI ). Bu mekanizma , önyüklenebilir çıkarılabilir medyanın (örneğin, bir USB sürücü) UEFI'de çalışmasına izin verir; sadece bir geri dönüş önyükleme yolu kullanırlar. Örneğin, Boot0002 seçeneği bu mekanizmayı kullanacaktır.


Not: Yukarıda belirtilen tüm Boot#### seçenekleri, efibootmgr'nin örnek çıktısında görüntülenen önyükleme seçeneklerine atıfta bulunur.


Her iki durumda da, UEFI Önyükleme Yöneticisi UEFI Uygulamasını ( işletim sistemi önyükleyicisi , UEFI Kabuğu, yardımcı yazılım, Sistem kurulumu ve benzeri olabilir) belleğe yükleyecektir. Bu anda, kontrol UEFI uygulamasının giriş noktasına aktarılır. BIOS'un aksine, UEFI uygulaması kontrolü aygıt yazılımına geri verebilir (uygulamanın sistemin kontrolünü ele geçirdiği durum hariç). Bu olursa veya bir şey ters giderse, Önyükleme Yöneticisi bir sonraki Boot#### girişine geçer ve tam olarak aynı işlemi izler.


Belirtim, önyükleme yöneticisinin veritabanı değişkenlerini otomatik olarak koruyabileceğini belirtir. Bu, başvurulmayan veya ayrıştırılamayan yükleme seçeneği değişkenlerini kaldırmayı içerir. Ek olarak, karşılık gelen yükleme seçeneği değişkenleri olmadan herhangi bir yükleme seçeneğini kaldırmak için herhangi bir sıralı listeyi yeniden yazabilir.


Yukarıdaki metin UEFI önyüklemesini açıklar. Ayrıca, UEFI aygıt yazılımı, BIOS'u taklit eden Uyumluluk Destek Modülü (CSM) modunda çalışabilir.

İşletim Sistemi Önyükleyicisi

Donanım yazılımı (genellikle İkinci Aşama Önyükleyici ) tarafından başlatılan ve işletim sistemi çekirdeğini yüklemek için arayüzünü kullanan bir yazılım parçası. Bir işletim sistemi kadar karmaşık olabilir ve şu gibi özellikler sunar:


  • Çeşitli dosya sistemlerinden okuma (HFS+, ext4, XFS, vb.)
  • Bir ağ üzerinden etkileşim (örneğin, TFTP, HTTP)
  • Çoklu önyüklemeyle uyumlu çekirdeklerin önyüklenmesi
  • Zincir yükleme
  • İlk ramdiskler yükleniyor ( initrd )
  • Ve daha fazlası!


Bu programların genel tasarımları bu makalenin kapsamı dışındadır. Popüler işletim sistemi önyükleyicilerinin ayrıntılı bir karşılaştırması için ArchLinux wiki ve Wikipedia makalesine başvurabilirsiniz.


Windows sistemi , Windows Önyükleme Yöneticisi (BOOTMGR) olarak bilinen tescilli işletim sistemi önyükleyicisini kullanır.


Donanım yazılımı artık küçük, karmaşık bir kod parçası değil. Çok büyük miktarda karmaşık kod haline geldi ve güncel eğilimler buna katkıda bulunuyor. Üzerinde Doom , Twitter ve diğer birçok ilginç uygulamayı çalıştırabiliriz.


Genel mimariyi anlamak, bu bileşenleri zihninizde düzenlemenize yardımcı olur. Mevcut donanım yazılımının tasarımını inceleyerek, bir bilgisayar her açıldığında ortaya çıkan büyüleyici sürece dair fikir edinirsiniz. Bu yukarıdan aşağıya bakış açısı, yalnızca her bir parçanın rolünü açıklığa kavuşturmakla kalmaz, aynı zamanda modern donanım yazılımı sistemlerinin karmaşık ve gelişen doğasını da vurgular.

Kaynaklar