Linux uruchomiony na 8-bitowym mikrokontrolerze AVR

Początkujący w dziedzinie mikrokontrolerów pytają czasem na forach, czy uda im się uruchomić Linuxa na 8-bitowym mikrokontrolerze, co zwykle wywołuje salwy śmiechu. Mówi się, że absolutnie minimalne wymagania sprzętowe dla Linuxa to 32-bitowy procesor z jednostką zarządzania pamięcią (MMU) i co najmniej megabajtem pamięci RAM na jądro systemu.

Rosyjski programista Dmitrij Grinberg postawił sobie za cel obalenie tych twierdzeń i udało mu się to - uruchomił Linuxa z jądrem 2.6.34 na mikrokontrolerze ATmega 1284p. Oczywiście zintegrowana weń pamięć (16 kB SRAM i 128 kB Flash) jest zbyt mała, dlatego Grinberg wykorzystał "antyczną", 30-stykową kość RAM SIMM, podłączając ją bezpośrednio do mikrokontrolera. Za pamięć masową służy karta SD o pojemności 1 GB (dla Ubuntu Jaunty wystarczyłaby nawet 512-megabajtowa).

To prawda, że Linux potrzebuje 32-bitowego procesora z MMU, lecz Grinberg udowodnił, że nie musi to być wcale fizyczny procesor. Zrobił rzecz zakrawającą o szaleństwo - napisał emulator procesora ARM działający na mikrokontrolerze ATmega. Emulowany procesor to ARMv5TE, taktowany zegarem 6,5 kHz.

Trudno jednak znaleźć praktyczne zastosowanie dla tego pomysłu, bo system działa przeraźliwie wolno. Samo uruchamianie od włączenia do pojawienia się znaku zachęty Basha trwa dwie godziny, a załadowanie systemu Ubuntu kolejne cztery.


Link


Źródła:
http://hackaday.com/2012/03/28/building-the-worst-linux-pc-ever/
http://dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit

Cool!

Dopiero co to widziałem na DP no i cóz - jestem pod wrazeniem...
W jaki sposob zostala wykonana emulacja ARM na AVR? Przeciez to nie ma racji bytu...

Translate post from polish to english

Quote:

6 godzin na uruchomienie systemu? Ciekawe ile lat gościu debugował ten emulator..

Przecież nie debugował linuxa tylko emulator procka. Jak przejdzie wszystkie instrukcje i podstawowe układy IO to emulator ma przetestowany.

Translate post from polish to english

Generalnie najciekawsze jest użycie starej kości ram. Czy są gdzieś w internecie materiały jak tego dokonać? Mam kilka kostek alliance AS7C256 i z miłą chęcią połączył bym je z jakąś atmegą

Translate post from polish to english

To jest Rosja, tam nie ma miejsca na błędy.
Poza tym czytaj posta wyżej, do przetestowania emulacji wystarczy jakiś program testowy, a nie cały system. ;p

Translate post from polish to english

Ruzby wrote:

Dopiero co to widziałem na DP no i cóz - jestem pod wrazeniem...
W jaki sposob zostala wykonana emulacja ARM na AVR? Przeciez to nie ma racji bytu...

Dlaczego tak uważasz? Przecież programowo można wszystko zrobić, kwestia tylko wydajności. Zwykle "mniejsze" emuluje się na "większym", bo emulacja programowa wymaga większej mocy obliczeniowej, ale że się da masz przykład w tym artykule. Jak to się robi - najprościej - masz "programowy procesor" i każdą instrukcję obrabiasz na bieżąco (tylko to najmniej wydajna metoda).

Translate post from polish to english

AVE...

Jak dla mnie to sztuka dla sztuki. Ciekawe, jakby to się spisało na jakimś szybkim 8051...

Translate post from polish to english

Nie bardzo łapię rozgraniczenie

2 godziny - znak zachęty z Basha (jedna z wielu powłok systemu Linux)
4 kolejne godziny odpalanie systemu Ubuntu ??, w sensie odpalanie czego ? Co autor miał na myśli?

Translate post from polish to english

Dowolny program możesz odpalić podając do lini poleceń jądra init= np. init=/bin/bash i masz pominięty cały init, tj. bash jest wykonywany jako init.

A co do ubuntu pewnie chodzi o wykonanie się skryptów startowych oraz wyświetlenie prośby o login.

Translate post from polish to english

felixd wrote:

Nie bardzo łapię rozgraniczenie

2 godziny - znak zachęty z Basha (jedna z wielu powłok systemu Linux)
4 kolejne godziny odpalanie systemu Ubuntu ??, w sensie odpalanie czego ? Co autor miał na myśli?

Tego można się łatwo domyślić, jeśli kiedyś próbowałeś budować system od
zera (z tarballi) pod kątem działania na sprzęcie low-end: wywoływanie init,
skryptów startowych i login żre trochę czasu (i RAMu), a nie jest konieczne
do działania systemu. (Ok, powłoka też absolutnie nie jest niezbędna, jednakże
poza zastosowaniami embedded *niewiele* osób korzysta z linuxa bez powłoki. )
2h jeśli bash jest wywoływany bezpośrednio przez argument "init" podany jądru
przy starcie, a kolejne 4h jeśli Ubuntu ma być załadowany normalnie (init, login,
etc.).

Wygląda na to, że facet jest uparty, bo X Window system też próbował uruchamiać
(i to na 24 MHz ATmedze... podziwiam. Ciekawe tylko, co miał na myśli
przez "a lot longer" - dobę? dwie? )

Translate post from polish to english

Wydaje mi się, że ten emulator 32-bitowego procesora na 8-bitowym AVR jest bardzo nieoptymalny, bo skoro taktowany zegarem 24MHz procesor emulował inny pracujący z szybkością 6,5kHz to łatwo policzyć, że na jeden takt tego emulowanego przypadało średnio 3690 taktów zegara AVR-a.

Translate post from polish to english

AVE...

Średnio tak. Ale to się liczy trochę inaczej. Proste instrukcje da się emulować w kilku linijkach kodu. Skomplikowane mogą wymagać nawet kilkunastu tysięcy. Ciekawe, czy dałoby się zrobić emulację 32-bitowego procesora łącząc cztery lub więcej ośmiobitowych mikrokontrolerów równolegle...

Translate post from polish to english

exti wrote:

Początkujący w dziedzinie mikrokontrolerów pytają czasem na forach, czy uda im się uruchomić Linuxa na 8-bitowym mikrokontrolerze, co zwykle wywołuje salwy śmiechu.

Pytają bo nie wiedzą. Życie uczy, że tak długo coś jest niemożliwe dopóki ktoś kto o tym nie wie, po prostu to zrobi. Także:

Urgon wrote:

Ciekawe, czy dałoby się zrobić emulację 32-bitowego procesora łącząc cztery lub więcej ośmiobitowych mikrokontrolerów równolegle...

Jest kwestią czasu.

Translate post from polish to english

komatssu wrote:

Wydaje mi się, że ten emulator 32-bitowego procesora na 8-bitowym AVR jest bardzo nieoptymalny, bo skoro taktowany zegarem 24MHz procesor emulował inny pracujący z szybkością 6,5kHz to łatwo policzyć, że na jeden takt tego emulowanego przypadało średnio 3690 taktów zegara AVR-a.

Ale pamiętaj, że każdy cykl do pamięci trzeba 'ręcznie' wygenerować na portach (tak rozumiem to zdanie o bezpośrednim podłączeniu do atmegi), a to SIMM - multipleksowane adresy, odświeżanie (a to musi działać dostatecznie często). I jeszcze zasymulować translację adresów w MMU.

Translate post from polish to english

Teoretycznie układ bezwartościowy - bo i po co to komu, zerowa wydajność etc. Ale jak znajdę czas, sam go zbuduje, dla czystej satysfakcji uruchomienia Linuksa na 8 bitowym mikrokontrolerze .

Translate post from polish to english

MrDarkenRahl wrote:

Teoretycznie układ bezwartościowy - bo i po co to komu, zerowa wydajność etc. Ale jak znajdę czas, sam go zbuduje, dla czystej satysfakcji uruchomienia Linuksa na 8 bitowym mikrokontrolerze .

To zaemuluj x86 oraz najważniejsze peryferia PC-ta i uruchom Windows.

Translate post from polish to english

Wyobrażasz sobie ładowanie się Windowsa na takim sprzęcie? Zdąży zawiesić się 10 razy. Podczas jednego uruchomienia.

Translate post from polish to english

Dlaczego zaraz windowsa myślę, że taki dos 2.0 to już było by coś

Translate post from polish to english

Projekt wcale nie jest bezsensowny. No, może emulacja takiej architektury mija się z celem, ze względu na wydajność (mimo wszystko dla samego pomysłu i udowodnienia, że się da to jak najbardziej). Można próbować emulować coś mniejszego, np. tak jak tutaj Z80: http://spritesmods.com/?art=avrcpm&page=1
Jak pisze autor, czas od włączenia urządzenia, do gotowości systemu wynosi 30 sekund. Jednak gdyby użyć przykładowo SRAM zamiast DRAM, podłączając go bezpośrednio pod szynę CPU można by zyskać dużo na wydajności. Można też próbować stworzyć coś bardziej skompilowanego jak JIT, który cacheuje wykonywane instrukcje i potem wykonuje je bez analizowania opcodów.

Translate post from polish to english

Fajne. Pokazuje że można zrobić coś z niczego. Chodzi to jak stare kompy. Ciekawe jak zareagował autor że mu to w ogóle ruszyło Wielki szacun dla niego.

Translate post from polish to english

Satysfakcja z tego że się coś potrafi i się to zrobi jest niesamowita, tak jak u nas jak i w Rosji jest masa ludzi którzy posiadają niesamowite umiejętności i samozaparcie aby tworzyć wiele ciekawych rzeczy tylko mało jest takich ludzi którzy chcą takich "wariatów", dać im warunki i perspektywy dla rozwijania samego siebie a i przy okazji robienia czegoś pożytecznego zamiast tracić masę czasu dla sztuki dla sztuki.chociaż robienie "bezsensownych" projektów nie jest wcale złe każdy chciał by robić to co lubi bez jakichkolwiek nacisków z otoczenia. Gościu poszedł pod prąd, wszyscy emuluja stare 8 bitowe architektóry na nowoczesnych 32 bitowcach lub FPGA a on na odwrót, jeszcze raz oddaję podziw za pomysłowość i samozaparcie w realizacji takiego pomysłu.

Translate post from polish to english

Tutaj użyto atmegi 1284 która ma 16kb ram i kości ram, jakiej ona jest pojemności?
Czy zamiast tego można użyć atmegi 328 i zewnętrznego ram 512kb? Coś takiego:
http://hackaday.com/2011/09/05/upgrading-ram-in-an-arduino-mega/

Translate post from polish to english

Ja obecnie kombinuję z połączeniem 2 kontrolerów aby pracowały równolegle.
Jeden do renderowania grafiki, drugi do pozostałych rzeczy (peryferia, wyświetlanie na LCD itd).
Buforem pośrednim są 2 kości ram i z nich pozyskują sobie informacje. Gdy jedna jest zajęta, układ czyta/pisze do drugiej i odwrotnie.

Ale to początki projektu, ale fakt faktem da się 2 kontrolery zaprzęgnąć do jednej pracy, wystarczy instrukcje podzielić na 2 kontrolery lub zrobić 2 identyczne które będą pobierać rozkazy z kolejki. Tzn jeden pobiera rozkaz i go analizuje a następnie drugi pobiera i analizuje. Po zakończonej analizie wynik jest zwracany według kolejności pobrania rozkazu.
Przy zastosowaniu oddzielnym pamięci RAM na każdy kontroler, można sporą wydajność zyskać.
Gdy jeden kontroler analizuje jakąś instrukcję dość długo, drugi może przetworzyć np. 5 kolejnych i wyniki zwrócić do RAM'u. Po zakończeniu pracy 1 kontrolera i zwróceniu wyniku, drugi lawinowo zwraca wyniki tych 5 instrukcji wykonanych w między czasie.

szymon122 wrote:

Tutaj użyto atmegi 1284 która ma 16kb ram i kości ram, jakiej ona jest pojemności?

Kość ma 16 MB pojemności.

Translate post from polish to english

... z ktorej wykorzystane jest 8 MB

Translate post from polish to english

jestem pod wrażeniem

ale nie mógł uruchomić uCLinux? który nie wymaga MMU? odpadłaby emulacja MMU, wydajność byłaby wyższa...

Translate post from polish to english

Ruzby wrote:

Dopiero co to widziałem na DP no i cóz - jestem pod wrazeniem...
W jaki sposob zostala wykonana emulacja ARM na AVR? Przeciez to nie ma racji bytu...

Juz tlumacze w czym rzecz:

ARM to procesor oparty o architekture RISC. Architektura RISC ma to do siebie iz uzywa zaledwie kilkunastu instrukcji - tak wiec bardzo latwo napisac jej emulator: bo potrzeba zaimplemetowac jedynie kilkanascie instruckcji, zamiast kiludziesieciu/kilkuset jak w architetekturach CISC (x86).

Ten projekt to cudowny przyklada dlaczego architektura RISC ma sens: bo jest tak prosta ze mozna ja zaemulowac na dowolnym, nawet bardzo wolnym procesorze w opartym o egoztyczna architekture.

Pozdrawiam i przepraszam ze odswiezanie starego tematu.

Translate post from polish to english