Fedora 20: ARM podmíněně primární architektura

Podle shrnutí záznamu FESCo konaného 17. července bude ARM podmíněně primární architekturou pro Fedora 20. Podmíněnost je dána tím, zdali se podaří včas připravit infrastrukturu a splnit kritéria potřebná pro release.

19.7.2013 20:43 | little.owl | Komunita

Komentáře

[little.owl]

Kdo ze to po mne upravoval ??

[alstar]

"primarne podminena architektura" - dobry ty Cestin, jen co pravda je

[frr]

Heh... a nemohl bys to pro mě (pomalou lamu) trochu víc okomentovat? Pokud se pamatuju, máš zrovna o tomhle docela přehled. Pokud vím, ARM měl ve zdrojákách vanilkového kernelu docela roztříštěnou množinu podporovaného hardwaru, se spoustou duplicit v platform-specific podadresářích... a pracovalo se na nějakém radikálním pročištění/sjednocení. Jak je to daleko? Souvisí to s tímhle milníkem ve Fedoře? Co je myšleno tou infrastrukturou - vyčištěný chlívek ARMu ve zdrojácích kernelu a třeba učesaný kbuild (pro snadný bootstrap na mnoha ARMových motherboardech), nebo třeba doladěný build environment pro "primární ARM" na fedořích build serverech? Opravdu je ARM svět už natolik jednotný, aby se mohl stát "primární architekturou" klobouku, který odjakživa bydlel hlavně na PCčkách? Půjde vůbec pro ARM sestavit něco jako generické instalační médium? Myslím CD nebo USB flaška. Nebo se Fedora odteď bude dodávat jako zazipovaný build environment, ze kterého po nevyhnutelné konfiguraci vypadne "bootstrap image" bootloaderu + holého základního systému, na který se budou instalovat další už předžvejkané balíčky přes TCP/IP z repa ze serveru? Žeby Fedora převzala styl instalace od OpenWRT?

[frr]

Jenom úplně na okraj, bude ta nová Fedora na ARMu "self-hosting", tzn. budou se releasy přímo na ARMu taky kompilovat? Nebo se budou cross-kompilovat na PCčku? Souvisí nějak ten milník se self-hostingem?

[Rezza]

Přímo na ARMu, buildery běží na hw od Calxedy.

[little.owl]

Přímo na ARMu

To bych cekal, vzhledem ke stavu cross kompilace.

hw od Calxedy.

Tahle kategorie ARMv7/ARMv8 HW je pro vetsinu uzivatelu Fedory v praxi nedostupna.

Pro nas je tak Cubieboard a Fedora Remix.

[Ovocníčok]

ARMv8 ještě na trhu neexistuje (64bit), naopak ten ARMv7 máte ve všech těch zařízeních, co se o ně jedná (Cortex-A8, A9, A7, A15...).

Calxeda má v sobě Cortex-A9, momentálně zcela nejčastjší jádro na těch různých špalíkách a minideskách. Kromě RPi samozřejmě, ale RPi je holt výkonnostní/technologický stařík.

[little.owl]

ARMv8 ještě na trhu neexistuje (64bit),

Zatim, ale mam takove tuseni, ze tohle je ten pravy duvod onoho armiho cviceni.

ten ARMv7 máte ve všech těch zařízeních, co se o ně jedná (Cortex-A8, A9, A7, A15...).

Jiste, jenze na nich genericky nenabootujete a to jde.

[Ovocníčok]

No jo, to ale nesouvisí s tím, že BFU si z praktických a finančních důvodů nemůže koupit nějaký microserver s EnergyCore.

Na buildbot se musí tak jako tak použít server, to se na nějakém USB ptáku přece dělat nedá :)

[frr]

Doklikal jsem se na nějakou wiki stránku - "ARM jako primární architektura" znamená, že vedle x86 a x86_64 bude ARMv7 další architekturou, pro kterou se budou buildovat releasy = budou se pro ni kompilovat všechny balíky, které nejsou vyloženě irelevantní (platformově specifické pro jiný hardware). Což mi nevysvětluje, jestli chtějí nějak genericky řešit bootstrap na ARMu atd.

[little.owl]

Což mi nevysvětluje, jestli chtějí nějak genericky řešit bootstrap na ARMu atd.

Pokud nebudou cilit na nekolik dostupnych HW platforem a nebudou pro ne bootovatelne image, bude jen hracka pro par skalnich fandu ochotnych si hacknout nejaky Allwinner netbook ci tablet za par babek a na tom se primarni architektura asi stavet neda.

Snad nam to Rezza vysvetli.

[Roman Došek]

Dříve muselo být jádro kompilované specificky pro konkrétní ARM hardware (nebo skupinu desek) ale v posledních verzích se přešlo na popis zapojení pomocí DeviceTree souborů, přibyl generický framework pro časovače a pin muxing.....takže teď už vážně jde sestavit generické jádro. Samozřejmě jen pro novější subarchitektury jako je tegra, highbank - se staršíma jako je třeba pxa už se asi nikdo přepisovat nebude.

[little.owl]

DeviceTree je sice fajn, ale v prvni fazi musite dostat pres primarni bootloader a tam muze byt treba neskutecne upraseny uboot.

[Roman Došek]

Na tom se shodneme, aby to šlo spustit tak tam musí být funkční odemčený bootloader s možností předávat DeviceTreeBlob jádru. Kromě U-Bootu to umí třeba Barebox, který je sice (dle mého osobního názoru) výrazně lépe udělaný, ale je v něm podporováno minimum hardwaru.

[Pavel Píša]

I pokud máte BareBox/u-boot bez podpory device-tree, tak se to na začátek dá obejít. V jádře lze zvolit

Boot options ->
[*] Use appended device tree blob to zImage (EXPERIMENTAL)
[*]   Supplement the appended DTB with traditional ATAG information

Poté lze stáhnout data do RAM přes TFTP a přidat si vlastní startup helper, který správně nastaví registry před skokem do jádra

tftp vmx53/zImage zImage
tftp vmx53/lnx-start-helper.bin lnx-start-helper
tftp vmx53/atags.dat atags.dat
memcpy -s zImage 0x0 0x70008000 4182973
memcpy -s lnx-start-helper 0x0 0x70007000 36
memcpy -s atags.dat 0x0 0x70000100 4096
go 0x70007000

Zdroják helperu

.text
.code 32

.global _start

_start :
        ldr     r0, .LC_r0_val
        ldr     r1, .LC_r1_val
        ldr     r2, .LC_r2_val

        ldr     r3, .LC_jump_val

        mov     pc,r3

.LC_r0_val:
        .word   0x0
.LC_r1_val:
        .word   0x298
.LC_r2_val:
        .word   0x07000100
.LC_jump_val:
        .word   0x07008000

.end

R1 je machine ID a pro DT může být 0xffffffff, ale zdá se, že je alespoň pro náš build ignorované. R2 by mělo ukazovat na začátek ATAG, ty se dají vykopírovat z nabootovaného původního jádra/systému. Nejsou ale kritické. Kritická je adresa v R2, která musí ukazovat na start RAM+0x100. Z hodnoty se určí start RAM pro dekompresor a startovací minimální stránkovací tabulku. Zbytek si již jádro vytahá z přibaleného DT.

Optimální řešení to není, ale minimálně umožní odzkoušení nového jádra bez (s minimalizací) rizika pokažení loaderu ve FLASH.

[Roman Došek]

No jasně, jenže s tím už neuděláte univerzální jádro, nebo snad jo?

[Pavel Píša]

Tím jsem se vyjadřoval k tomu bootloaderu bez podpory DT. A vhledem k tomu, že je možné nahrát DT do paměti a ve stubu předat jeho adresu do registru, tak to umožní nahrát i zcela obecné jádro pro danou třídu HW (Ale tak to zrovna my teď nepoužíváme a raději dávám příklad, který máme zrovna otestovaný). Je ale potřeba připravit a zkompilovat DT pro danou platformu. V současné době je ale podpora DT mnoha driverů/platforem v tak překotném vývoji, že na mnoha platformách stejně zkompilované DT chodí akorát s tou verzí jádra, ze které je připravené. Na druhou stranu vlatní jádro (zImage) může být opravdu jen jedno.

Další možnost je DT do/za konec zImage přidat a tak to kombinovat pro různé desky i s tím embedded DT.

Přitom na binární distribuci vidím jako hlavní přidanou hodnotu především tu plnou škálu balíčků a jejich provázanost. Pokud je to slušná distribuce a nevychází z nějaké shaddow branch (polo proprietárně vyvíjené a prodávané) opatchované verze jádra, tak kombinace s aktuálním mainline jádrem specifickým pro daný HW/desku není problém. Problém je, že Android a další mají vlastní zprasená jádra a na mainline neběží a mainline nemají snahu o udržbu mainline.

[little.owl]

Problém je, že Android a další mají vlastní zprasená jádra a na mainline neběží a mainline nemají snahu o udržbu mainline.

Coz je problem i mnoha HW vyrobcu, i ten bezny Allwinner neni v mainline a misto DT pouziva svuj proprietarni format.

[Kvakor]

Další možnost je DT do/za konec zImage přidat a tak to kombinovat pro různé desky i s tím embedded DT.

Myslím, že by možná nebylo špatné mít možnost sestavit jádro se všemi možnýmy DT (nejlépe s možností vyprat je už během konfigurace jádra) a předat mu identifikátro toho správného až v okamžiku zavádění bootloaderm skrz parametr jádra, stejně, jako kdysi dávno u před-PnP ISA sběrnice na x68 šlo vnutit jádru porty, IRQ a DMA hardwaru (pokud nefungovala jeho autodetekce). Soubory .dtb (přeložené binární DT) mají rádově kilobyty až několik desítek kilobitů, takže zas tak moc by to soubor s jádrem nezvětšilo.

[pc2005]

Ani by nebylo překládání jádra potřeba, myslím (je to jen nějaká binárka od adresy X do adresy Y). Stačilo by předat pointer na vybranej DT při startu.

Ještě vtipnější by byl editor toho DT před zavedením kernelu .

[little.owl]

Pokud mate odemceny bootloader, delat lze plno veci, nicmene tohle hackovani neni genericke reseni pro primarni architekturu a prumerneho uzivatele.

[Jardík]

Doufám, že to boude pro nové 64bit ARM procesory a né pro ty 32bit šmejďárny ;)

[little.owl]

ARMv7 ...

[pc2005]

OMG z tý zprávičky jsem dostal pocit, že jako jediná a x86 budou na vedlejší koleji.

[frr]

No já se právě taky vyděsil. Ale pak jsem našel tu wiki stránku, a kluci to tady moc hezky dovysvětlili. => pořád to není nic pro mě

[little.owl]

V cem je problem? Chapani toho, co je ve Fedore primarni a sekundarni architektura? Viz. zde.

[pc2005]

Toho, že ze zprávičky není jasné, zda to bude přidání do množiny nebo nahrazení množiny a délka toho pocitu než jsem si našel jak to teda je .

[Petr Ježek]

No pokud to vyjde, tak ARM povyroste. Slyšel jsem o tom. Nejsem povolán soudit, zda ARM či Intel bude to pravé v čele nejen fedořího zástupu...