ARM mimarisinde PCI opsiyon ROM'ları ile ilgili sorunlar:
- X86 düzeneğinde yazılan bir seçenek ROM, bir ARM CPU tarafından anlaşılmaz.
- PC BIOS'ları tarafından yürütülmesi amaçlanan isteğe bağlı ROM'lar (bu tür ROM'lar
0x55AAsağlama toplamı ve ek bilgiler için bir kaç baytla başlar ve bunlarla başlar ), VGA donanımı, Intel CPU G / Ç bağlantı noktaları vb. Gibi PC mimarisinin düşük düzey ayrıntılarını varsayar.
- Tüm BIOS konsepti x86 CPU ve PC mimarisine sıkıca bağlandı ve hiçbir ARM sisteminde kullanılmadı.
Şimdi ...
UEFI, BIOS halefi, x86 dışındaki CPU'larda kullanılmak içindir.
Yukarıdaki sorunların çözümü, EFI bayt koduydu - UEFI'deki bir çalışma zamanı tarafından yorumlanacak ve bu sayede CPU'nun bağımsız olmasını sağlayan bir bayt kodu.
UEFI kullanan ARM sistemleri nispeten yenidir (Surface RT böyle bir sistem bile olabilir). ARM sistemlerinin çoğu, CFE, U-Boot veya PC BIOS gibi çalışmayan diğer boot firmware'lerini kullanır.
Şimdi bunu bir ARM makinesine takarsam, PCIe cihazı başlatılamadı mı?
ARM sistemi UEFI kullanmıyorsa, hiç şansınız olmazdı. Öyle olsaydı, sisteminiz muhtemelen önyüklenirdi. EBC önyükleme ROM belleniminde yaygın olarak kullanılmaz.
Önyükleme ROM'u çalışmazken, daha sonra önyükleme yapan bir işletim sistemi yine de donanımı tanıyabilir ve kullanabilecektir.
Önyükleme ROM'u ne yapar?
Eski UEFI öncesi BIOS, x86 kesme mekanizması aracılığıyla bir API uygulamaktadır. Programınızın çeşitli x86 kayıtlarını parametre olarak ayarlaması ve ardından bir x86 INTtalimatı vermesi gerekir .
INTx86 CPU'nun bir tabloda bir adres aramasına neden olur ve ardından kontrolü kendisine iletir (buna yazılım kesintisi denir - donanım bunun CPU'ya da bağlı bir kesme denetleyicisi ile konuşarak bunun olmasına neden olabilir).
Seçenek ROM'ları işlemeden önce, BIOS bu tabloyu BIOS'a geri dönen ve API işlevlerini gerçekleştiren çeşitli adreslere doldurur.
MS-DOS orijinal fonksiyonu için BIOS güvenerek, yoğun tablosu kullanan - bir B Te I /, girişi O ıkış S istem. Diğer işletim sistemleri denetime sahip olduklarında BIOS çağrılarını kullanmazlar, kendi sürücülerini ve donanım sürüş mekanizmalarını kullanırlar.
Bu kesme tablosu RAM'de olduğundan, değiştirilebilir. Seçenek ROM'lar kesme tablosuna "bağlanabilir" - belirli bir kesintinin adresini ROM'daki bir şeyin üzerine yazar - ve BIOS API çağrıları önce seçenek ROM'una gider.
BIOS'un kendisini kullandığı bir BIOS API çağrısı 13h- bu çağrı bir disk cihazının kesilen bölümünü okur. Bir işletim sistemini (MS-DOS bile) önyüklemek için sektör 0'ı sabit diskten yüklemek gerekiyor.
BIOS, disket ve IDE cihazlarıyla nasıl konuşulacağını biliyor ancak başka bir şey yapmıyor. Bir SCSI kartında, yeniden yazacak veya "takacak" 13h- ve bir SCSI sürücüsünden önyüklenmeyi mümkün kılan seçenek bir ROM olacaktır . İşletim sistemi MS-DOS ise, MS-DOS 13h, disk işlemleri için kullanacağından SCSI sürücüsüyle çalışabilir .
Ağ önyüklemesi, seçenek ROM'ların kullanıldığı başka bir durumdur.
Öyleyse, sürücülerin bunun yerine bununla ilgilenecek şekilde tasarlanması mümkün mü?
Evet ve onlar. BIOS seçenek ROM'ları yalnızca bir işletim sisteminin ve isteğe bağlı olarak bir yapılandırma menüsünün önyüklenmesini desteklemektedir (“RAID yapılandırmasına girmek için Ctrl-A tuşlarına basın”, Seçenek ROM'dandır ve BIOS'un başlangıç kodunu çağırdığı noktada görürsünüz).
IIRC Linux, yeniden numaralandırma aygıtlarıyla ilgileniyor ve x86 BIOS'tan gelen bilgileri hemen hemen göz ardı ediyor
Windows da bunu yapıyor. x86 BIOS (ve x86 gerçek mod), MS-DOS desteği için olduğu sürece takılı kalmıştır.