BIOS - Basic Input/Output System ( Podstawowy System Wejścia/Wyjścia ) jest to komponent komputera odpowiedzialny za jego prawidłowy start i dalszą pracę. Bios aktualnie jest zbiorem instrukcji procesora, które kolejno są wykonywane, coś w rodzaju programu komputerowego, jednak są pewne różnice, w tym gdzie jest przechowywany kod, oraz w dostarczanej funkcjonalności.
W przeciwieństwie do innych programów, Bios jest trwałym elementem komputera, dokładnie płyty głównej. Kod nie jest ładowany z dysku, lecz przechowywany jest w pamięci ROM ( Read Only Memory - pamięć tylko do odczytu ) zwanej ROM BIOS, aktualnie możemy się spotkać z nazwą "Flash Bios", wynikającą z użycia technologii pamięci flash do przechowywania (o tym pozniej). Kod programu w Biosie różni się od typowego oprogramowania, ponieważ jest integralną cześcią komputera, definiuje czym komputer jest i co potrafi zrobić, zawiera dokładną specyfikację sprzętową komputera i od momentu startu wykonuje pracę w celu uruchomienia systemu operacyjnego.
Podstawowe zadania BIOS-u:
Przeprowadzenie po restarcie, testów podstawowych układów i urządzeń systemu, zwanych autotestem po włączeniu zasilania - POST (Post On Self Test).
Inicjalizacja pracy systemu (instrukcje pobierane podczas startu pracy procesora, programowanie układów programowalnych, takich jak sterowniki przerwań czy DMA, wpisanie wartości początkowych do struktur systemowych w pamięci, na przykład inicjacja tablicy wektorów przerwań).
Zapewnienie w postaci programów obsługi przerwań (programowych bądź sprzętowych), procedur obsługi (sterowników) podstawowych, standardowych urządzeń systemu.
Niwelacja z punktu widzenia systemu operacyjnego, różnic konstrukcyjnych płyt głównych pochodzących od różnych producentów.
Podczas procesu startu komputera jest również rezerwowana mała liczba bloków pamięci RAM zwana BIOS Data Area, gdzie przechowywane są konfiguracyjne informacje, aby programy miały możliwość dowiedzenią się np. jaki dysk lub jaka karta(system) video jest zainstalowany w komputerze. Można powiedzieć, że Bios łączy oprogramowanie użytkowe ( włącznie z systemem operacyjnym ) ze sprzętem.
PowrótPo uruchomieniu komputera kontrolę przejmuje BIOS, dokładnie mikroprocesory rodziny Intel 8086 przekazują automatycznie sterowanie do adresu F000:FFF0 (segment:ofsset), który jest 16 bajtów poniżej końca pamięci trybu rzeczywistego, która jest pierwszym megabajtem pamięci, do której ma dostęp procesor pracując w trybie rzeczywistym. Pierwsza instrukcja pod tym adresem jest instrukcją skoku do procedury realizującej test komputera POST.
POST - Post On Self Test
W pierwszym kroku testowany jest procesor (typowe instrukcje, rejestry, itp.). Jeżeli pojawi się jakikolwiek błąd, sygnalizowany jest za pomocą dźwięku z głośniczka systemowego ( liczba dźwięków, ustalona przez producenta, oznacza konkretny błąd ) i inicjalizacja jest przerywana. Potem testowana jest pamięć ROM, zawartości komórek pamięci są dodawane i porównywane z wartością sum kontrolnych znajdujących się na końcu pamięci ROM. Następnie testowana jest pamięć RAM - test polega na zapisywaniu pamięci wartościami testowymi, które potem porównywane są z odczytywanymi. Potem testowane są pozostałe układy na płycie głównej, a następnie poddawane kontroli są podstawowe urządzenia peryferyjne ( klawiatura, karta grafiki, stacja dyskow elastycznych, dyski twarde, itp. ). Ostatni test sprawdza rozszerzoną pamięć ROM, jeśli taka została wykryta.
PowrótExtension BIOS (ROM)
Każda funkcja startowa BIOS'u jest osobnym, oddzielnym kawałkiem kodu ( struktura modułowa ), co pozwala w łatwy sposób rozpoznawać i dodawać nowe moduły. Ta cecha pozwala dodać kod inicjalizujący z urzadzeń, które będą podłączone do płyty głównej.
Od czasu pierwszego IBM PC BIOS kodu po dzisiejsze biosy, w prosty sposób odbywa się proces wykrywania rozszerzonej pamięci ROM na kartach (urzadzeniach np. dysk) zewnętrznych. Bios skanuje fragment zarezerwowanej pamięci w poszukiwaniu specjalnej sekwencji bajtów, która jest sygnaturą dodatkowego modułu BIOS'u. Specjalna sekwencja dwubajtow określa początek dodatkowej sekcji ( dokładnie 055h, a potem 0AAh ). Następny bajt określa, ile będziemy potrzebowali 512 bajtowych bloków do przetrzymywania dodatkowego kodu.
Jeżeli dodatkowy kod został poprawnie zidentyfikowany, system ( program wykonywalny BIOS'u ) wykonuje skok do czwartego bajtu sekcji i wykonują się specyficzne funkcję dla danego urządzenia. Przeważnie te instrukcje informują system jak zaincjalizować dane urządzenie oraz tworzą(udostepniają) funkcję obsługi, które będą dostępne dla BIOS'u oraz oprogramowania systemu operacyjnego.
Kiedy zakończą się instrukcje rozszerzenia BIOS'u, sterowanie jest zwracane z powrotem i system kontynuuje przeszukiwanie pamięci. Kiedy zakończy sie proces wykrywania rozszerzonej pamięci ROM, system przechodzi do istotnego procesu startowego Plug-and-Play.
PowrótPlug-and-Play
Plug-and-Play jest to skomplikowany proces, który umożliwia PC zidentyfikowanie większość zainstalowanych dodatkowych kart, również starsze karty ISA ( chociaż niektóre bedą wymagać ręcznej konfiguracji ), i większość kart PCI.
W czasie startu systemu BIOS musi nie tylko rozpoznać i poprawnie zainstalować różne urządzenia, ale od czasu wprowadzenia magistrali PCI i technologii PnP spoczywa na nim dodatkowy obowiązek rozdziału zasobów systemowych. Wymagane do tego informacje o konfiguracji zapisywane są w obszarze ESCD (Extended System Configuration Data), który zajmuje obszar 4kB ( w zależności od modelu ). Tłumaczy to jednocześnie, dlaczego obecnie stosowane są układy flash-ROM w miejsce popularnych dawniej pamięci EPROM (EPROM nie umożliwiały zapisu danych).
Zadania wykonywane przez BIOS Plug-and-Play:
Zostają utworzone przez BIOS wszystkie dostępne przerwania IRQ, kanały DMA i adresy I/O. Wyłączone pozostają jedynie zasoby zarezerwowane przez użytkownika.
BIOS przekazuje magistralę ISA i PCI.
Załadowana zostaje ostatnia konfiguracja systemu ESCD i porównana z aktualną.
Zostaje określone zapotrzebowanie na zasoby wszystkich niezgodnych komponentów z P&P.
Sprawdzone zostają zasoby przydzielone przez użytkownika i usunięte z tablicy wolnych zasobów.
Kartom P&P przydziela dostępne w tablicy zasoby systemowe i informuje urządzenia o wprowadzonych zmianach.
Bios zapisuje aktualną konfigurację za pomocą mechanizmu ESCD.
Aktualna konfiguracja wyświetlona zostaje na ekranie monitora i przekazana do drugiego etapu uruchomienia, który jest już wykonywany przez system operacyjny.
PowrótStart systemu operacyjnego
Po teście POST i procedurach inicjalizujących, kontrolę przejmuje oprogramowanie w postaci systemu operacyjnego. Większość komputerów ładuje swój kod systemu operacyjnego z dysku, ale również niektóre prosto z sieci, innymi slowy BIOS musi wiedzieć wystarczająco dużo o stacji dyskietek, dyskach i cdromach czy karcie sieciowej, aby móc odnależć i uruchomić kod systemu operacyjnego.
Proces startu systemu to IPL (initial program load). Nowe Biosy sprawdzają konfigurację skąd ma być system operacyjny załadowany i ładują kod z boot sektora np. dysku twardego. Dalej w zależnosci od systemu sa podejmowane dalsze czynności ( np. załadowanie okrojonego sterownika systemu FAT dla Windows ).
PowrótKorzystanie z funkcji dostarczonych przez BIOS umożliwiają przerwania programowe. Aby użyć jakiejś sprzętowej funkcji, program ładuje rejestr numerem przerwania, i następnie wykonywana jest instrukcja przerwania INT. Instrukcja ta powoduje, że mikroprocesor zagląda do tablicy przerwań ( pod daną pozycję ) i wykonuje skok do zbioru instrukcji odpowiadających danemu przerwaniu. Kiedy obsługa przerwania się skończy sterowanie powraca do orginalnego kodu programu za instrukcję INT.
Przykładowa lista programowych przerwań obługiwanych przez prawie wszystkie PC'ty:
| Przerwanie programowe (w Hex) |
Funkcja |
| 02 | Non-Maskable Interrupt |
| 05 | Print Screen |
| 08 | System Timer |
| 09 | Keyboard |
| 10 | Video Interface |
| 11 | Equipment Check |
| 12 | Memory Request |
| 13 | Fixed Disk/Diskette Interface |
| 14 | Serial Interface |
| 15 | System Functions |
| 16 | Keyboard |
| 17 | Printer/Parallel Port Interface |
| 19 | Primary Boot Request |
| 1A | System Timer and Real-Time Clock |
| 70 | Real-Time Clock |
Ewolucja systemów operacyjnych PC spowodowała, że obecnie jedyną rolą BIOS-u jest załadowanie systemu operacyjnego. Tym niemniej, ze względu na przyjętą w Standardzie PC zasadę wstecznej zgodności, BIOS musi być wciąż obecny. Chociaż bardzo niewiele używany, jest niezbędny do działania komputera.
W systemach takich jak Linux czy Windows od 95 po XP - większość funkcji BIOS'u nie jest wykorzystywana, jedynie do programowania niskopoziomowego układów scalonych i współpracy z sytemem do kontroli zarządzania energią. Współcześnie urządzenia systemowe i peryferyjne są głównie kontrolowane przez system operacyjny i różnego rodzaju driver'y. Czasami nowsze systemu ignoruja informacje o wykrytych urządzeniach przez BIOS, co może się objawić że dane urządzenie wyłączymy w BIOS'ie, a będzie zainstalowane i gotowe do działania pod systemem operacyjnym.
Mimo wszystko, że system operacyjny nie używa funkcji bios'u, każdy PC potrzebuje bios'u, ponieważ potrzebujemy jakiejś kontroli nad komputerem zanim zostanie załadowany system operacyjny. Np. system video musi działać, żebyśmy widzieli, co system wykonuje i musi być podstawowa obsługa dysków, abyśmy mogli załadować nasz system operacyjny.
PowrótBios przechowywany jest we wbudowanej na płycie głównej pamięci ROM. W dzisiejszych konstrukcjach jest to oczywiście pamięć typu Flash ROM, której zawartość może być dowolnie modyfikowana za pomocą odpowiedniego oprogramowania. Zapewnia to użytkownikowi możliwość załadowania nowej wersji bios'u, potrzebnej np. przy zmianie procesora na nowszy i szybszy, ale... stwarza szansę dla wirusów. Znane są już wirusy, które potrafią uszkodzić lub zmodyfikować bios. Nic zatem dziwnego, że konstruktorzy płyt głównych zaczęli stosować rozmaite rozwiązania, chroniące bios przed trwałymi uszkodzeniami - np. dwa biosy na płycie, lub możliwość załadowania biosu z dyskietki ( przed wszystkimi czynnościami startowymi, tylko podstawowa obsługa stacji dyskietek - ten fragment bios'u jest niezmienialny).
W tej samej pamięci, co BIOS, przechowywany jest również inny ważny program "wbudowany" w płytę główną. Jest to tzw. SETUP, czyli narzędzie programowe umożliwiające zapisanie charakterystyki konfiguracji komputera. Setup współczesnej płyty pozwala na wiele modyfikacji ustawień poszczególnych parametrów, a przy właściwym wykorzystaniu tych możliwości wydajność komputera może wyraźnie wzrosnąć w stosunku do ustawień fabrycznych (default). Ustawienia dokonywane w SETUP-ie dotyczą wszystkich układów znajdujących się na płycie głównej.
Zapamiętane dane o konfiguracji przechowywane są w pamięci dostatecznie długo przy pomocy baterii lub małego akumulatorka, doładowywanego zwykle z zasilacza sieciowego komputera. Nowoczesne baterie litowe mają trwałość określaną przez producentów 10 lat. Często spotykanym rozwiązaniem jest zitegrowanie układu scalonego z zasilaczem. Często w instrukcjach b.starych komputerach było zalecenie uruchamiania komputera nie rzadziej niż co dwa tygodnie.
PowrótW latach 80 komputery rozwijały się coraz szybciej, powstawało mnóstwo nowego sprzętu. Pojawił się problem z niezliczoną ilością konfiguracji. W laboratoriach SUN opracowano i opublikowano w 1988r standard OpenBoot, który przerwał koszmar i pozwolił jednej wersji BootRom'u na uruchamianie na każdej konfiguracji sprzętu i oprogramowania.
Idea okazała się słuszna, inni producenci komputerowi, tacy jak IBM, czy Apple również zaczęli wspierać projekt, co zaowocowało stworzeniem standardu dla OpenFirmware - IEEE-1275
OpenFirmware z założenia składał się z następujących komponentów:
język FCode - kodowanie operacji np.: 0x47 - duplikuj element ze stosu...
User Interface - powłoka interpretująca proste polecenia wpisywane przez użytkownika na standardowym wejściu
Device Interface - komponent budujący drzewo urządzeń,
Client Intereface - komponent pozwalający systemowi operacyjnemu wywoływać polecenia wysoko-poziomowym językiem, np. C
Aby zobaczyć, że to może działać należy zrozumieć co chcemy uzyskać. Główne zadania jakie ma spełnić kod bootujący to:
uruchomienie Driverów - ich zadaniem jest przede wszystkim wyświetlanie komunikatów podczas bootowania, przed wystartowaniem OS'u. Są również bardzo przydatne podczas debuggowania sprzętu, gdy ten zawiedzie podczas uruchamiania.
i przede wszystkim zbudowanie drzewa urządzeń - z niego będzie później korzystał OS, aby dowiedzieć się jakie urządzenia są i jak z nich korzystać. Oczywiście każdy OS tworzy sobie własne drzewo urządzeń, bazując na drzewie stworzonym przez OF, a informacje o nim uzyskuje poprzez Client Intereface. Podczas budowania każde urządzenie dostaje potrzebną do działania pamięć.
Powrót
Apple Macintosh: aby wejść do User Interface należy przytrzymać przycisk NMI podczas wciskania przycisku Reset. Wtedy zostaje uruchomiony bardzo podstawowy proces bootowania, bez ładowania systemu, z niskopoziomową diagnozą sprzętu, otwarty zostaje port dla operacji We/Wy, i wyświetla się znak zachęty oczekując na polecenia od użytkownika. (sposób uruchamiania nie jest zdefiniowany przez IEEE)
Powrótjęzyk FORTH, przykłady, debuggowanie
Forth jest językiem bazującym na stosie używającym odwrotnej notacji polskiej, tzn. najpierw umieszczamy argumenty na stosie, a następnie operujemy na nich używając poleceń. przykład:
0 > decimal ok 0 > 5 ok 1 > 7 ok 2 > + ok 1 > . 12 ok 0 > |
następny przykład to efekt wywołania polecenia dev / ls ; dev otwiera węzeł w drzewie, / to korzeń drzewa, ls wypisuje poddrzewo:
0 > dev / ls 86746496: /PowerPC,604@0 86747184: /l2-cache@0,0 86749168: /chosen@0 86749472: /memory@0 86749800: /openprom@0 86749992: /AAPL,ROM@FFC00000 86750528: /options@0 86752280: /aliases@0 86752856: /packages@0 86752992: /deblocker@0,0 86755040: /disk-label@0,0 86756384: /obp-tftp@0,0 86765664: /mac-files@0,0 86767704: /mac-parts@0,0 86769592: /aix-boot@0,0 86770736: /fat-files@0,0 86776320: /iso-9660-files@0,0 86778696: /xcoff-loader@0,0 86781192: /terminal-emulator@0,0 86781344: /bandit@F2000000 86785936: /gc@10 867... ok 0 > |
devalias -- ustawienie aliasów dla urządzeń:
0 > devalias vci0 /chaos@F0000000 pci1 /bandit@F2000000 pci2 /bandit@F4000000 fd /bandit/gc/swim3 kbd /bandit/gc/via-cuda/adb/keyboard ttya /bandit/gc/escc/ch-a ttyb /bandit/gc/escc/ch-b enet /bandit/gc/mace scsi /bandit/gc/53c94 scsi-int /bandit/gc/mesh ok |
podgląd urządzenia:
0 > pwd / ok 0 > .properties name device-tree model Power Macintosh compatible AAPL,9500 MacRISC AAPL,cpu-id 3900A69D #address-cells 00000001 #size-cells 00000001 clock-frequency 02FAF080 ok 0 > words dma-sync dma-map-out dma-map-in dma-free dma-alloc map-out map-in decode-unit close open ok 0 > |
Możliwy jest również dostęp do dysku twardego, oraz wykonywanie zawartości plików:
\ This is a file that contains some colon defined, formatted, \ commonly used, basic Open Firmware functions. ." vv = hello & select root (dev /) " cr ." xx = formatted directory (pwd) " cr ." yy = key controlled dev tree list (ls) " cr ." zz = formatted property list (.properties) " cr : hello ( -- ) cr ." Hello Open Firmware" ; : slctroot ( -- ) " ... selecting 'root' " cr ; : scrl-start ( -- ) cr ." press Control-Q to start scrolling" ; : scrl-stop ( -- ) cr ." press Control-S to stop scrolling" ; : wt-4-key ( -- ) cr ." press an key to continue ... " key clear ; : vv ( -- ) hello slctroot clear " /" find-device ; : xx ( -- ) cr cr ." " pwd ." = current working directory" ; : yy ( -- ) cr scrl-start scrl-stop cr wt-4-key ls ; : zz ( -- ) cr cr ." *** Properties ***" cr .properties ; \ end of file comment ... so I can locate the end! |
przeglądanie hd:
0 > dir hd:\
117820 4/ 7/ 0 23:43:38 1DIMM
124280 4/ 7/ 0 23:37:19 2DIMM
6/ 2/ 0 15:10: 0 Anarchie%203.7
3824 6/ 2/ 0 15:10: 0 Anarchie%203.7%20Installer%20Log%20File
68539 6/ 7/ 0 14:39:21 Apple%20CPU%20Plugins
6/ 5/ 0 20:56: 2 Apple%20Extras
159744 6/24/ 0 0:30:15 AppleShare%20PDS
6/ 5/ 0 20:31:29 Applications
6/ 5/ 0 20:33:18 Assistants
158 6/ 6/ 0 0:45:34 Auth.bak%0a
8/17/ 0 22:26:24 Cleanup%20At%20Startup
6/ 5/ 0 23:51:33 Cubase%204.1
319488 8/24/ 0 15:32:41 Desktop%20DB
1652242 8/24/ 0 15:31:58 Desktop%20DF
8/25/ 0 22:59:53 Desktop%20Folder
210 8/25/ 0 22:49:15 devtree_OF
5/ 3/ 0 0: 1: 3 Echo%20Card%20Folder
6/ 5/ 0 16:15:18 firewire
6/16/ 0 17:23:50 ImageMate3_A%20folder
6/ 5/ 0 20:26: 4 Installer%20Logs
6/ 5/ 0 20:33:18 Internet
0 6/ 5/ 0 20:31:27 Late%20Breaking%20News
8/25/ 0 18:55:44 OFfolder
6/15/ 0 20:50: 0 Sys%20folders
8/24/ 0 15:49:46 Temporary%20Items
6/ 6/ 0 7: 0:44 TheFindByContentFolder
6/ 5/ 0 21: 4:29 TheVolumeSettingsFolder
2/ 2/ 4 10:12:38 Trash
287 6/ 5/ 0 23:59:30 USB%20Floppy%20Enabler%20Install%20Log
9549 10/24/99 7: 0: 0 USB%20Floppy%20Enabler%20READ%20ME
6/ 5/ 0 20:27:30 Utilities
6/ 5/ 0 20:33:39 Web%20Pages
6/24/ 0 0:13:45 %uffe5%uffe5%uffe5%20HFS%20Private%20Meta%20Data
ok
0 > dir hd:\OFfolder
156 8/26/ 0 1:41:43 devtree_test ok
ok
|
wykonywanie pliku:
0 > boot hd:\devtree_OF load-size=378 adler32=15900efd evaluating Forth source vv = hello & select root (dev /) xx = formatted directory (pwd) yy = key controlled dev tree list (ls) zz = formatted property list (.properties) ok 0 > vv Hello Open Firmware ... selecting 'root' ok 0 > xx / = current working directory ok 0 > |
ogólny schemat jak debuggować urządzenia:
Powrót
Dokumentacja techniczna dla deweloperów - Apple
Aby uzyskać super wydajny system, można zastosować dwa rozwiązania:
inny przykład klastra klasy "mini" - klaster ACCORD - W chwili obecnej klaster składa się z 16 węzłów obliczeniowych (32 procesory AMD Athlon MP). Do jego budowy wykorzystano własne rozwiązania sprzętowe. Klaster zawiera 8 węzłów (eltoro - eltoro07) opartych na dwuprocesorowych płytach głównych Tyan Tiger MPX z procesorami AMD Athlon MP 1600 MHz oraz 8 węzłów (eltoro08 - eltoro15) opartych na dwuprocesorowych płytach Tyan Tiger MP z procesorami AMD Athlon MP 1200 MHz. Każdy z węzłów posiada po 512 MB pamięci typu RAM oraz 60 GB pamięci dyskowej a węzeł zarządzający (eltoro) posiada dodatkowo dysk 80GB na konta użytkowników...
PowrótParę lat temu zespół z Cluster Research at Los Alamos Laboratory zaczął zastanawiać się nad usprawnieniem węzłów w klastrach. Doszli do następujących wniosków:
Wtedy pojawił się pomysł zrezygnowania z biosu... a w jego miejsce zainstalowania systemu operacyjnego.
Około roku 2000 rozpoczęto prace nad zastąpieniem biosu przez jądro linuxa które może uruchomić linuxa z zimnego startu. Systemem operacyjnym który stosunkowo najmniej korzysta z usług standardowego biosu, a zarazem którego kod źródłowy jest dostępny jest linux. Nowatorski eksperyment powiódł się i wynikiem tego jest LinuxBIOS, który jest zwykłym linuxem z zaaplikowanymi 10 liniami patch'y. Dodatkowo dodano instrukcje potrzebne do wystartowania - około 500 linii kodu napisanego w assemblerze i około 5000 linii kodu napisanego w C. Wykonywanych jest tylko 16 instrukcji, potrzebnych do przejścia w tryb 32-bitowy.
Zalety LinuxBIOS'u:
Dzięki wgraniu jądra linuxa do pamięci flash podstawowa konfiguracja węzła zdolnego do pracy to:
komputer nie potrzebuje dysku twardego... klawiatury, monitora...
PowrótW roku 2000, gry uruchomiono dwa komputery z LinuxBIOS'em na pokładzie pojawiły się głosy, że idea ma sens, jednak nie ma szans na sukces gdyż nie uda się zaimplementować jąder dla wszystkich modeli płyt głównych. Sytuacja jest jednak podobna do tej, jaka była z FreeBSD oraz Linuxem. w 1991 roku również tylko mała grupa ludzi wierzyła w powodzenie projektu Linusa Torvaldsa...
PowrótCzas potrzebny na wystartowanie komputera i zgłoszenie znaku zachęty to nawet tylko 3 sekundy. Komputer po niecałej sekundzie gotowy jest do zamontowania systemu plików (zobacz ciekawostki).
LinuxBIOS po sekundzie gotowy jest do nawiązania połączenia sieciowego z serwerem z którego ściąga właściwe jądro. Zalety tego rozwiązania to zcentralizowanie jądra w jednym miejscu.
Powrótoto link do jednego z pierwszych klastrów opartych na LinuxBIOS'ie:
PowrótPink to klaster zbudowany z 1024 węzłów, każdy po dwa procesory Pentium 4. Węzły działają oczywiście w oparciu o LinuxBIOS'a. Jedną z cech wyróżniających Pink'a, to sposób wstawania systemu. Węzeł nie zawiera lokalnego dysku twardego, bootuje LinuxBIOS'a z Flash RAM'u. Każda jednostka jest gotowa do pracy z odpalonym linuxem w ciągu kilku sekund. Jedną z pierwszych rzeczy jaką robi węzeł to łączy się z "serwerem" (BProc), skąd pobiera nowe, docelowe jądro na którym będzie pracować i zamienia obecnie uruchomione z nowym. To dwu poziomowe bootowanie upraszcza do granic możliwości zarządzanie systemem eliminując różnice w wersjach jąder na poszczególnych maszynach. Jądro - jedno dla całego klastra znajduje się na wyróżnionym węźle. Jakakolwiek zmiana dokonywana jest w jednym miejscu, po czym prawie natychmiastowo można wprowadzić zmiany poprzez reset klastra.
konfiguracja:
strona domowa klastra Pink
PowrótLinuxBIOS'a można z powodzeniem stosować również pracując na jednym komputerze. Przykłady kiedy zastąpienie oryginalnego biosu może być bardzo opłacalne to:
Ciekawostki:
Kolejne kroki wykonywane przez LinuxBIOS po uruchomieniu:
Uruchomieniu trybu ochrony pamięci
1. Pierwsza instrukcja: wykonywana w trybie 16 bitowego adresowania. Skok do początku BIOS'a - jest to standardowa instrukcja obsługi "resetu" w procesorach x86.
2. Kolejne 5 instrukcji: zablokowanie przerwań, wyczyszczenie TLB, ustawienie rejestrów segmentów kodu i danych.
3. Kolejna instrukcja: załadowanie wskaźnika do Globalnej Tablicy Deskryptorów (GDT). Jest to tablica kontroli zarządzania adresowaniem w trybie segmentowym.
4. Kolejne 4 instrukcje: włączenie ochrony pamięci.
5. Kolejne instrukcje: zrobienie pozostałych ustawień rejestru segmentów dla trybu ochrony pamięci.
W ten sposób po wykonaniu 17 instrukcji jesteśmy w trybie ochrony pamięci i możemy zaadresować 4 GB pamięci oraz działamy z prędkością naszego procesora, a nie jako 8086.
PowrótDRAM często wymaga jakiejś konfiguracji (zależnie od płyty głównej). Ponieważ nie mamy jeszcze działającej pamięci ten kod jest w assemblerze. Ta część okazała się najtrudniejsza i pochłania kilka tygodni dla większości płyt. Ta część to 79 linii asemblera dla Intela, a 280 dla Procomm. Tak więc są tutaj dosyć znaczne różnice.
PowrótReszta LinuxBIOS'a jest pisana w C, więc kolejnych kilka instrukcji inicjuje stos i wywołuje funkcje inicjujące resztę sprzętu.
PowrótInicjacja płyty głównej zawiera ograniczą inicjalizację sprzętu, którego potrzebujemy do załadowania jądra systemu. W obecnej implementacji jest to:
1. Wykonanie czynności wymaganych przez płytę główną do włączenia cache'u.
2. Umożliwienie procesorowi dostępu do całej pamięci FLASH.
3. Uaktywnienie minimalnych możliwości sprzętowej kontroli mocy (jeśli jakaś jest możliwa).
Potrzebujemy również paru rzeczy, których Linux nie może zrobić lub nie zrobi. Obecnie Linux nie inicjalizuje zupełnie niezainicjowanych gniazd PCI. Robimy tutaj niezbędne minimum inicjalizacji, tj. ustawienie Base Adress Registers na sensowne wartości, a resztą zajmie się Linux. Linux wymaga również aby klawiatura była w odpowiednim stanie, więc ją resetujemy. W końcu włączamy przerwania zegarowe (jest to zależne od płyty głównej).
Ustawienie płyty głównej to obecnie 330 linii kodu w C.
PowrótJest to standardowy kod wzięty z jądra Linux'a. Został on nieco rozszerzony. Po pierwsze parametry z LinuxBIOS'a zostają właściwie zinterpretowane w tym kodzie. Zostają one skopiowane do standardowych lokacji dla danej architektury. Wiersz poleceń również jest kopiowany. Standardowy gunzip nie będzie działał w środowisku ROM bez paru zmian. Przede wszystkim zminiona jest deklaracja zainicjowanych tablic jako 'const' tak aby były one trzymane w pamięci tylko do odczytu (np. FLASH) a nie RAM. Inicjacja automatyczna i zmienne globalne musi również być zmienio tak, aby odbywała się na bieżąco.
Gdy parametry i linia poleceń zostaną skopiowane uruchomiony zostaje gunzip i jądro zostaje rozpakowane do standardowej w danej architekturze lokalizacji (0x100000 dla PC).
PowrótJest to prosta instrukcja skoku. "Skaczemy" bezpośrednio do początku kernel'a, ponieważ większość standardowych ustawień jest zbędna - odbywa się w LinuxBIOS'ie.
Zamiasta uruchamiać jakiś bootloader taki jak np. lilo wchodzimy od razu do jądra do funkcji startup_32.
Podsumowując struktura LinuxBIOS'a jest prosta - jest tam tylko tyle assemblera aby wszystko działało, a reszta jest w C. Jest tylko tyle C aby sprzęt działał, a reszta to Linux.
PowrótPierwszą rzeczą jaką należy sprawdzić jeśli planujesz instalację LinuxBIOS jest to, czy twoja płyta główna jest kompatybilna i wspierana. Strona LinuxBIOS zawiera informacje, które płyty są wspierane. Najważniejszym wymaganiem dla płyty głównej jest to, czy jej chip BIOS można usunąć z gniazda, ponieważ w ten sposób należy zmienić stary chip BIOS na nowy, większy zawierający kod LinuxBIOS.
Kroki potrzebne do instalacji LinuxBIOSu na wspierane płyty główne są bardzo podobne do tych przedstawionych tutaj.
Kolejnym potrzebnym elementem jest Disk-on-Chip(DoC) - urządzenie pamięci, które zostanie podłączone zamiast naszego starego chipu BIOSu, i które ma wystarczającą wielkość do pomieszczenia jądra Linuxa oraz małej wielkości bootstrap generowany przez LinuxBIOS, potrzebny do inicjalizacji płyty głównej. DoC jest urządzeniem, które może zostać sformatowane tak, by wyglądało jak twardy dysk, i które może zawierać standardowy system plików Linuxa.
Urządzenie DoC tutaj wykorzystane ma 8MB programowalnej pamięci flash i pasuje do standartowego 32-igłowego gniazda używanego przez 2 megabitowe chipy BIOS.
W końcu zaleca się użycie 32-igłowego gniazda Zero Insertion Force (ZIF), w celu ułatwienia usunięcia i podłączenia BIOSu i DoC. Dzięki niemu czynności powinny być bezpieczne. Procesu programowania DoC zawiera usunięcie BIOSu i podłączenie DoC przy włączonym napięciu. Robienie tego bez ZIF jest zdecydowanie odradzane i może zakończyć się nawet śmiercią.
PowrótPo pierwsze należy przeczytać LinuxBIOS FAQ i dokumentacje LinuxBIOSa dla twojej płyty głównej. FAQ daje ogólne pojęcie o procesie i o jego krokach. Do tworzenia kodu LinuxBIOSa można użyć systemu developerskiego, programując go do DoC, a potem umieszczając je w oddzielnym systemie docelowym, na którym będzie on działał. Użycie tylko jednej maszyny jako systemu do tworzenia i systemu docelowego jest jednak tak samo proste. Kroki potrzebne do instalacji LinuxBIOSa są następujące:
instalacja Linuxa ze wsparciem dla DoC (które raczej nie jest standardowe) na maszynie docelowej,
zdobycie źródeł LinuxBIOSa,
zdobycie odpowiedniego patcha dla jądra Linuxa i zbudowanie go,
konfiguracja i budowa kodu LinuxBIOSu odpowiedniego dla twojej płyty głównej,
zdobycie narzędzi Memory Technology Device (MTD) narzędzia erase
usunięcie chipu BIOSu z gniazda i podłączenie DoC (przy włączonym zasilaniu),
wypalenie na DoC obrazu LinuxBIOSu zawierającego kod boota i jądro,
zresetowanie komputera i start systemu pod LinuxBIOSem.
Zanim rozpoczniemy należy podłączyć gniazdo ZIF do płyty głównej i umieścić w nim oryginalny BIOS i uruchomienie systemu. Najpierw należy zapamiętać położenie chipu BIOSu i przy ponownym podłączeniu zrobić to w tą samą stronę.
Jeśli jeszcze nie masz zainstalowanego Linuxa zainstaluj podstawowy system. Powinien on zawierać narzędzia programisty do zbudowania jądra, należy także zainstalować Python'a, ponieważ jest on używany przy plikach konfiguracyjnych LinuxBIOSa.
Pierwszą rzeczą, którą należy zrobić po instalacji to kompilacja jądra, które będzie używane przez LinuxBIOS tak, aby zawierał wsparcie dla MTD (Memory Technology Devices), którego nie ma w standardowej instalacji jądra. Jest istotne abyś miał wsparcie dla dla ładowanych modułów na maszynie, na której system będzie powstawał, ponieważ dla programowania DoC jest niezbędne uruchomienie kilku komend przed załadowaniem modułu obsługi DoC i dlatego nie może być skompilowany bezpośrednio w jądrze.
Jeśli używasz make menuconfig to opcje, które należy zaznaczyć przedstawione są poniżej:
Dodatkowo należy zmienić jeden z plików jądra, aby obsługa MTD działała poprawnie. Wymagana zmiana jest w pliku /usr/src/linux/drivers/mtd/devices/docprobe.c należy przedefiniować następującą linię:
#define DOC_SINGLE_DRIVER
na:
#undef DOC_SINGLE_DRIVER
Następnie ściągnij źródła LinuxBIOSa przez CVS z sourceforge'a. Wprowadzając puste hasło i ignorując informacje o błędach. Postępuj według następującej procedury:
export CVS_RSH=ssh
cvs -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios login
cvs -z3 -d:pserver:anonymous@cvs.freebios.sourceforge.net:/cvsroot/freebios co freebios
LinuxBIOS opiera się na wcześniejszym projekcie FreeBIOS i taka nazwa pojawia się w ścieżce użytej przy kompilacji LinuxBIOS. Zanim rozpakujesz świeże jądro aby wprowadzić patch LinuxBIOSa, sprawdź patche LinuxBIOSa aby dopasować wersję do twojej płyty głównej, wersji jądra i chipu. Prawdopodobnie będziesz mógł zastosować patch do innego jądra, ale na tym etapie najlepiej jest postępować dokładnie zgodnie z instrukcją, aby upewnić się, że LinuxBIOS w ogóle działa.
Należy zwrócić uwagę na to, że patche jądra i pliki konfiguracyjne są przeznaczone dla jądra, które będzie zaprogramowane na DoC, i z którego będzie się bootował twój komputer. Mogą one nie być najlepsze dla jądra, którego używasz przy tworzeniu LinuxBIOSa i wypalania DoC przed uruchomieniem z niego systemu. Gdy budujesz jądro po prostu użyj 'make bzimage' i pozostaw skompilowane jądro tam gdzie jest. LinuxBIOS później będzie go szukał obrazu zawartego w DoC w:
/usr/src/linux/vmlinux
Zaleca się abyś stworzył swój własny plik konfiguracyjny oparty na jednym z przykładów. Następnie należy zbudować obrazy dla urządzenia DoC w innym katalogu, poza drzewem źródeł FreeBIOS. Zapewni to, że nie zostaną skasowane gdy będziesz uaktualniał swoją kopię przez CVS. Ze względu na nazewnictwo zaleca się utworzenie katalogu linuxbios identycznego z freebios i tam budowanie obrazu dla DoC:
mkdir linuxbios
cd linuxbios
cp ../freebios/util/config/NLBConfig.py .
cp ../freebios/util/config/pcchips.config .
Polecenia te kopiują program Python, który jest używany przy konfiguracji i plik pcchips.config, który powinien odpowiednio dobrany do płyty do nowego katalogu. Po skopiowaniu pcchips.config do katalogu roboczego należy dokonać w nim następujących zmian:
usunąć 'single' z końca linii komend jądra, aby LinuxBIOS ładował się do standardowego ustawienia dla wielu użytkowników.
dodać cpu k7, jeśli używasz procesora Athlon
dodać opcję ENABLE_MII=1 aby uzyskać działający ethernet
zmienić opcje HAVE_FRAMEBUFFER na HAVE_FRAMEBUFFER=1 (ma to po prostu wyeliminować późniejsze ostrzeżenia)
Może również być potrzebna edycja plików wymaganych w źródłach LinuxBIOSu - w przykładzie omawianym tutaj należało zmienić plik filefreebios/src/arch/i386/lib/hardwaremain.c - trzeba w nim było odkomentować wywołanie funkcji keyboard_on() około linii 344. Jeśli się tego nie zrobi to po ostatecznym zabootowaniu LinuxBIOSa otrzyma się wiele błędów pc_keyb: controller jammed (0xFF) i klawiatura nie będzie działać. System jednak będzie sprawny - będzie do niego dostęp poprzez porty szeregowe i przez ssh.
Po zaaplikowaniu tych zmian należy uruchomić program Python:
python NLBConfig.py pcchips.config ~/freebios
Tworzy to podkatalog w katalogu linuxbios o nazwie pchips, a w nim następujące pliki:
LinuxBIOSDoc.config
Makefile
Makefile.settings
crt0_includes.h
nsuperio.c
Gdy już masz te pliki i skompilowałeś jądro (które jest w /usr/src/linux/vmlinux) możesz uruchomić makefile aby zbudować obraz LinuxBIOSa:
cd pcchips
make clean
make
Następnie skopiuj narzędzie burn_mtd do nowopowstałego katalogu pcchips, ponieważ domyślnie to narzędzie przeszukuje katalog bieżący aby znaleźć pliki źródłowe do wypalenia urządzenia DoC:
cp ../../freebios/util/mtd/burn_mtd .
Burn_mtd to po prostu skrypt shella, jednak pliki uzyskane z make nie do końca pasują do niego - należy go przeedytować - zmienić pierwsze dwa wystąpienia 'vmlinux' (jedno w komentarzu w linii 3, drugie w linux=vmlinux.bin.gz w linii 16) na 'linux'. Kolejny krok to ściągnięcie narzędzi MTD z http://www.linux-mtd.infradead.org/ i zbudować narzędzie 'erase' - po prostu ściągnąć najnowszą wersję narzędzi jądra z sekcji ChangeLog i 'make erase' w podkatalogu util. Ostatnim narzędziem potrzebnym do programowania DoC jest flash_on z katalogu freebios/util/sis. To narzędzie pozwala na używanie gniazda BIOS z płyty głównej jako programatora flash:
cd ~/freebios/util/sis
make flash_on
Należy skopiować narzędzia "erase" i "flash_on" do ścieżki przeszukiwanej (na przykład /usr/local/sbin). Teraz przechodzimy do programowania LinuxBIOSa - usunięcia chipu BIOS i zastąpienia go DoC - to właśnie tutaj gniazdo ZIF okazuje się niezbędne.
Programowanie chipu
Przy włączonym zasilaniu i działającym systemie, należy zwolnić dźwignię gniazda ZIF, usunąć oryginalny BIOS i zastąpić go przez DoC. Należy być bardzo ostrożnym, aby włożyć DoC właściwą stroną i upewnić się, że igły są właściwie ułożone. Następnie unieruchomić DoC dźwignią gniazda ZIF. Uruchomić komendę:
./burn_mtd
powinna ona zaprogramować chip LinuxBIOSu. Output powinien wyglądać następująco:
# ./burn_mtd
rmmod: module docprobe is not
loaded
rmmod: module doc2001 is not
loaded
rmmod: module docecc is not
loaded
11+1 records in
12+0 records out
0+1 records in
1+0 records out
Erase Total 1024 Units
Performing Flash Erase of length
8192 at offset 0x7fe000 done
1+0 records in
1+0 records out
1+0 records in
1+0 records out
126+0 records in
126+0 records out
1536+0 records in
1536+0 records out
#
Jeśli na tym pojawią się zamiast tego poniższe napisy:
# ./burn_mtd
rmmod: module docprobe is not
loaded
rmmod: module doc2001 is not
loaded
rmmod: module docecc is not
loaded
11+1 records in
12+0 records out
0+1 records in
1+0 records out
File open error
dd: opening '/dev/mtd0':
No such device
dd: opening '/dev/mtd0':
No such device
dd: opening '/dev/mtd0':
No such device
dd: opening '/dev/mtd0':
No such device
#
Należy sprawdzić działające jądro: upewnić się, że zmieniło się plik /usr/src/linux/drivers/mtd/devices/docprobe.c tak by oddefiniować DOC_SINGLE_DRIVER przed budową jądra, że wybrało się opcje MTD wymienione wcześniej, i że zrestartowało się maszynę po tych zmianach tak, że to jądro aktualnie działa.
Jeśli output z burn_mtd wygląda dobrze, zrebootować maszynę i przetestować efekty. Jeśli system rebootuje się i widać pingwina w górnym rogu ekranu - powiodło się. Linux jest bootowany przez system LinuxBIOS bezpośrednio z DoC.
Nie należy się przejmować jeśli system startuje trochę niewłaściwie. Te błędy mogą być łatwo poprawione później. Ważne jest, że mamy działający kernel.
Jeśli efekty są negatywne wtedy najlepszą metodą odkrycia co poszło nie tak jest podłączenie kabla szeregowego do portu RS232 i połączenie z innym działającym systemem z emulatorem terminala takim jak minicom (ustawionym na 115200 baud, 8 bits, no parity) i zresetowanie. Powinno otrzymać się trochę informacji do zdebugowania, które pomogą w ustaleniu co poszło nie tak. Jeśli absolutnie nic się nie dzieje - jest możliwe, że nie masz właściwej wersji obrazu wypalonego na twoim DoC, należy wtedy wyłączyć komputer, przełączyć się na stary BIOS, zobaczyć, który z kroków się pominęło i zacząć od początku.
PowrótNastępną rzeczą, którą możesz chcieć zrobić, gdy twój komputer się bootuje z DoC, jest stworzenie głównego systemu plików na w pozostałej z 8MB pamięci DoC. Będziesz do tego potrzebował kilku więcej opcji MTD włączonych w jądrze podczas tworzenia systemu (do sformatowania i zapisu root fs) tym razem również w jądrze docelowym (tak by mogło czytać z systemu plików opartym na MTD). Opcje, które należy zaznaczyć są przedstawione poniżej:
Gdy już masz skompilowane jądro (pamiętaj o zainstalowaniu jądra to systemu ,na którym budujesz system, zrestartowaniu i umieszczeniu wygenerowanego jądra przez make bzimage w /usr/src/linux/vmlinux), powinieneś być w stanie sformatować partycję w pozostałym miejscu w DoC:
nftl_format /dev/mtd0 0x100000
nftl_format jest w katalogu linuxbios/mtd/util. Możesz użyć fdisk /dev/nftla do stworzenia jednej partycji głównej, zajmującej całe dostępne miejsce, a potem sformatować ją przy pomocy mke2fs /dev/nftla1 w normalny sposób. Możesz zmienić urządzenie, z którego LinuxBIOS spodziewa się ładować główny system plików modyfikując modyfikując skompilowany obraz jądra (przed wypaleniem na DoC):
rdev /usr/src/linux/vmlinux /dev/nftla1
Jeśli chodzi o to co umieścić w tak małym rootcie i nadal mieć działający system można zajrzeć na http://www.toms.net.rb/
PowrótGdy LinuxBIOS wystartuje Linux'a z NVRAM'u, kernel może podjąć następujące akcje:
Ustanowienie połączenia SSH z konfiguracją DHCP. Połączenie SSH może być znacznie bezpieczniejsze od sposobów stosowanych dotychczas. Korzysta ono również z bardziej stabilnego zachowania TCP w stosunku do podejścia UDP.
DHCP informuje węzeł o jego identyfikatorze i kieruje do jądra, które ma zabootować. Serwer DHCP może nawet przesłać obraz jądra przez połączenie SSH, a następnie może ono być załadowane przez LOBOS.
Aby móc użyć SSH potrzebujemy podstawowych funkcji, które obecnie są dostępne w różnych klientach SSH. Obecnie trwają prace nad biblioteką, opartą na źródle OpenSSH, która umożliwi obu jądrom tworzenie połączeń SSH, a za ich pośrednictwem kodowanego połączenia TCP.
PowrótDHCP może przesłać do jądra niezbędne parametry, a potem zlecić kontynuowanie ładowania. W tym przypadku kernel z NVRAM'u zostanie załadowany. Kernel ten może w dalszej części załadować inne jądro z lokalnego źródła (dysk, CDROM, etc.).
Ten przypadek jest niemal identyczny z tym co obecnie jest stosowane w węzłach klastrowych, z tą różnicą, że:
1. Sekwencja bootowania jest pod całkowitą kontrolą węzła zewnętrznego. Bootowanie będzie tak samo szybkie, ale pod większą kontrolą.
2. Wszystkie istniejące sekwencje bootowania dla węzłów klastrowych polegają na częściach ruchomych, takich jak dyskietki, CDROM'y, dyski. Sekwencja oparta na LinuxBIOS'ie opiera się na urządzeniu bez części ruchomych, to jest na NVRAM'ie z płyty głównej. Jeśli węzeł ma się zabootować z dysku lokalnego, a ten się nie zgłosi - węzeł może zgłosić to do węzła kontrolnego. Ułatwi to wyszukanie fragmentu, który zawiódł.
PowrótDHCP może polecić jądru podłączenie systemu plików przez NFS, AFS, Coda, InterMezzo, lub każdy inny sieciowy system plików. Potem kernel może kontynuować, lub załadować inne jądro z zamontowanego systemu plików.
PowrótDHCP może zlecić jądru ustanowienie portu SSH dostępnego dla zdalnego zarządzania. W takim przypadku węzeł nie wystartuje nawet /sbin/init, zamiast tego będzie czekał na instrukcje z kontroli zdalnego zarządzania. Instrukcje mogą zawierać zmiany parametrów LinuxBIOS'u, a nawet zapis nowego, testowego jądra do NVRAM'u. Jądro może nawet załadować nowy systemy plików dal root'a, lub zmienić partycje dysków lokalnych.
Zapis do NVRAM'u może zawieść - w takim przypadku musi istnieć sposób naprawy. Obecnie polega się na BIOS'owym programie naprawczym NVRAM'u. Gdy NVRAM na płytach będzie większy będziemy mogli mieć w nim dwa kernel'e - normalny i naprawczy.
Innym rozwiązaniem jest zlecenie kernel'owi otwarcia portu HTTP i zarządzanie poprzez przeglądarkę sieciową.
PowrótWszystkie standardy PC dla bootowania sieciowego polegają na netboot ROM, działającym w trybie 16 bitowym dla pakietów sieciowych I/O. Skoro LinuxBIOS ładuje prawdziwego Linux'a możemy używać bardziej wydajnych narzędzi dla procesów sieciowych, takich jak Myrinet.
PowrótSCI to to sieć oparta na pamięci i przemieszczanie danych wymaga jedynie bcopy. Gdy system się ładuje powinien zostać skonfigurowany interfejs SCI. Gdy ten już działa jądro może użyć go do powiadomienia zdalnego serwera, który bcopy'uje obraz jądra do węzła lokalnego, a ten może załadować je poprzez LOBOS. Serwer może również skopiować cały obraz ramdysku, którego następnie użyje jądro. Prędkości SCI na 32 bitowym PCI wynosi około 80MB/s więc odbywa się to w ciągu kilku sekund.
SCI ma jeszcze jedną zaletę - interfejs konfiguracyjny wymaga jedynie 128 bajtów danych i może być skonfigurowany przez zewnętrzny węzeł. LinuxBIOS nie musi ładować mikrokodu do interfejsu, tak jak robi to przy Myrinecie.
PowrótNetboot przy użyciu IP multicast'u.
Gdy cały klaster jest bootowany możemy użyć multicast'u do dystrybucji jądra i obrazów dysków. Większość obecnych narzędzi wspierających ten tryb działa pod DOS'em. W naszym przypadku dysponujemy pełnym Linux'em i możemy użyć IP Multicast'u dla większości danych, oraz otwartego gniazda TCP do odzyskania utraconych pakietów.
PowrótRozszerzenie LinuxBIOS tak aby móc bootować wiele systemów operacyjnych.
Oryginalnie LinuxBIOS koncentrował się na ulepszeniu zarządzania dużych klastrów węzłowych, jednak wielu projektantów widziało w nim możliwość zwiększenia bezpieczeństwa w stosunku do BIOS'u i dodania wsparcia dla innych systemów operacyjnych niż Linux.
Projekt SEBOS ma na celu urzeczywistnienie tych projektów.
Jak do tej pory udało się uruchomić Windows 2000, OpenBSD i Linuxa na płycie Matsonic 7308e.
Udało się to osiągnąć poprzez połączenie metod wykorzystywanych w LinuxBIOS'ie i emulatorze Bochs.
Bochs jest to emulator x86 CPU, ze zwykłymi urządzeniami I/O takimi jak dyskietka, twarde dyski oraz BIOSem x86.
Bochs został napisany w C++ przez co jest niezależny od platformy sprzętowej.
Komponentem Bochs'u, który został wykorzystany w projekcie jest Bochs BIOS. Jego następujące cechy okazały się wyjątkowo przydatne dla powyższych celów:
Żadne z urządzeń emulowanych przez Bochs nie jest implementowane w warstwie BIOSu. BIOS został zaprojektowany tak, aby porozumiewać się z urządzeniami za pomocą rzeczywistych przerwań urządzeń aby być zgodnym z aktualnymi standardami. Ta cecha była użyteczna, ponieważ niewiele zmian było wymaganych, aby dostosować Bochs BIOS do platformy sprzętowej.
Skoro sprzęt jest "emulowany" to nie musi być "włączony" tak jak w prawdziwym x86. To oznacza, że Bochs nie implementuje inicjalizacji takich rzeczy jak cache, kontrolery IDE, etc. Te usługi są już zapewniane przez LinuxBIOS dla płyt, które wspiera.
Te cechy sprawiły, że modyfikacje niezbędne dla nas w Bochs będą w pierwszej kolejności rozważane dla kolejnej jego edycji. Zmiany jakie należało zrobić w Bochs dotyczyły niemal tylko bardziej precyzyjnej implementacji przerwań z BIOSu. Po tych zmianach Bochs BIOS jest nadal kompatybilny z całym emulowanym sprzętem, pozwala to również na bardziej dokładną pracę z rzeczywistym sprzętem.
To co łączy ze sobą LinuxBIOS i Bochs BIOS to ADLO.
Zatem w tej implementacji są trzy części:
LinuxBIOS, który inicjalizuje sprzęt na wielu płytach głównych.
ADLO, które łączy Bochs BIOS z LinuxBIOSem, co pozwala LinuxBIOSowi używać
BIOSowych przerwań urządzeń dostarczonych przez Bochs. ADLO można znaleźć w
katalogu freebios/util/adlo w cvs'ie LinuxBIOSa. Instrukcje używania ADLO
znajdują się w pliku README do niego dołączonym.
Bochs BIOS dostarcza przerwań urządzeń. Każdy kto chciałby bootować Windows 2000 lub OpenBSD z LinuxBIOSa będzie również musiał ściągnąć źródła Bochs z CVS i postępować zgodnie z instrukcją dołączoną do źródeł ADLO w pliku README wymienionym powyżej.
Ponieważ Bochs BIOS jest niezależny od sprzętu, ADLO z Bochs BIOSem powinno działać na większości płyt obsługiwanych prze LinuxBIOS.
Powrót