Miniaturní PC Raspberry Pi jde do výroby

Miniaturní počítač Raspberry Pi - na bázi ARM a s Linuxem - jde do výroby. Vyrábí se v Číně, výroba v Británii totiž nebyla cenově únosná, čemuž značně přispívají dokonce i tamní zákony. Pokud importujete součástky, clo platíte, ale u hotových výrobků nikoliv.

11.1.2012 03:20 | Luboš Doležel (Doli) | Zajímavý projekt

Komentáře

[Luboš Doležel (Doli)]

Pokud importujete součástky, clo platíte, ale u hotových výrobků nikoliv.

Tohle mi přijde dost zvláštní - myslel jsem, že pravidla na clo jsou teď v EU všude stejná.

[vlanav]

To bude takhle asi v celé EU. Každopádně zařazení podle celního sazebníku TARIC bude jiné, což může znamenat rozdílné clo.

[boris11]

anglicko nema rovnake zakony ako zvysok EU, ma tolko vynimiek ze krajiny ako svajciarsko a norsko ktore niesu v EU su s nou ovela kompatibilnejsie v zakonoch

[frdrx]

Anglicko? To na Slovensku říkáte normálně?

[MaT]

Mně to nijak zvláštní nepřijde. Kdysi jsem se díval do celních sazebníků (našich, českých), už to nějaký rok bude, ale právě mě tam zaujalo, že u některých přístrojů a elektroniky je dovozní clo 0. Takže tehdy mi hlavní vrásky dělalo DPH.

Konkrétní součástky (resp. typy součástek) nebo díly ale můžou být v tomto sazebníku jinde a clo na ně klidně může být... Třeba 2 %, třeba 10 %, kdo ví...

Tak možná správné řešení, aby se ochránil pracovní trh v EU by bylo, aby někdo přišel s tím, že se napálí dovozní clo alespoň 10 % i na celé přístroje.

[Andy]

Bude někdo dělat do ČR hromadný nákup?

[maes]

Asi to nebude mozne, chcu limitovat pocet na jednu objenavku.

[petr_p]

Jak je to se otevřeností (specifikace rozhraní) grafického čipu? Čipset od Broadcomu integruje grafický systém VideoCore. Nikde jsem nenašel, jak se s ním Xorg dokáže domluvit. Navíc v mailing listu OpenBSD se vyjádřili, že ve skutečnosti deska bootuje z SD karty do VideoCore natažením proprietárního operačního systému a uzavřeného ovladače pro VideoCore z VFAT oddílu, který pak zapne ARM a předá mu obraz linuxového jádra.

[Grunt]

Yup. Podobně to funguje i u TI, nevidím důvod proč by to mělo u BCM fungovat jinak. Nebo aspoň já žádné zdrojáky k VC nenašel.

[Grunt]

BootRom se to jmenuje.

[VM]

Fujtajbl, to nesehnali rozumnejsi hardware?

[dustin]

Nedivil bych se, kdyby nesehnali.

[pc2005]

No bootovat přes GPU je sice takový kostrbatý, ale jak jinak bys chtěl nahrávat update ROM bootloaderu (můžou to mít klidně jako přepálitelné pojistky na křemíku). BTW systém mikrokódu v x86 je taky ROM program a taky ho nemůžeš modifikovat (jen pár oblastí upravit) .

[petr_p]

Jenže VideoCore je plnohodnotný general purpose processor. Je to víc než jen grafický akcelerátor. Je škoda že se do něj člověk nedostane.

O několika megabajtový firmware mi ani tak nejde jako že není specifikace jak s jeho službami komunikovat. Obávám se, že papírová podpora OpenGL je vám k ničemu, když za stávající uzavřenosti bude Linux honit grafiku přes frame buffer a video přehrávat v lepším případě jako video overlay, v horším případe ručně přesouvat bitmapy z dekodéru do frame bufferu.

[R]

Pripomina mi to jeden "otvoreny" telefon, kde jedina aspon trochu funkcna distribucia bezi nad neakcelerovanym framebufferom...

[Grunt]

Mě zas přijde zajímavější nativní vykonávání Java bitecodeu přímo na procesoru. Holt nevyrábím tisíce telefonů za den, tak si můžu nechat zajít chuť. Čistě pro zajímavost: S OpenGL_ES to nebude o nic lepší.

[Grunt]

No, ne jako že by snad ti ostatní to jádro tahali o moc lépe. A tohlencto je přesně „ten klasický corporate přístup“,který se mi fakt nelíbí. GPP předpokládám dostali už licencované od ARMu, takže maximálně CTRL+C, CTRL+V na wafer, GPP potřebuje určitě natažený blok instrukcí někde aby je mohl začít vykonávat (řadič SD karet to bude těžko ovládat mikrokódem) a jediné co si můžou v Broadcomu upravovat je ten jejich bazmek kolem GPP (DSP,GPU,…) tak to nevymyslely lépe než to je. Si dovedu docela živě představit i tu diskuzi u návrhu:

• Šéfe, a mám to začít natahovat z prvního bloku na kartě, to se zas bude blbě dělat update jádra, ne?
• Ježiš, tak to šoupněte do nějaké partišny, ne?
• Ok, a mám té partišně dát i nějaký FS nebo jak?
• Probůh dejte tam třeba FAT, hlavně ať už to je, protože to stojí čas a čas jsou peníze a … blábláblá, přibližně čtvrt hodiny nezáživného přednášení z hodin ekonomie kombinované max. s jednoduchou lineární matematikou.
• FAT?
• Řekl jsem FAT, tak FAT!
• Když FAT, tak FAT, Vy jste šéf…

A vznikl tenhle bazmek. Místo toho aby se všechny strany zainteresované posadili kolem kulatého stolu a něco spolu vymyslely. A to i přes to, že by z toho těžili úplně všichni ARMem počínaje, koncovými uživateli konče.

[Grunt]

to se zas bude blbě dělat update jádra

Resp. výkonného bloku, protože u těchhle ASICů se předpokládá, že se budou natahovat aplikace (jádro, zavaděč, specifická na míru udělaná aplikace) a FAT je jediný souborový systém na který má přístup úplně všechno. S jádrem systému (nedejbože jádrem GNU) se počítá jen sotva.

[pc2005]

No tak možná by šlo mikrokódem tahat data z SD, stačil by jen první sektor. A pokud by mikrokód nestačil, tak klidně malá boot ROM na čipu (takovejch 512B v MBR taky stačí ). A MBR by pak natáhlo cokoliv dalšího. Osobně by mě stačila i SPI flash, ta je malá, nezabírá místo a měla by jít naprogramovat jen obmotanejma drátkama a hlavně na ní stačí automat určitě. Jinak FAT je na jeden image firmware zbytečná věc, stačí v MBR definovat start a konec oblasti a v ní mít ty data RAW (i malej header by šel implementovat).

Ovšem jestli to má bootovat i z jinejch periférií než SD, tak je něco složitějšího asi fakt potřeba.

[Grunt]

No tak možná by šlo mikrokódem tahat data z SD

A jak s ní budeš komunikovat? Na to aby si s ní mohl komunikovat, tak by si musel inicializovat vše od interní sběrnice procesoru až po kartu samotnou a celou strukturou se prokousat. Což netvrdím, že není v mikrokódu neproveditelné, ale určitě je to docela takové kostrbaté.

A pokud by mikrokód nestačil, tak klidně malá boot ROM na čipu (takovejch 512B v MBR taky stačí ). A MBR by pak natáhlo cokoliv dalšího.

No ona ta idea brouka s malým NAND polem a na výjmatelné patici a přímo napojené na procesor nebyla až tak blbá. Jen kdyby ty křápy na ní nebyly tak moc bazmekoidní (tím myslím BIOS). Zas brouci jsou dneska levní a většinou se už na ně vleze i celé jádro, takže je to takové dvousečné.

Jinak FAT je na jeden image firmware zbytečná věc

Tak aby se to dobře updatovalo. Zas z toho že se tím standardem stává FAT mám docela strach.

stačí v MBR definovat start a konec oblasti a v ní mít ty data RAW (i malej header by šel implementovat).

Jasně a balíčkovací systém se u příkazu update bude k tomu prokousávat jak?

Ovšem jestli to má bootovat i z jinejch periférií než SD, tak je něco složitějšího asi fakt potřeba.

Staré Broadcomácké SoC to dělali tak, že měli na sběrnici NAND, na prvních 256kB CFE a v mikrokódu něco jako nacpi 256kB někam do paměti a JMP na to místo. CFE měl otevřené zdrojáky.

[pc2005]

tak by si musel inicializovat vše od interní sběrnice procesoru

K flipflopu nezapojím RST drát do vstupu R ale do vstupu S .

BTW asi stejně jako na PC logický řetězec CPU-NB-SB(-LPC-host)-SuperIO-flash, včetně mňamek typu detekce paměťových oblastí BIOSu. BTW^2 moderní BIOS je LPC periferie přímo :-O (lepší než SPI).

Což netvrdím, že není v mikrokódu neproveditelné, ale určitě je to docela takové kostrbaté.

Dobře tak 2kB ať nežeru . Spousta uC má takovou ROM (třeba scanner) ještě větší (a firmware pak navíc ještě tahá přes USB).

V PCI kartách je řadič, co si natáhne data z i2c eeprom.

Tak aby se to dobře updatovalo. Zas z toho že se tím standardem stává FAT mám docela strach.

Firmware s NAND nebo NOR to maj taky dost natvrdo.

Jasně a balíčkovací systém se u příkazu update bude k tomu prokousávat jak?

Stejně jako u NAND/NOR . Navíc bych se divil, kdyby někdo nedokázal ani dd (zvlášť, když při korektním zápisu do MBR se vytvoří mount point!).

Staré Broadcomácké SoC to dělali tak, že měli na sběrnici NAND, na prvních 256kB CFE a v mikrokódu něco jako nacpi 256kB někam do paměti a JMP na to místo. CFE měl otevřené zdrojáky.

Tak samozřejmě nejlepší by to bylo s opensource to je bezpředmětný. Ta NAND se mě už moc nelíbí (v případě PoP package zabírá místo ramce). Problém je zase, že externí SPI flash je na dlouhodobé provádění kódu pomalá :-/.

[Grunt]

BTW^2 moderní BIOS je LPC periferie přímo

Ale houbelec? Jak nové? Je pravdou že já mám starého Celera tak z přelomu tisíciletí, ale ještě co jsem viděl nové desky, brouk (pole) nebyl natvrdo připájený, ale dal se kleštěma vybrat. Co když se posere flashung?

Dobře tak 2kB ať nežeru . Spousta uC má takovou ROM (třeba scanner) ještě větší (a firmware pak navíc ještě tahá přes USB). V PCI kartách je řadič, co si natáhne data z i2c eeprom.

Ty tak trochu nepobíráš moji pointu. Tou není ani velikost ani způsob natažení, ale nějaká standardizace. Kdysi dávno to byla disketa, včera to byl přímí přístup na NAND, dneska SD card, zítra třeba nějaký holografický pičmulínek, pozítří ví bůh. PCI karta nech si výkonný kód tahá jak chce (pokud bude fungovat), ale třeba u Fedory už by ten způsob neměl být device-specific. No tak či tak by Někdo měl říct že se tu i případě různých periferií bude tahat tak a tak, měl by to vymyslet modulárně, nepříliš komplexně, otevřeně a hlavně aby se to tahalo co nejkratší možnou dobu.

Firmware s NAND nebo NOR to maj taky dost natvrdo.

Jako co? Firmware, jádro nebo zavaděč?

Navíc bych se divil, kdyby někdo nedokázal ani dd (zvlášť, když při korektním zápisu do MBR se vytvoří mount point!)

Dovedeš si představit Debian nebo Fedoru a jádro s dd? A jaká by byla hraniční velikost? Ne! Jádro patří do /boot/bzImage (klidně může být i symlink někam do nějakého brouka, hlavně když se to bude přepisovat systémovým voláním write())

[Grunt]

Jinak jsem zapomněl dodat, že v případě, že by se z ARMu měla stát budoucnost, která nahradí x86 by se to na různých malovýrobcích křemíku a dohodě mezi nimi nemělo nechávat dvakrát. Před třiceti lety se to nechalo na nějakém zduněném Frantovi z Intelu (možná IBM) a trpíme tím jak zvěř cca 30 let dodneška.

[pc2005]

Ale houbelec? Jak nové? Je pravdou že já mám starého Celera tak z přelomu tisíciletí, ale ještě co jsem viděl nové desky, brouk (pole) nebyl natvrdo připájený, ale dal se kleštěma vybrat. Co když se posere flashung?

Moderní PC (ne z roku 2000 jako K7S5A) už nemaj obyč. paralelní flash, ale SPI nebo lépe LPC flash. SPI může být jako SMD brouk (rayer.ic.cz tuším popisoval flash), ale taky nemusí. LPC pak mám v kompu (2006) jako PLCC32 brouka (stejný pouzdro jako ta původní flash). Ale je to složitější mikrokontrolér (?), neboť reaguje na adresní a datové cykly na LPC (sériová sběrnice), LPC slave může realizovat cokoliv, je to vlastně náhražka ISA. Moje flash tuším umí na nepoužitých pinech (asi 50% ) provozovat GPIO.

Ty tak trochu nepobíráš moji pointu.

Jo, a nebo se snažíme aproximovat odpověď z jiných úhlů .

Otázka je pouze ta jak nabootovat základní kód na reset vektoru. Pokud rovnou z DDR, tak tam musí nejdřív něco ty data nacpat. Pokud z nonvolatilní externí paměti, tak je otázka kolik? Použít třeba jen 64kB je plýtvání místa na >16MB se už v pohodě vejde celej linux. Pokud má bejt ta paměť v procesoru, tak je problém zda ROM nebo flash. U ROM se ti nebude líbit proprietarita kód u flash jsi limitován velikostí a řekl bych, že takový hybridní čip bude docela sranda vyrobit.

Pokud kopíruješ do DDR, tak můžeš obecně z SPI, SD. Ostatní varianty jsou buď zbytečné (externí flash), nebo programově náročné (usb mass storage). SPI je triviální, tu lze vyrobit automatem a SD IMHO půjde taky. Dál není problém provést standardizaci typu FDD (že ale byly krásně standardní ). Na disku už pak může být normální zaváděcí systém jako je na PC.

Jako co? Firmware, jádro nebo zavaděč?

To je právě otázka co to je . Jak definuješ jádro? Může být v tom 32 pinovým švábu co máš v PC? OMAP má v sobě natvrdo vypálenej kód, co teprve zavede zavaděč z NAND flash - obvykle u-boot a ten je teprve jako první updatovatelný. U-boot pak může načíst z usb/sd/nand jádro.

A jak s ní budeš komunikovat? Na to aby si s ní mohl komunikovat, tak by si musel inicializovat vše od interní sběrnice procesoru až po kartu samotnou a celou strukturou se prokousat. Což netvrdím, že není v mikrokódu neproveditelné, ale určitě je to docela takové kostrbaté.

To jsem myslel mikrokód automatu nebo kód v ROM přímo na SoC (bába nebo sníh ). Interní sběrnice může být resetována do inicializovaného stavu.

Dovedeš si představit Debian nebo Fedoru a jádro s dd? A jaká by byla hraniční velikost? Ne! Jádro patří do /boot/bzImage (klidně může být i symlink někam do nějakého brouka, hlavně když se to bude přepisovat systémovým voláním write())

Přesně MBR(0x1be+16*i+0xc) přičemž i je 0,1,2,3, ale imho by to bylo skoro vždy =0. Pak by se vytvořil /dev/sda1. Jinak u-boot taky moc na rozložení NAND flash, kde je třeba linux, nehledí.

Jinak FATka se oproti tomuhle RAWu zrovna moc neliší, je ale složitější jí implementovat.

[R]

Medzi LPC flash a SD kartou je obrovsky rozdiel v tom, ze LPC flash v PC priamo namapovana pod 4GB (a kus este niekde dolu ako povodny BIOS IBM PC), takze procesor vykonava kod priamo z nej. SD karta je blokove zariadenie, ktore treba nejako inicializovat, prekopirovat data (odkial a kolko?) do RAM a vykonavat az tam.

[pc2005]

Jj, to LPC ale bylo jen k té citované větě o BIOSu. SD protokol bude imho na úrovni složitosti komunikace IDE řadiče, možná lepší (někde jsem snad viděl adaptér IDE-SD, tam ale bude uC). Spousta operací z protokolu by šla implementovat přímo v hw (samozřejmě, že řadič typo GPIO bit banging bude potřebovat složitější software ). No a ovládání IDE řadiče je docela triviální (doslova jde ovládat ručně ).

[Kvakor]

Drsné. Obvlášť ta separátní partiton. Trochu mi to připomíná řešení problému pro VESA framebuffer "kdysi dávno" u PC v Linuxu. V devadesátých letech, kdy ještě běžné grafické karty byly nanejvíš 2D, výrobců jak čipů tak karet bylo mnoho (pamatujete ještě na S3, Trident, Oak Tech., Tseng, OPTi, Chips and Technologies ... ?), v Linuxu pro tento často exotický hardware nebyla nativní podpora a karty sice uměly lineární (tj. nestránkovaný) framebuffer, ale neměly ve VGA BIOSu VBE 2.0+, jen 1.2.

Pokud chtěl uživatel provozovat VESA framebuffer na takovémto stroji (protože alternativa byla VGA v 16 barvách), tak se na začátku disku nechala malinká DOSová partition, kde se prvně zavedl DOSový VBE ovladač od výrobce (nebo UniVBE od SciTechu) a pak se teprve natáhlo jádro přes loadlin.

Obdobné obezličky bylo tenkrát třeba i u jiného hadrware, napřiklad než jsem si pořídil pravou SB 16, tak jsem měl jakousi divnou levnou zvukovou kartu, co se až po inicializaci DOSovým programem od výrobce začala jevit SB Pro kompatibilní.

[tap]

Neviem ci dane su primarny problem, z clanku som nadobudol dojem ze primarny problem je, ze v UK by vyroba trvala minimalne 12-14 tyzdnov a na dalekom vychode 3-4tyzdne. Pricom v UK sa ceny nejak lisili od kapacity pri vacsich odberoch dokonca vacsie ceny - ale to som nejak nepochopil. Toto nieje problem dani, to je problem manazerskej neschopnosti firiem v EU.

[multi]

s tou vyrobou to bude asi tak, ze v EU se vyrabi maximalne jen zkusebni vzorky a ve vetsim se vyrabi v cine z duvodu ceny a kapacit

[Ivan]

To nemuze trvat dlouho. Nakonec skonci vsechno na vychode. Viz: why-amazon-cant-make-a-kindle-in-the-usa

[pc2005]

No a pak si nemaj firmy a státy stěžovat, že vývoj odchází do Číny...

[David Watzke]

Já jsem si koupil radši CuBox. Ale kdo ví kdy dorazí

[Petr]

To vypadá hodně dobře!

[David Watzke]

Souhlasím, v zásadě by to mohlo nahradit HTPC. Teď mi přišel e-mail, že by to mohli odeslat zhruba koncem února.

[Grunt]

Sem ti to říkal už dávno (myslím).

[lenny]

tak co kupite si to abo ne? ak to ma koprocesor ktory dokaze prehrat Full HD video tak by som to bral ako doplnok k mojej LCD telke. Ubuntu by bolo ako velky bonus ak byt o fungovalo.. a binarny blob v podobe zavadzaca no nejako by ma to netrapilo

[Jooky (inactive)]

Ja nieco podobne hladam ... este som dopodrobna nestudoval HW, ale asi pojde o +- veco co hladam ... riesim dva problemy 1) monitoring zariadeni (napr. UPS daleko od servra/najblizsieho pc + enviromental monitoring), 2) tenky klient (kedze nechcem riesit plnu instalaciu pracovnych masin + mam silny a nevyuzity server) ... pri tej cene je to dost lakava ponuka, no najprv si idem nastudovat HW ... (btw. pre pripad 1) som zvazoval riesenie ala arduino.cc, ale programovanie v userspace linuxu mi je blizsie ako hranie sa so samotnym HW a programovanim na strojovej urovni)

[lenny]

no pozeral som na ich stranku tak Debian je pouzivany na Raspbery pi ako default takze urcite by sa ti to hodilo kedze debian je skor na take experimentovanie ako ubuntu..

co sa tyka ubuntu tak som sa docital ze Cannonical chce odhodit podporu pre ARMv6 teda aj podporu pre Raspbery Pi co je skoda

Fedora tam je podporovana neviem aka verzia

RISC OS to je prenadsencov vyzera zaujimavo ale je to skor hobby os

kazdopadne za 35eur ziskat masinu co prehraju fullhd film aj ked len x264 by seklo

ak by som si raspberry pi kupil za tych 35eur + post. ked bude dostupny tak chcelo by to spravit nejaku s plexiskla krabicku.. nejake navrhy?

[Roger]

35 DOLARŮ, nikoliv eur :)

[Luboš Doležel (Doli)]

Obecně je u Raspberry problém s tím, že tam nejsou naprosto žádné "mounting holes". Takže to abych si šel koupit cigára a schoval to do krabičky od cigár, jinak nevím, jak to upevnit

[Roger]

"Oficiální" doporučení je přilepit (radili i konkrétní prostředek :) ).

[AsciiWolf]

Eh, to je teda fakt "řešení za všechny prachy".

[frdrx]

Ďoury prý snad budou v nějaké další revizi.

[Luboš Doležel (Doli)]

Já si to chci koupit minimálně na recenzi.

[Grunt]

Spíš ne.