Ubuntu bootolás 8 bites mikrokontrolleren?

 ( trey | 2012. március 31., szombat - 12:56 )

Dmitry Grinberg blogjában arról számol be, hogy sikeresen bootolt be egy 8 bites mikrokontrolleren Linuxot. Pontosabban Ubuntu-t. A hacker szerint nem csak parancssorig képes eljutni. Aki türelmes, akár X + GNOME felületet is kaphat (2 óra a bash promptig single módban, plusz 4 óra a login-ig, de ha valaki X-et is akar, akkor jóval többet kell várnia).
Általában elmondható, hogy Linux futtatásához minimum kell egy MMU-val rendelkező 32 bites CPU és legalább 1MB RAM, hogy elférjen a kernel. Dmitry megpróbálta lejjebb vinni a határokat. Írt egy ARM CPU emulátort a ATmega1284p-hez és arra varázsolta rá a Linuxot. Vagy legalábbis ezt állítja.

Részletek a blogbejegyzésben.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ez egy állat! :)

Majd mindjárt jön Erendis42 és jól megmondja, hogy ez időpazarlás volt, nem ezzel kellett volna foglalkoznia... :)

ezt én akartam.
illetve kéne pic32-re is, nem kéne mplab-bal szopni:-)

Abban mi a kihívás? MIPS32 mag van benne.

hja, meg egy mega ram.

Ezen én is gondolkoztam. Linuxból van mips port, lehet csak a memóriakezelés kellene megpiszkálni, de azt nagyon ;-)

MPLAB X-et próbáltad már?

Hat van non-MMU Linux is, ha nagyon kell ...

Szerintem nem csak az a gond, hogy nincs MMU, hanem az is, hogy nagyon kevés RAM van benne. Igaz, 32-bittel 4 GB-ot lehet címezni, de fizikailag csak 128 kB van benne, és nem lehet külsőleg közvetlenül címezhetőleg hozzárakni. Az IO portokon vagy a párhuzamos porton (PMP) természetesen lehet külső RAM-ot hozzákötni, de azt bonyolultabb elérni.
Azt kéne megoldani, ha valaki olvasni akar mondjuk a 0x2A2A2A2A címről, akkor a proci ténylegesen ne onnan olvasson, hanem olvassa be a külső memóriáról a PMP segítségével az adatot a belső memóriába, majd az utasításnál cserélje ki a 0x2A2A2A2A-t, arra a címre, ahova a belső memóriába beolvasta a külső emóriában lévő adatot.

Mondjuk ha a Microchip visszarakná az MMU-t (és az FPU-t (ami uC-es környezetben sem ártana)) és megcsinálná, hogy valahogy rá lehessen kötni külső memóriát, akkor egy egész kis pofás linuxot futtató SoC/uC/proci -t kapnánk.
(Bár akkor már ugye van ARM, amiből van GHz-es tartományú is, lehet nem lenne értelme. Esetleg hobbistáknak jól jönne, akik nem tudnak/akarnak BGA-t forrasztani.)

Az önkínzásra sejtésem szerint vannak egyéb módok is. :-)

Pedig annyira nem veszesen rossz a koncepcio. Beleneztem a kodba es siman lehetne javitani rajta annyit, hogy picit erosebb 8b-eseken hasznalhato sebesseggel fusson egy minimalista linux.

Ez nagyon tetszik. 8 bites CPU-ra portolni a Linuxot vajon nem lenne kisebb szopás? Végül gyorsabban futna, talán még élvezhető is lenne. Ha már egyszer emulátorral sikerült, még akár az emulátorral is lehetne egy egyszerű bináris->bináris fordítót csinálni.

--
joco voltam szevasz

Nem, sokkal tobb szopas lenne.

Időzíthette volna április 1-re :D

Ugyanilyen mikrokontroller van az Arduino Mega-mban

Hát erre nincs más szó, ez tényleg egy állat :D Ez még Bellard böngészőben futó linuxánál is nagyobb állat!
De azért látom egy kis plusz ram még így sem ártott neki... :) Érdekes lenne a mikrokontrollerben lévő 16 kbyte sram-al :)
Kíváncsi vagyok meddig lehet még levinni az igényeket, pl. a következő talán már egy attiny lesz? :)

Figyelembe véve, hogy az alapvető problémát (hardveres hiányosságok) nem a Linuxban oldotta meg, hanem egy emulátorral megkerülte...

...ezzel a módszerrel gyakorlatilag bármeddig.

----------------
Lvl86 Troll - Think Wishfully™

Mikor fog bootolni az első 2 bites relés "számítógépen" futó AVR emulátoron futó ARM emulátoron futó linux? :-)

Hardware-dolgokban nem sok a tudományom, de úgy tudom a C-64 is 8 bites gép. Akkor reménykedhetem benne, hogy egyszer majd azon is Linux fog futni?
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Igen, megoldhato lenne, de meg ennel is lassabb lenne.

Amugy letezett egy LUNix nevezetu UNIX-like OS is C64-re.

@@
"You can hide a semi truck in 300 lines of C."

És a reboot vége egy SYS 64738 lesz. ;)

SYS $FCE2
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

Ezt nem tudom, hogy hol almodtad, de egyik assemblerben sem talaltam igy hirtelen SYS hivast. :)
A $hivatkozast sem ismeri a basic 2.0 :)

Tehat, klasszikusokat, vagy pontosan, vagy sehogy.
Mondjuk igy:

4C E2 FC JMP $FCE2

Ertem?
Minden mas assemblerben, monitorprogramban eleg egy jmp $fce2 is. :)
Okoska. :D

Ebben neked természetesen igazad van, csakhogy annak idején amikor még a C-64-el foglalkoztam, készítettem egy Basic-bővítést, amely már felismerte a $ előtéttel jelölt hexadecimális számokat, s emiatt írtam így. Igazság szerint ez az egyetlen dolog amit nem szeretek a C nyelvben: hogy ott a hexa számokat 2 karakterrel jelölik, a 0x-el, s nem egyetlen jellel, a $-ral, amit pedig úgy megszoktam még anno a C-64 korában.

De a Basic-bővítésem bináris számokat is tudott kezelni, azoknak a % jel volt a bevezető karaktere, pld %1101

A Basic-bővítésem különben képes volt akár számított ugróutasítások és szubrutinhívások végrehajtására is, simán lehetett benne pld ilyesmiket írni:

goto 3*A+200

De volt benne feltételes NEXT utasítás is, ilyesféle hogy pld:

next(A>B)

Ez azt csinálta, hogy ha a zárójelben megadott feltétel igaz volt, akkor kiugrott a ciklusból, azaz a next utáni utasítás végrehajtását kezdte el, ha ellenben a feltétel hamis volt, akkor folytatta a ciklust. Meg még nagyon sok cool utasítás szerepelt a Basic-bővítésemben. Régi szép idők!

-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#

"a C nyelvben: hogy ott a hexa számokat 2 karakterrel jelölik, a 0x-el, s nem egyetlen jellel, a $-ral"

#define $ 0x

Problem solved.

Szerk: na jó, nem működik, de most már érdekelne egy működő megoldás. ;)

de most komolyan... Mi a feneert szamit, hogy 0x vagy $?

Megszokás kérdése, én pl. avr asm-ben is a 0x alakot használom, mert C-ben előbb írtam hexadecimális számokat, az avr asm meg megengedi. :)

En nem erzem annyira megszokasnak, sokkal inkabb nyelvi jellegzetessegnek. Semmivel sem kenyelmesebb az egyik a masiknal. Persze, klassz lenne ha mind a ketto menne, de nem sokat javitana semmin. :)

C64-re volt ám C és Pascal fordító is!

Ki is próbáltam mind a kettőt! A C után már tényleg tisztább és szárazabb érzésem volt:

int - 2 byte
long - 4 byte
float - 4 byte
double - 8 byte

Teljesen megborzongtam, hogy huhú 4 byte-os egész! Assemblyben szophattam volna vele rendesen, itt meg: long l=1000000;

Volt ám!
A C igen gyenge kódot fordított, és a Pascal is csak floppyval ment. Valami P-kódos trágya volt. (Talán UCSD Pascal...)

UCSD volt, én szerettem. (A C fejlesztőrőlről csak annyi emlékem volt, hogy valami fickó aki az Impossible Mission 2-t írta, valami riportban emlegette, hogy a C64-es portot *nem* C-ben írja, mert nem fér el egyszerre a fordító és az IM2 kódja a memóriában.)

IM2 C64-es portját magyarok írták (Novotrade színeiben).
De ha már itt járunk, a LastNinja-t is magyarok kezdték el írni C64-re, csak nem volt szerencsés, hogy Forth-ban akarták leprogramozni.

linus+8bit+mikrokontroller témában ez jutott eszembe. :)

Ez mind eszedbe jutott? :))


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ugyan, nekem még ennyi se.

Érdekes értékek vannak a printk-s sorok előtt...

Mondjuk a kod minosege eleg borzalmas...

Hát? Ügyes a srác, de végiggondolva nem látom értelmét így 2012 évben a tettének.

Egyébként ha valaki még mazochistább akar lenni, és sok felesleges ideje van, saját minimál processzorra ír cpu emulátort és arra tolja az ubuntut. Minimálprocesszorhoz kiindulási alap:
http://opencores.org/websvn,filedetails?repname=mcpu&path=%2Fmcpu%2Fweb_uploads%2Fmcpu.pdf

A Knuth-féle MIX-en fut már Ubuntu?

azon kívül hogy vicces, van ennek valami gyakorlati értelme?

Eredetileg irtam valami hosszu dolgot ide, de a valodi valasz: nincs. :) Viszont innentol erdekes kerdes, hogy ki tudja gyorsabbra megcsinalni ;)

Hogyne lenne. Például ha állást keresel, azért ez szerintem elmegy egy jópontnak.

És hány FPS-sel megy a Quake3 rajta? :-)

marmint... hpf (ora/frame)

Azért ARM emulátort irni AVR-re... poénnak jó, de viccnek is rossz...
:-)

Amit lehetne viszont csinálni: Xilinx Zynq ARM magjain Linuxot futtatni, az FPGA-ba meg hardveres gyorsítást az egyes kernel részekre. Na, ez buli lenne...
Kár, hogy a Zynq-nek még árát sem látni sehol...

Annak sem lenne sok értelme, mert nem tudnád otthon összerakni. Ebben pont az a poén, hogy a hardware egyszerű mint egy kilincs.

Ez egyfelől tény, másfelől eval. boardon lehetne vele játszadozni.
Jó, mostanság zynq-mániás lettem, mert kíváncsi vagyok rá. Bár meg kell vallanom, az FPGA-oldala a beágyazott rendszereknek mindég jobban érdekelt, mint a mikrokontrollerek.

Es? Rengeteg proci van ami elfer kisebb FPGA-kon. Az eval boardok meg dragak ahhoz, hogy jatszadozni jo legyen.

De ossze tudnad, csak konyen 50kHuf felett lesz csak a PCB amit rendelsz.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Persze, de ha mar egyedi alkatreszt kell hozza rendelni, akkor az már nem az igazi.

Addig csak tuleled valahogy a Power magokkal :) Vagy mas gyarto termekevel: http://www.actel.com/products/arminfusion/.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kibírom én nélküle... :-)
Megvagyok a Spartan-6-tal is. Abba megy OpenRISC, ha kellene valami.

Virtualbox elindul alatta? Raknék rá guest-ként Windows 7-et.

Én úgy tudom a virtualbox az x86 only, de a Qemu tuti menne.