Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Advanced Search
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Linux uruchomiony na 8-bitowym mikrokontrolerze AVR

exti 28 Mar 2012 22:18 21466 28
Computer Controls
Reply Cool? Ranking DIY | New topic
Notify about new articles
  • 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

    Cool? Ranking DIY
    About Author
    exti
    Level 32  
    Offline 
    exti wrote 2419 posts with rating 156, helped 10 times. Live in city Wrocław. Been with us since 2008 year.
  • Computer Controls
  • #2
    Ruzby
    Level 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
    User removed account
    User removed account  
  • Computer Controls
  • #4
    krru
    Level 33  
    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.
  • #5
    User removed account
    User removed account  
  • #6
    mkpl
    Level 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
    To_Ja92
    Level 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
    ezbig
    Level 20  
    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).
  • #11
    milyges
    Level 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
    LemingAnadyrski
    Level 10  
    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? :-))
  • #13
    komatssu
    Level 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
    Urgon
    Editor  
    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
    Atreyu Makiavel
    Level 34  
    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.
  • #16
    krru
    Level 33  
    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.
  • #17
    MrDarkenRahl
    Level 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
    krru
    Level 33  
    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. :)
  • #19
    MrDarkenRahl
    Level 13  
    Wyobrażasz sobie ładowanie się Windowsa na takim sprzęcie? Zdąży zawiesić się 10 razy. Podczas jednego uruchomienia.
    :P
  • #20
    mkpl
    Level 37  
    Dlaczego zaraz windowsa myślę, że taki dos 2.0 to już było by coś
  • #21
    ja.czekanski
    Level 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.
  • #22
    1996arek
    Level 20  
    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 :D Wielki szacun dla niego.
  • #23
    REVISOR
    Level 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
    szymon122
    Level 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
    ADI-mistrzu
    Level 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.
  • #28
    mlody_elektronik
    Level 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
    hans512
    Level 15  
    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.
Reply Cool? Ranking DIY | New topic
Notify about new articles
Popular Topics