tryby rzeczywistości 4/9 #Różnica między BIOS a UEFI;
//wróć do spisu treści; tekst jest fragmentem większej całości;
#Różnica między BIOS a UEFI;
Klocek który wystartowaliśmy (to duże na nóżkach; z radiatorem) dawniej nie miał jakoś tak fizycznie wydzielonej części do startu (początkowo nie miał żadnych innych części), po prostu nie cały klocek się od razu zapalał, trzeba było wykonać szeregu operacji uruchamiających kolejne rozszerzenia (układy, szyny 32 i 64). Ponieważ ten proces ogarnięto to w obecnych klockach ten archaiczny duperel startowy 16bit trybu rzeczywistego (czy jego równoważnik dla dowolnego układu, logicznie robi to samo – sprawdza czy ma wszystko na miejscu, czy mostki doprowadziły prąd do zegarynki, do magistral, czy jest z kim gadać) jest spakowany jako Boot Strap Processor i wydzielony w układzie klocka (znaczy fizycznie można go obejrzeć, że jest on tu i tylko tu; bo odkomplikowano tę gmatwaninę, rezyduje ona z przyczyn kompatybilności wstecznej; dziedzictwo takie). Procesory aplikacji (AP) do pozostałej logiki będą dopiero obudzone. Nawet gdyby zmienić architekturę to i tak logika wstawania każdego klocka będzie taka sama, sprawdź rejestry, sprawdź logiki. Każdy rdzeń i tak będzie to robił u siebie na takiej szynie danych jaką ma. GPU też to musi zrobić. Hierarchia klocków i ich wstawaniem różni się tylko tym, kto ma przełącznik uruchamiający “moją” architekturę no i na końcu jest użyszkodnik mający dwubitowy włącznik prądu. Oczywiście na płycie są zestawy czipsów, które sterują czymś i też muszą wstać, ale z punktu widzenia In/Out nie robią nic, dopóki procesor nie dojdzie do etapu wydania im imperatywu Out i uruchomienia ich sekwencji startowej (albo jej wymuszenia własnym kodem, co wcześniej było praktykowane). Dowolny hopsztylion klocków spięty razem i tak odwołuje się zawsze do Pana, który trzyma nad nimi dwubitowy przełącznik “żyj/nie”. A to że prąd płynie z zasilacza i przetworników to tylko gotowość na użycie tego przełącznika.
Ta różnica między BIOS a UEFI to szybkie przejście w POST na fninit (wariant 32 tutaj, 64 później), czyli komendę uruchamiającą FPU (32/64bitowe CPU ze sprzętowymi operacjami na float, które są rozbijane z 32 na 80 bitowe liczby do tej operacji, tryb long dla double wymaga tam 128 bitowego przetworzenia 64 bitowego floata na potrzeby przetworzenia w ALU, a high precision mając również 256 i nawet 512 bitowy rejestr w pętli ALU przy czym tego na razie UEFI nie będzie używać, przyjmijmy, że jesteśmy w chronionym 32bity dla niekomplikowania bo mamy dostępne rejestry rozszerzone A i B, EAX i EBX, a 64 bitowych RAX i RBX jeszcze nie; i przejście do protected mode 32bit czyli wyłączenie przerwań naszego real; załadowanie GDT, który opisuje segmenty pamięci do adresowania, 4GB dla 32 bit i przypisaniu im flagowania crN, oczywiście na początku wypada, żeby było cr0 r/w [patrz #Konstytutka] bo będziemy to dopiero rozdzielać kto ma flagę, że mu wolno, a komu tylko czytać, a komu po łapkach; tutaj też ustawiamy rozdzielczość tej pamięci, tak żeby docierając do komórki dalej działała nam szyna adresowania fizycznego na 20 kabelkach, po prostu przypisujemy całe paczki takich referencji do klocków osadzonych w gnieździe na płycie; te pierwsze kabelki wożące bity nad 16 tylko rozdzielają nam do którego stosu cegieł/miasta się wybieramy, adres stosu cegieł/domu i pokoju dalej leci po 20 kablach 16bit; ustawienie bitu flagującego, że jesteśmy na 32; ustawienie uprawnień cr0 dla 32 bitowego rejestru – znaczy wolno mu; to są takie uprawnienia bitowe, i jest tego cały szereg przełączników jak zworki, które ustawiają SMEP, SMAP i pozostałe mycelia nawet jeśli ich nie ma na pokładzie, bo są nieustawione przez OS, którego jeszcze nie uruchomiliśmy, abstrakcji do nich brakuje) co wcześniej było komponentem (mycelium w czasach BIOS), a obecnie grzecznie zakładamy, że w klocku to jest. Jak nie ma to nigdzie nie jedziemy. BIOS może nad brakiem FPU przejść do porządku dziennego i pojechać w 16bitach. Tak samo jeśli nie uruchomi się MMX – to też mycelium.
UEFI też inaczej ogarnia IVT, ładuje szkielety sterowników DXE, to w zasadzie to samo (logicznie nie robi nic innego) tylko chodzi w większych paczkach. No i pętla EFI jakoś tam przypomina szkielet OS (powiedzmy, że to taki przerośnięty BIOS, gdzie zamiast Ponga czy civ1 odpalamy obsługę na większej liczbie warunków, bo mamy długi rejestr więc możemy sobie zaadresować wincyj pamięci i o więcej rzeczy pytać, a nawet trzymać dłuższe odpowiedzi. Podstawową różnicą jest jednak takie zagospodarowanie tego dobrobytu, żeby z pamięci wczytywać całe sekwencje (pociągi) sygnału, który od razu trafia do rejestru instrukcji i pamięci (jeśli rozgrzebiecie programowanie starych maszyn przemysłowych, to jest to linika formatowana funkcja tab argument1 tab argument n tab…) przy czym tu jawnie ograniczono liczbą bitów. Abstrakt takiej sekwencji można nazywać stosem poleceń do wykonania. Zazwyczaj dyskutując o bardzo podstawowym robieniu klocka w konia mówimy o właśnie o majstrowaniu przy zawartości i porządku tego zestawu jakby był czymś rzeczywistym, ale nie jest to struktura pierwotna. To taka ściąga jak lista zakupów, kiedy kobita wysyła choopa po mleko (i musi napisać w które uliczki w markecie skręcić oraz jak trafić do kasy po sprawdzeniu stanu, że mleko jest w ręce; bo to mliko to nie wiadomo gdzie jest, wszystkie rzeczy, po które samiec może wyruszyć samodzielnie do sklepu są od razu przy kasie pod czujnym okiem sprzedawcy).
W EFI mamy też napisane sterowniki (takie standardowe, powiedzmy jako takie żeby się USB odpaliło, bo tam może być boot). No i wypada odpalić odpowiednik CMOS (NVRAM). Wszystko nazywa się niby inaczej, ale robi dokładnie to samo tylko na bogatszej architekturze, która wcześniej była opcją, a obecnie uznajemy, że jest w standardzie. A jak nie USB to duże dyski (GPT) i szukanie ewentualnego sektora rozruchowego pod BIOS (MBR) gdyby nekromancją trzeba było się zająć.
Jeśli napiszecie sobie Ponga w EFI to będzie działała nawet mysza (w BIOS nie ma) i jakiś pixelart. Nie tylko tryb tekstowy. Oczywiście admini od razu popukają się w czoło “do czego jest cokolwiek ponad tryb tekstowy” no i należy wyrazić zrozumienie.
Co w UEFI może pójść nie tak… jak widzicie “sterowniki” EFI są kopiuj wklej, więc jeśli coś nie działa (a nie ma testu bo nie jest to krytyczne) to nie piśnie brzęczykiem. Jeśli macie dziwną, zmodyfikowaną płytę główna, albo sterownik w EFI jest źle naskrobany – sprawa leży. Oczywiście jest problem – jest rozwiązanie, w EFI możecie mieć zamiast całego boota wrzucony kod EFI do testu sprzętu i sprawdzania In/Out jak urządzeniem sterować (co przyjmuje, co zwraca). No i oczywiście te “sterowniki” to nie jest pełna funkcjonalność urządzeń. Tylko to samo co w IVT – ściągawka do nawiązania komunikacji.
Dawniej to co robi UEFI robił dopiero kernel podnoszący OS. Czyli podłączał nam pamięć, akcesoria i myclia wyrosłe na płycie. Można więc przyjąć, że UEFI jest takim OS. Istotne jest GDT – czyli adresowanie pamięci. Ono ciągle pozostaje wprost fizyczne, ale już w ramach UEFI można przypisać abstrakty (stronicowanie) choć przy inicjalizacji to jest zapis odkąd dokąd w ogóle ten RAM mamy. Na tym etapie cr0 zajmuje się adresowaniem fizycznym i w żadnym razie się to nie zmieni w dalszym procesie, po prostu przed tym procesem wejdzie nam kilka sprawdzeń, które będą kierowały do wykonania na fizycznym adresowaniu przez abstrakcję stronicowania, sprawdzenia uprawnień i pozostałych paper please co komu wolno.
Uruchomienie trybu 32bit, czyli rozszerzenie rejestru bitowego dla klocka (on przecież cały czas działa, tylko się nie używa) to przesunięcie uprawnień cr0 dla rejestru a i b (eax i ebx), czyli że klocek może teraz pisać nie po 20 kablach, a po 36, i jak włączymy rax,rbx to po 48 co zwiększy tam dalej liczbę cegieł podzielonych w zgrabne stosiki. Bo zgaduję że sam twardy dysk macie obecnie nieco większy niż 4giga? Tak odrobinkę? Oczywiście da się ogarnąć duże paczki z poziomu 32bit, tylko z inną granulacją, trzeba wybierać dane w bardzo dużych paczkach i rozkładać do 4gigowych przechowalni zapisując już jako oddzielnie wyjmowalne kawałki, bawiąc się w buchalterię i archiwistykę. Nie że się nie da, tylko łatwiej jest to zautomatyzować po większej liczbie kabli.
Czyli raczej UEFI po zmacaniu kontrolera pamięci IMC (in/Out – przyznaj się!) wybiera czy odpalać się w trybie chronionym 32 czy długim 64. Procedura ta sama, tryb długi sponsoruje literka R, więc do większości nazw będzie gdzieś podmienione E na R lub dodane R (GDT -> GDTR). Reszta jest jak patrz wyżej z uwagami, że mamy cały makaron kabli podpięty i używany. Ponieważ tryby są ekskluzywne tylko warunkowo (pisałem na początku – nikt nie broni) to żeby informację o tym gdzie jesteśmy w abstrakcji zachowuje się we flagach (deskrytpory trybu) i sprawdza, żeby ignorować polecenia niewłaściwego trybu. Czyli jak pod 64 bitowym system odpalicie program skompilowany na 32 bity bez alternatywy, czyli próbujący się odwołać do eax zamiast do rax to aniołek, którego poprosiliście aby Wam o tym przypominał zignoruje polecenia. Oczywiście możecie tego flagowania nie włączać i dalej mieć działające programy 16 i 32 bit na 64 bitowej architekturze, ale… musicie po pierwsze obsłużyć nadpisywanie pustek w rejestrach, bo inaczej wjedzie Wam w starsze bity poprzedni stan rejestru, nienadpisany. Po drugie raczej nie odpalajcie zmiennoprzecinkowych, ponieważ położenie bitowe znaku, cechy i mantysy ma swój standard sprzętowy dla rozkodowania zmiennoprzecinkowego wewnątrz ALU i możecie uzyskać rezultat jak najbardziej poprawny, tylko nie o taki, o który Wam chodziło. No chyba, że planujecie zrobić coś wyjątkowo perfidnego (CPU w konia, jaki jest każdy widzi) i tak pokierować zwrotkami z operacji, aby zostały obsłużone w trybie cr0 w sposób wyjątkowo nieprzewidziany w dokumentacji zmieniając (demolując) ustawienia (oczywiście zabezpieczeń) przed takimi działaniami, które planujecie w kolejnych krokach swego szczwanego planu.
Dlatego właśnie hierarchia jest tak stworzona, żeby było to jak najtrudniej zrobić i mimo to klocek coś jednak wykonywał. O wiele prościej by było gdyby klocek od razu wstawał jako 64 czy 128 bitów beż żadnych stanów pośrednich, działał tak i tylko tak, no ale kompatybilność wsteczna ma swoje wymagania. I z tej kompatybilności tyle zachodu, pilnowania co kto odwala i czy mu wolno, a wyłączanie tych zabezpieczeń (flagowania) jest uznawane za zachowanie co najmniej niestosowne. Prędzej czy później i tak dojdzie do wymiany architektury na taką, która legacy nei obsługuje, ale do tego musi nazbierać się dość nierozwiązywalnych problemów, aby taki dyktatorski zapęd zrealizować. Na razie jeszcze lecimy.
Tryb 64 ustawi nam jeszcze uproszczenie dla odnoszenia się do cegieł RAMu. Wyjściem jest mapowanie liniowe, wprost (takie, które Tygrysek lubi najbardziej, bo mieści się w jego małym rozumku), ale żeby jakoś ten (za chwilę zmieniający się) burdel płonący ogarnąć to stawiani są skrybowie (aniołki takie) trzymające tablice PML4 (w której tablicy szukać), oraz PDP, PD, PT (gdzie to fizycznie się klei z magazynem, znaczy które kable podpiąć, czyli ten adres co go tygrysek lubi). No i włączy mycelia (EFER – rozszerzony rejestr myceliów uruchomiono) flagując gdzieś na początku pamięci. Odtańczy jeszcze co zrobić z obsługą 32 bitową (czyli jak to rozumieć), żeby w razie czego przyjmować obsługę eax jeśli taki rozkaz padnie, ale przesuwać bity kasując starsze w rejestrze (jak to wyłączycie^^) i podobne cuda dla pozostałych emulacji trybu dla przesunięć bitowych ze starszych standardów na te najbardziej rozszerzone, które ma na pokładzie.
Różnica trybu rzeczywistego i longa dotyczy głównie kopania się z modułem 80 bitowym dla floatów. Long SSEn używa, rzeczywisty musi się prosić z taką częścią klocka x87, do której wycieczka z 16 bitów to kilka cykli ładowania rejestru. Znaczy da się, ale jak chcecie z cpu robić grafikę na cały ekran to będzie pokaz slajdów. W kontekście obsługi RAMu chodzi o włączenie do macierzy Niemiec Wschodnich (szyny DDR) co wymaga kontrolera pamięci, który w EFI jest na pokładzie (chyba, że kazaliście inaczej).