Pokud uz by se nekdo chtel pustit do standardniho PC postavenyho na ARMu. Tak nestaci jen deska ve formatu ATX. Musel by tam byt PCI-e (aspon 20 linek), HW kterej ma primou podporu v Linuxu a hlavne by tam musel byt BIOS/UEFI aby se to i chovalo jako PC. To je docela dlouha cesta od techto jednoduchych SBC.
Vicemene by museli pouzit standardni PC HW + vlastni navrh ARM procesoru + zaplatit nakymu vyrobci UEFI. Takova deska by minimalne nez by se to trochu rozsirilo stala v radu desitek tisic.
PC je HW standard, kterej zarucuje standardni rozhrani mezi HW a OS. To jestli ten OS pouziva x86 instrukce nebo ARM instrukceje celkem vedlejsi. ATX je jeden z formatu PC HW. Cili pokud uz by mela byt ARMova deska ve formatu ATX mela by umet aspon zakladni veci ktery PC standard vyzaduje.
Jinak jen to porad jen SBC se vsema jeho nevyhodama, ktery jen jde namontovat do ATX skrine.
Bez nakyho BIOSu/UEFI je deska vetsinou pouzitelna jen s OS ktery doda vyrobce, pripadne nejakej zkusenej HW hacker. PC standard by ARMu dal podobnou svobodu vyberu jako ma klasicky x86 PC.
O zadny emulaci nebyla samozrejme rec.
Samozřejmě, že s efi by to bylo lepší. Není to nemožné.
Ale i bez něj by to byl pořádný posun. Možnost osadit RAM a připojit plnohodnotně disky by ze začátku určitě stačilo. Všechny vnější konektory vzadu, možnost dát to do normální skříně... Co se týče CPU - existují už snad ARM servery ne? Dodavatel by se tedy mohl najít.
PC(nebo laptop) na dnešních ARMech je velice lákavá představa a vůbec bych se nebál o to, že po krátké době by na něm bootoval trochu upravený Debian.
Nechápu, proč nic takového dosud neexistuje. Asi to brzdí tržní podíl jistého dodavatele podivného OS, svázaného značně s Intelem :-(
Laptop je, a dokonce od totozneho vyrobce jako Rock64, jde o Pinebook kterej je v podstate podstavenej (na upravene) jeho "predchozi" desce Pine64:
https://www.root.cz/clanky/pinebook-linuxovy-notebook-s-arm-za-89-dolaru/
Ty si jako vazne myslis, ze nabootovat z neceho vyzaduje bios? Ve skutecnosti ani widle ani tux BIOS vubec nanic uz hezkych par let nepouzivaj a nepotrebujou. Naposled to potrebovaly widle zalozeny na DOSu.
Nevsim sem si pak, ze by trebas ... mikrotik potreboval uefi ... a presto na tom sou celkem bezne minipci ... napr. Divny, jak voni to jen sakra delaj ...
Ve skutecnosti bohate staci, kddyz nekdo neco vyrobi, a pokud je to dostatecne zajimavy, staci rict, ze to startuje ... ze 187 sektoru na disku. A dodat k tomu dokumentaci.
No z mého skromného pohledu BIOS/(U)EFI/[jakkoliv si to nazvem] přijde docela k ruce, když zařízení má více vstupů a je potřeba z nějakého vstupu nabootovat.
Tudíž pokud to má možnost připojit klávesnici tak bych nějaký základní bootovací program, s jednoduchým výběrem odkud chci natáhnout operační systém určitě uvítal. Za mě teda lepší než že vytáhneme JTAG debugger a jdeme flashovat bootloader na eMMC.
To bohuzel nestaci. Absence BIOSu u ARM procesoru znamena, ze Linux musi ziskat o HW informace jinde. Pouziva se k tomu device tree file kterej je potreba zakompilovat do jadra.
Sice to funguje, ale je to dost otravny a ne vzdy muze byt device tree vubec dostupny pro uzivatele. Navic to znamena, ze pro kazdej druh desky musi byt zvlast zkompilovany jadro.
Proto neexistuje zadnej obecnej ARM linux s jednim jadrem. BIOS/UEFI by to resilo.
Tak koukam, na SD image pro Raspberry a je to jasny. Na kazdym image jsou DTB pro vsechny typy Raspberry a bootloader v ROM(Flash) ma z vyroby zadratovany, kterej ma nacist.
To mi prijde jako dost velkej problem techle SBC, ze nejen ze si clovek nemuze vybrat bootovaci zarizeni, ale dokonce kazda deska ma jinej a jinak nastavenej bootloader, takze i kdyby se vyresil problem s autodetekci HW, tak porad neexistuje zadnej standardni zpusob jak bootovat system. Coz je dalsi vec co by UEFI resilo.
Ale prd je zadrátované. Bootloader většinou umí i overlays, aby dokázal řešit všechny ty hats... Furt nechápu v čem je problém, pokud je někde v adresním prostoru namapované nějaké zařízení, těžko jej nějak detekovat, že ano. Proto výrobce desky dodává tuto s "BIOSem" - U-Bootem nebo v případě RPi vlastním nesmyslem (protože na RPi po resetu běží kód v GPU) postará se o zavedení jádra a příslušného DTB. Prostě mám jádro, DTB a obraz filesystému a tohle spustím. Jestli je to pomocí UEFI nebo čehokoliv jiného je jedno.
No jako sou jen dve moznosti. Bud autodetekce nebo zadratovany. Predpokladam, ze bootloader neni vedma aby vedel kterej DTB pouzit bez jedny z tech dvou veci.
Problem je v tom, ze pokud by sme ATX desku postavenou ARMu, tak bez autodetekce externi graficky karty nebude shopna ji pouzit pri bootu, bez autodetekce SATA zarizeni nebude schopna bootovat z disku, bez autodetekce site nebude schopna bootovat ze site a umoznovat treba wake on lan. U SBC to az tak nevadi, ale u ATX desky by to bylo hodne omezujici.
Všechny tyhle věci SBC třeba s U-Bootem nebo Bareboxem umí. Asi není úplně jasné, co DTB je. Takže obráceně - DTB nepopisuje, jestli je něco připojené v SATA portu, ale kde je namapovaný SATA controller, neříká, jestli je připojený ethernet kabel, ale kde je namapovaný ethernet chip, neříká, jestli je něco v PCIe, ale kde (a jestli) je PCIe controller.
DTB slouží k popisu zařízení která nelze (bez nebezpečí) detekovat, bootloader potom musí umět DHCP, TFTP, přečíst data z filesystému a vědět, jak pracovat s diskem. Dobře připravený SBC tohle umí, příslušný DTB je uložený někde ve flash a tak je možné nabootovat stejný systém na RPi nebo BeagleBoardu.
Průser hraček typu RPi potom je, že nemají žádné persistentní úložiště, takže záleží na obsahu SD karty. Pak je těžké udělat jednu kartu, která bude fungovat všude, protože výrobci se to snaží "zjednodušit" - třeba některé SoC od TI (DaVinci, ap.) mají BootROM, která v případě bootu z SD karty předpokládá v první partišně VFAT a tam umístěný soubor MLO, který bez dalšího zavedou a spustí. Problém je, tento kód má za úkol inicializovat třeba časovaní DDR a podobné nízkoúrovňové věci, takže musí být specifický pro daný SoC a jeho zadrátování.
Jinými slovy, to co chcete sice existuje, ale protože všechno musí být super levné (asi aby si kdokoliv mohl na 64bit čtyřjádru zmatlat meteostanici v Pythonu), výrobci levných SBC upouští od zadrátování NAND za pár (doslova) dolarů, čímž uživatele připraví o možnost uložení systému, který tak je součástí vyměnitelného média - představit si to můžete třeba tak, jako byste byl povinen do PC vrazit flash s BIOSem, aby výrobce ATX desky ušetřil.
Myslim, ze se moc nechapeme. U kazdy jednotlivy SBC se resi boot jinak. Bootloader ve vnitrni pameti desky nebo primo SOC obsahuje minimalni nutny drivery pro inicializaci storage a pro nacteni 2nd stage bootloaderu nebo primo jadra. Ale to kde presne a co presne se ma nacist je u kazdyho vyrobce jinak. To by standardizace typu UEFI resila. DTB nijak nesouvisi s bootloaderem. DTB je predavanej az Linuxovymu jadru. Bootloader (pokud prednim neni neco jako UEFI co mu to rekne) musi mit konfiguraci komponent bud zadratovanou nebo byt schopnej ji detekovat.
RPI samozrejme stejne jako vsechny ostatni SBC ma vnitrni persistentni uloziste, kde je ulozenej bootloader. Bez toho by RPI nebyla schopna bootovat, protoze by ten ARM nejen nevedel odkud bootovat, ale ani ze po nem nekdo chce, aby neco bootoval.
A tak...
1) chtít po výrobci SoC, aby implementoval UEFI je nesmysl (a tak jste to asi nemyslel), takže:
2) osadit desku například NAND a uložit do ní cosi, co by UEFI implementovalo se zase nechce výrobci SBC, ačkoliv to má zcela ve své moci.
3) Jak U-Boot, tak Barebox umí načíst DTB a zachovat se podle něj. Je (bude) tedy možné použít jedinou binárku U-Bootu pro více typů SBC. SPL ale bude furt problém.
4) Vnitřní persistentní úložistě jak ho popisujete na příkladu RPi a ostatních SBC není ani vzdáleně, co mám na mysli. To, co popisujete je ROM zapsaná výrobcem SoC, která se stará o načtení SPL a základní inicializaci SoC. A tu jsme u toho: kdyby se výrobce obtěžoval s přidáním NAND například, pak by bylo možné BootROM pomocí (zpravidla) pullupů na boot pinech sdělit, kde že to je ten Váš kód implementující UEFI.
Zkrátka k tomu, aby se tyhle SBC chovali tak nějak normálně stačí jediná součástka: flash pamět (NAND, eMMC, SPI NOR), prostě něco kam bude výrobcem desky určeno předat řízení (protože třeba U-Boot UEFI implementuje).
To jde ovšem proti ceně výsledného výrobku a tu jsme u zásadní nevýhody RPi a spol. Nikdy to nebude fungovat normálně a díky použití SD karty to nikdy nebude spolehlivé. Prostě nechápu, na co si stěžujete :-). To, co by se vám líbilo na trhu již je, akorát stojí víc peněz a námahy se k tomu dobrat.
Samozrejme, ze po vyrobci SOC nikdo nechce aby implementoval UEFI. Chtel bych to po vyrobci potencialni ATX desky zalozeny na ARMu. U SBC je sice bolest, ze neni mozny udelat jednotnej instalacni image, ale tam se s tim lidi zatim nak smirili...
A tu "ROM" u RPI predpokladam nezapisuje vyrobce SOC, ale vyrobce desky. Aspon u vetsiny ostatnich SBC to tak je. Jestli to zapise na vnitrni Flash SOC nebo na exteni Flash na desce je celkem vedlejsi. Flash stoji par korun v kazdym pripade.
A znovu rec je o potencionalni ATX desce, ne o SBC. I kdyz SBC by z toho tezily taky.
Jediny o co mi jde je sjednotit bootovaci proces. Jestli to bude UEFI nebo jedna presne definovana configurace uboot neni az tak dulezity. Do znacny miry by se tim zjednodussil dnes extremne roztristenej vyvoj OS na ARMu.
A on nějaký výrobce uvedl na trh ARM ATX desku bez UEFI? Měl jsem za to, že byste to chtěl i po výrobcích SBC neboť u ATX formátu desky je to tak nějak normální.
Pokud jde o boot ROM RPi pak jest součástí SoC, více třeba zde: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/bootflow.md
SoC samozřejmě umí bootovat i z NAND, SPI... ovšem kluci malinoví se s tím neobtěžují. Přitom jen ta NAND by stačila, aby to bylo o několik řádů spolehlivější.
Stručně: po resetu RPi ARM jádro neběží, GPU běží, SDRAM netiká. GPU začně provádět kód BootROM (to je součást SoC), ten se podívá jak má zadrátované bootovaní a pokusí se načíst bootcode.bin z SD karty do L2 cache a spustit jej: ten nastaví SDRAM a načte do ní loader.bin. Tady už si nejsem jistý, myslím, že loader.bin natáhne jádro a teprve když mu předává řízení odresetuje ARM (bez záruky, už jsem to dlouho neviděl neboť RPi je pro mě naprosto nezajímavý hw).
Mimochodem, na absenci jakékoliv standardizace ARM platformy si stěžuje i jakýsi Torvalds ;-)
(přesněji, on si tuším nestěžuje, jen říká, že to je to, co ARM činí proti x86 méně atraktivním)
Tak teda dobře, hned na začátku:
11. 7. 2017 12:36
BlackRider
Pokud uz by se nekdo chtel pustit do standardniho PC postavenyho na ARMu. Tak nestaci jen deska ve formatu ATX. Musel by tam byt PCI-e (aspon 20 linek), HW kterej ma primou podporu v Linuxu a hlavne by tam musel byt BIOS/UEFI aby se to i chovalo jako PC. To je docela dlouha cesta od techto jednoduchych SBC.
ARM ATX desky se vyrábí a vyrábí se tak, jak byste chtěl, aby se vyráběly. Nechápu, proč tam je použitý podmiňovací způsob a nechápu Váš poslední komentář. Cesta již byla prošlapána.
Začátek vlákna je výkřik do tmy, pod tím je nějaké přání, jak by se po něčem, co ještě nikoho za pár korun nenapadlo vyrábět zaprášilo, kdyby se to vyrábělo za pár korun a pak je Vaše odpověď.
Snažil jsem se vysvětlit, proč jsou věci, tak jak jsou. No, to je jedno, jakési odkazy se tu mezitím objevily, já jsem měl čest pouze s Gigabyte MP30-AR0, což byla blahé paměti deska řádově dražší než dnešní Rock64 a RPi3.
A ta věc, co po ní toužíte, se jmenuje Server Base System Architecture (SBSA) ;-)
jen to delas, nebo ti nedochazi ze:
1. ne kazdej potrebuje sata, ale kdyz by tam bylo tak
1.a. zaplatej ho i ti co ho nepotrebujou
1.b. musel by se zvolit SOC co ma nativni SATA nebo pridat dalsi chip jen kvuli sata
2. dalsi lidi by chteli neco jineho a stejne by (trapne) pronesli neco jako ty: "Dalsi zbytecny kram bez $NECO"
3. ma to USB3, GLAN, eMMC slot to ma pohromade maloco...
4. lze zvolit verzi s 4GB RAM ... to ma snad jen Nvidia JETSON TX1 za $600 ;) nebo podobne drahe prumyslove desky...
Bud jsem blbej jenom jako, nebo jsi blbej opravdu. Trapnost je predevsim v tvem prispevku a to proto, ze:
1) Na IoT je tu kramu dost (to je duvod reakce tveho predrecnika).
1a) Tak znovu pro pomalejsi jako jsi ty. IoT levjech smejdu z Asie je tu dost, neni duvod, aby si ti, kteri SATA nepotrebuji, platili za SATA.
1b) Ano, a takove "zvoleni" (tj. premysleni hlavou) by bolelo takove arogantni hlupaky jako jsi ty.
2) Ano, a na zaklade toho by se treba vyvinula zase dalsi a jinymi zajimavymi periferiemi osazena deska.
3) Mozna "maloco", ale ma, tj. je to kopirka jiz hotoveho, nic noveho to neprinasi.
4) A prave proto, ze jsou drahe, puvodni prispevatel prispival a vznesl myslenku, ze masovost vyroby RPi se SATA (coz by uz ale pochopitelne nebylo RPi, ale zase by to nebyla Nvidia Jetson) prispela k cekovemu snizeni nakladu a idealne i ceny pro koncoveho zakaznika.
Jak vidis, jsi trapny sam, at uz je to tim, ze ze sebe dobrovolne blbecka delas, nebo jim jsi, a pak je mi te lito.
@Kaplan
ad 1 ze by melo jit o dalsi kram sem rozporoval faktama ze tomu tak neni, kdybys misto zesmesnovani ktere se obraci stejne proti tobe, trochu premyslel... ;)
ad 2 si dost protirecis, pokud ti vadi ze je tady dalsi deska k hromade (ignorujic ze prinasi neco jineho nez ta hromada) tak jak muzes obhajovat tvorbu dalsich a dalsich desek na zaklade dalsich a dalsich pozadavaku dalsich a dalsich nespokojenejch se stavajicim? ;)
ad 3 i kdyby slo(jako ze nejde) o kopirku fakt je ten, ze tim ze to ma parametry jako maloco, tak NEjde o dalsi z hromady kramu, ale maximalne dalsi z tech nekolika malo co takove parametry maji
ad 4 nic takove nevznesl, to jen ty sve do toho promitas sve dojmy ;) s nativnim sata muzes mit nejakou desku s CPU A10, A20, R40, mas ji? tezko, mas spis jen blbe kecy ;) ja desku s A20 mam...
btw: kazdopadne chlapce, zajdi si co nejdrive k lekari, potrebujes nasadit ci zmenit leky ;)
Sice to "nobody@pel.cz" nevidi, ale je zjevne, ze obe jeho reakce jsou naprosto mimo misu vubec nereagujici na prispevek Kaplana a mimo tema puvodniho prispevatel. To nic pochopitelne nemeni na faktu, ze Kaplan je buran.
Idealni by bylo, kdyby ani jeden "neprispival" do diskusi. Doktora by kazdopadne potrebovali oba!
me reakce reaguji na to co psal Kaplan, coz bylo jeho rozvedeni zacatku vetve ze bez SATA jde jen o dalsi kram, coz jestli nevidis ze rozporuju a netusis proc, tak si zajdi k lekari sam ;)
kazdopadne "prvni" testy, resp. komentar od "TKasera z Armbianu" z praxe s Rock64:
Rychlost cteni SSD ci SCSI pres USB ma ~380MB/s, rychlost po GLAN je 940 Mbits/sec v obou smerech, cimz to povazuje za momentalne NEJVHODNEJSI SBC pro pouziti jako NAS... (coz vyvraci opet teoreticko-namyslene-machrovane kecy na ktere sem reagoval ;)
Add 1. chápu, to je logickej argument
Add 2. Mno další zbytečný krám bez „komunitní podpory“ to Vám přijde málo? Mít desku na který pojedu jen Droida a s Linuxem budu mít problémy? Ještě jsem si nenačetl, co o této desce píše na Armbian fórech TKaiser, kterej vždycky tohle kritizuje a dělá si předběžný testy jak to bude fachat.
add 3. a 4. x86 za 165USD https://shop.udoo.org/eu/x86.html?___from_store=other&popup=no
@djmanas
add 2 - zrovna Pine a (napr.) FriendlyARM se celkem snazej a bez komunitni to neni, co psal tkaiser sem pastnul tady vidim tam sama positiva ;)
add 3 a 4 - myslel sem ze z kontextu je jasne ze je rec o SBC s ARM... nicmene i tak Rock64 je s 4GB za $45 porad 4x levnejsi... a v reakci na to ze jde zas o dalsi kram je to naprosto cistej argument ze jde NAOPAK o ojedinelou desku ;)
Add 2: Bohužel toho jsem si všiml až později a root neumožňuje změnit už napsané :-(
Add 3 a 4: Validní argument, každopádně jsem reagoval primárně na to, že něco podobného stojí $600 oproti tomu těch $165 je 3x míň a hlavně nebude problém s distribucí Linuxu, nejnovějším kernelem a tak. Ale uznávám, i při odpovědi jsem si uvědomoval, že se mluví primárně o ARMech, kde ta cena je ještě jinde...
Tady mas desku co ma ARM & 4x SATA & 2xUSB3, reseni navrzene primo pro NAS. Levne to ale neni. Spokojeny?
http://kobol.io/helios4/
http://www.cnx-software.com/2017/05/11/helios4-personal-cloud-diy-nas-supports-3-5-hard-drives-raid-and-more-crowdfunding/
Ta cena neni spatna. Za 170USD tam nic nevidim. Maji jen cely kit - deska, zdroj, bedna, kabely za 195USD.
Osobne bych to srovnaval treba s ASRock J3160DC-ITX.
Spotreba se CPU je srovnatelna. Teda aspon to co sem nasel ja. (5W vs. 6W) Jenze to ARM reseni ma v cene i RAM i bednu.
Takze pokud chcete spotrebu na srovnatelne urovni, tak x86 reseni je drazsi. Ale asi bude vykonnejsi.
Kazdopadne ta deska se blizi tomu co bych si predstavoval jako zaklad sveho NASu.
Otazka je jestli to bude mit SW podporu. Na Intelu to je jednoduche. Ale na tomto nikdy clovek nevi:-(
Tak si asi slepej ....
"An early bird pledge of $125 US should get you the basic kit with 1GB RAM, while $149 is required for the 2GB version. If you want a full kit with enclosure, you’ll need to pledge $139 (1GB RAM) or $169 (2GB RAM). Worldwide shipping adds $39 or $43 for respectively the basic and full kit, even if you are in Singapore."
Deska s 2GB + krabka $169 + $43 za postovny ... Takze s dopravou za $212
2Ladislav Michl: Tusis ty vubec ze 80+% ti u toho tvyho uzasnyho jednodiskovyho NASu sezere ... HDD? Resit, jestli neco bude fungovat a zrat o 5W vic nebo to nebude fungovat a usetrim na provozu 10Kc rocne ... lol.
Dokážu pochopit, že někoho u NAS pro domácí použití prostě nenapadne ten disk uspat, protože takové zařízení přece musí začít sypat data do několika milisekund, jinak se stane neštěstí. Kdybyste se obtěžoval změřit odběr Vašeho PC za pár korun, dojdete pravděpodobně k hodnotě převyšující 20W (bez disku) zatímco "blbá" deska s ARM si vystačí s příkonem řádově nižším. Další věc je, jaký to "normální" PC bude dělat hluk, ap. protože ta pasivně chlazená řešení zas tak levná nejsou. A jinak samozřejmě souhlasím s tím, že pokud je někdo matla odkázaný na hotová řešení, pak PC nemá konkurenci.
Njn, vylizanec co netusi, ze ty veci sou jednak pripojeny k JEDNOMU tomu SAMYMU USB ... takze se o nej delej, a druhak nema ani paru o tom, jak se USB ve skutecnosti chova, a jeste k tomu micha MB a Mbit ....
Libovolnej disk pripojenej k libovolny verzi nativniho SATA je o rad (minimalne) rychlejsi, nez naprosto cokoli na libovolnym USB, a to i kdyz na tom USB nebude vubec nic jinyho.
jasne, ses proste "borec" co se krci u monitoru a nadava aby si nadzvedl sebevedomi ;-)
ty tusis jak to je? studoval jsi schema? zjistoval sis neco? ne jen zas placas, ten SOC totiz ma 2x ethernet v sobe, jedno je vyvedene na RJ45 konektor jako GLAN, druhej je vyvedenej na GPIO pinech jako FastEthernet...
co bych nemichal, u cteni disku se uvadi MB/s u site naopak Mbit, vsimni si ze jde o GigabitLAN nikoliv o 125MegabytLAN, kazdemu je pak jasne ze rychlost SSD je dosazena vice nez 3x kolik se da pres jakoukoliv GLAN protlacit i to ze tato GLAN dosahuje v praxi vynikajicich vysledku ;)
Libovolnej disk pripojenej k libovolny verzi nativniho SATA je o rad (minimalne) rychlejsi
jasne hosane, takze pokud Rock64 u SSD pres USB3 ma 380MB/s, tak ty kdyz to same SSD pripojis na SATA tam mas najednou rychloost minilalne 3800MB/s a mozna i 38000MB/s :-D
(ponecham ze si psal libovolny disk, takze tech 38000MB/s mas asi i s 4200rpm 2.5" diskem, nebo vlastne ty asi i kdyz pripojis 5.25" MFM HDD :))