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.
Ü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:
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.
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ı :
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.
Ö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:
ExitBootServices()
çağrısıyla sonlanır.
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:
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.
Coreboot'un nasıl çalıştığına dair detaylı makaleler yakında geliyor. Sosyal medyamı takip edin – çok yakında yayınlanacaklar!
İ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ı :
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.
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.
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.
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.
Önyükleme Mantığı : Mevcut önyükleme ortamından yükü (muhtemelen işletim sistemini) bulup yükleme mekanizması.
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.
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.
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ı :
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.
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.
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.
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.
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 .
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.\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.
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:
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.