logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Linux uruchomiony na 8-bitowym mikrokontrolerze AVR

exti 28 Mar 2012 22:18 21856 28
  • 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.





    Ź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

    Fajne? Ranking DIY
    O autorze
    exti
    Poziom 32  
    Offline 
    exti napisał 2419 postów o ocenie 164, pomógł 10 razy. Mieszka w mieście Wrocław. Jest z nami od 2008 roku.
  • #2 10731184
    Ruzby
    Poziom 19  
    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...
  • #3 10731190
    Konto nie istnieje
    Konto nie istnieje  
  • #4 10731230
    krru
    Poziom 33  
    Cytat:
    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.
  • #5 10731245
    Konto nie istnieje
    Konto nie istnieje  
  • #6 10731324
    mkpl
    Poziom 37  
    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ą
  • #7 10731332
    To_Ja92
    Poziom 14  
    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
  • #8 10731530
    ezbig
    Poziom 20  
    Ruzby napisał:
    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).
  • #9 10731776
    Urgon
    Poziom 38  
    AVE...

    Jak dla mnie to sztuka dla sztuki. Ciekawe, jakby to się spisało na jakimś szybkim 8051...
  • #11 10731941
    milyges
    Poziom 12  
    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.
  • #12 10731952
    LemingAnadyrski
    Poziom 11  
    felixd napisał:
    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? :-))
  • #13 10732005
    komatssu
    Poziom 29  
    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.
  • #14 10732197
    Urgon
    Poziom 38  
    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...
  • #15 10732242
    Atreyu Makiavel
    Poziom 34  
    exti napisał:
    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 napisał:
    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.
  • #16 10732999
    krru
    Poziom 33  
    komatssu napisał:
    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.
  • #17 10733067
    MrDarkenRahl
    Poziom 13  
    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 :).
  • #18 10733426
    krru
    Poziom 33  
    MrDarkenRahl napisał:
    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. :)
  • #19 10733448
    MrDarkenRahl
    Poziom 13  
    Wyobrażasz sobie ładowanie się Windowsa na takim sprzęcie? Zdąży zawiesić się 10 razy. Podczas jednego uruchomienia.
    :P
  • #20 10733570
    mkpl
    Poziom 37  
    Dlaczego zaraz windowsa myślę, że taki dos 2.0 to już było by coś
  • #21 10734010
    ja.czekanski
    Poziom 13  
    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.
  • #23 10735234
    REVISOR
    Poziom 25  
    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.
  • #24 10736952
    szymon122
    Poziom 38  
    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/
  • #25 10737500
    ADI-mistrzu
    Poziom 30  
    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.
  • #27 10741364
    Ruzby
    Poziom 19  
    ... z ktorej wykorzystane jest 8 MB
  • #28 10782399
    mlody_elektronik
    Poziom 27  
    jestem pod wrażeniem :)

    ale nie mógł uruchomić uCLinux? który nie wymaga MMU? odpadłaby emulacja MMU, wydajność byłaby wyższa... :)
  • #29 11165786
    hans512
    Poziom 15  
    Ruzby napisał:
    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.
REKLAMA