Linux na 286?

Nie mam 286 ani nie zamierzam uruchamiać Linuksa na jednym. Jednak skoro 286 ma tryb chroniony, dlaczego często mówi się, że Linux wymaga procesora 386 lub nowszego?

Ze strony http://tuxmobil.org/286_mobile.html wydaje się, że wersja ELKS Linuksa może działać na 286, czy to prawda? Jakie (jeśli jakieś) modyfikacje zostały wprowadzone, aby jądro mogło działać na procesorze 286?

Teraz oczywiście rozumiem, że jądro skompilowane dla 386 nie może zostać uruchomione na procesorze 286, który jest 16-bitowy. Więc moje pytanie brzmi: dlaczego nie można skompilować standardowego jądra Linuksa dla 286, a następnie wykonać na 286? Czy Linux wymaga sprzętowej obsługi VM86?

Tryb chroniony 286 (PM) zasadniczo różni się od tego, co oferuje 386. Pomyśl o 286 PM jako prototypie, który miał tak wiele wad, że prawie nikt go nie używał, a całość została całkowicie przeprojektowana od podstaw dla 386.

Nie korzystał z płaskiego modelu pamięci, używał modelu segmentowego, takiego jak tryb rzeczywisty, co oznaczało, że trzeba było skakać przez obręcze, aby uzyskać dostęp do pamięci w blokach większych niż 64kB na raz.

To było całkowicie niekompatybilne ze wszystkimi dostępnymi wówczas programami (MS-DOS), więc kiedy byłeś w PM, nie mogłeś używać żadnego z programów, do których byłeś przyzwyczajony.

Nie można również ponownie opuścić trybu chronionego, dopóki nie uruchomisz ponownie komputera, więc producenci wymyślili kreatywne rozwiązania, takie jak umieszczenie flagi w pamięci RAM, a następnie zapisanie magicznej wartości na kontrolerze klawiatury, która przesunęła pin resetowania na procesorze, aby ponownie uruchomić maszyna. Pierwszą rzeczą, którą BIOS zrobiłby, to wykrycie wcześniej ustawionej flagi, w której wróciłby do oryginalnego programu zamiast uruchamiać procedurę POST, pozwalając oryginalnemu programowi na kontynuowanie działania po „wyjściu” z PM.

Oznaczało to, że użycie 286 PM uniemożliwiło uruchomienie normalnych programów DOS bez dużej liczby sztuczek. W czasach, gdy były tylko programy DOS, nie warto było w ogóle używać PM.

Tak więc praca z 286 PM była bardziej skomplikowana niż życie bez niej i poleganie na EMS i XMS w celu uzyskania dostępu do dodatkowej pamięci. Wiele 286 płyt głównych miało obsługę chipsetów dla EMS, dzięki czemu można było wykorzystać całą dodatkową pamięć systemową bez potrzeby PM.

Intel rozpoznał te niedociągnięcia i stworzył zupełnie nowy PM w 386. Płaski model pamięci ułatwia dostęp do pamięci w kawałku do 4 GB. Procesor może wchodzić i wychodzić z PM za pomocą kilku instrukcji, więc nie są potrzebne nieporęczne protokoły ponownego uruchamiania. VM86 oznacza, że ​​przez większość czasu nawet nie musisz wychodzić z PM, możesz uruchamiać programy DOS będąc w PM.

Wszystkie te ulepszenia oznaczały, że 386 PM był nie tylko bardziej funkcjonalny, ale także znacznie bardziej kompatybilny.

Innymi słowy, jedyną wspólną cechą między trybem chronionym 286 i 386 jest nazwa. Właśnie dlatego systemy operacyjne PM są zwykle 386 lub nowsze. Dodanie obsługi 286 PM byłoby całkowicie niezależnym wysiłkiem, z niewielkim kodem lub bez kodu, który mógłby być współdzielony z zupełnie innym 386 PM.

Natomiast 386 PM działa w ten sam sposób aż do ostatniego z 32-bitowych procesorów, a nawet dalej, jeśli uruchamiasz oprogramowanie 32-bitowe na 64-bitowych procesorach.

W jądrze są części napisane w asemblerze i trzeba by je przepisać, żeby obsługiwały 286.

Jeśli chodzi o ELKS, w swoich FAQ wskazują, że jest to podzbiór jądra Linuksa, więc być może przenieśli tylko absolutne potrzeby.

Myślę, że prawdziwą odpowiedzią na moje pytanie jest:

Każda większa architektura procesora (lub jego główna wersja) wymaga kodu obsługi zestawu oprócz kodu C.

Nawet jeśli GCC skompiluje jądro Linuksa do 16-bitowego kodu maszynowego 286, nadal brakuje niezbędnego 16-bitowego kodu asemblera zgodnego z 286.

Innymi słowy, jądro byłoby co najwyżej tylko częściowo zbudowane. Każdy kod asemblera specyficzny dla architektury nie skompilowałby się, ponieważ po prostu nie został napisany dla tej architektury.

Na tej podstawie zakładam, że dokładnie tak robią np. ELKS i podobne projekty, kiedy implementują Linuksa na architekturze 286 lub innych - implementują ten brakujący kod wsparcia asemblera.

80386 obsługuje stronicowanie oprócz segmentacji pamięci, podczas gdy 286 obsługuje tylko segmentację pamięci. Linux w dużym stopniu zależy od obsługi stronicowania, tzn. Używa płaskiego schematu pamięci, który zasadniczo ustawia wszystkie rejestry segmentów na 0 i używa stronicowania do zarządzania aplikacjami. Aby przenieść Linuksa na 286, podstawowy menedżer pamięci potrzebuje całkowitego przeprojektowania, aby działał w trybie segmentacji bez stronicowania, co jest prawdopodobnie dużym nakładem pracy.

Czy Linux wymaga sprzętowej obsługi VM86?

Nie jestem facetem od montażu, ale zgodnie z tym :

Ponieważ oryginalna implementacja 32-bitowego rozszerzenia architektury 8086, zestaw instrukcji 80386, model programowania i kodowania binarne są nadal wspólnym mianownikiem dla wszystkich 32-bitowych procesorów x86, jest to nazywane x86, IA-32 lub i386 -architektura, w zależności od kontekstu.

386 reprezentuje rozszerzony zestaw instrukcji z 286, więc kto wie, jak trudny byłby port. Widocznie wystarczy, że prawie nikt nie zadał sobie trudu, aby spróbować ... Chyba możesz o to zapytać ludzi ELKS.

Największym powodem jest to, że oryginalny projekt GNU skierowany był na maszyny 32-bitowe (takie jak uniksowe stacje robocze z połowy lat osiemdziesiątych), zamiast zadawać sobie trud obsługi mniejszych elementów, dlatego cały łańcuch narzędzi GNU nie był odpowiedni do generowania 16-bitowego kodu. Przeniesienie wczesnego, wymagającego dużego montażu segmentu jądra Linuksa do 286 byłoby łatwiejsze niż jakikolwiek inny cel do przeniesienia - gdyby GCC miał możliwość wygenerowania 286 kodu trybu chronionego. Ale celowanie GCC w tryb chroniony 286 byłoby ogromnym projektem obsługującym przestarzały procesor.

Ostatnio jądro Linuksa porzuciło 386 jako obsługiwaną platformę, a jądro Linux NIE obsługuje procesorów Intel 286. 80286 nie jest 32-bitową jednostką centralną, która jest wymagana do uruchomienia.

Linux x86 nie może być łatwo przeniesiony z powrotem na 80286, ponieważ jest to 16-bitowy procesor, a Linux x86 wymaga 32-bitowego procesora.

Mówiąc dokładniej, rejestry na 286 nadal miały szerokość tylko 16 bitów. Żaden rejestr EX nie był dostępny. Ponadto segmenty pamięci i przesunięcia miały nadal tylko 16 bitów. Programy nadal musiały radzić sobie z kodem i danymi blisko / daleko.

Oznacza to, że Linux / 286 potrzebuje radykalnie innego jądra i interfejsu API użytkownika niż Linux / 386. Każdy plik źródłowy zestawu i wiele plików źródłowych typu C musiałoby zostać przepisanych. To byłoby jak różnica między programowaniem dla Win16 a Win32.

Krótko mówiąc, nie możesz po prostu powiedzieć GCC, aby skompilowało się dla innego procesora. Każdy kawałek kodu musiałby zostać przepisany dla środowiska 16-bitowego.

Z tego, co przeczytałem, kanonicznym sposobem na uruchomienie Linuksa na 80286 byłoby uruchomienie go na maszynie wirtualnej. To co zrobił Fabrice Bellard tutaj . Musisz samodzielnie zaimplementować maszynę wirtualną lub przenieść ją.