Dotaz: Big endianový ARM – jak spouštět uživatelský prostor?

[xHire]

Snažím se rozchodit svůj big endianový build Gentoo Linuxu na ARMu (konkrétně Cubieboardu s procesorem Allwinner A10). Build mám. Dokonce jsem už úspěšně rozchodil i zavádění BE jádra. :c) S čím si ale nevím rady a vrtání ve zdrojácích jádra mě nikam neposunulo, je přepnutí do uživatelského režimu, tzn. zejména spuštění initu.

Mám podezření, že zatímco pro sebe si jádro procesor přepne do big endian režimu, aplikace ho dostanou k dispozici v little endian módu, takže se mi nic nespustí. (A zkompilovat je jako little endian nepomůže, protože to je zase odmítne spouštět jádro – s chybou Exec format error. Navíc tímhle směrem ani jít nechci.)

Dával jsem za init i tak jednoduchý program jako:

int main(void)
{
        return 0;
}

(nebo třeba nekonečný cyklus), ale „návratová“ hodnota je vždycky 11 (Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b).

Nějaké tipy, nápady? :c) Předem díky!

---

---

Odpovědi

[endian]

Je Ti znamy text a vies, co to znamena?

Linux support The Allwinner A1X architecture is referred to as 'sunxi' in the Linux kernel source tree. The source code is available at GitHub. At the moment, stable and full hardware support is limited to 3.0.x and 3.4.x kernels. Recent Mainline Kernels run, but do not offer NAND Access an limited 3D-acceleration.

zdroj

Aka je konfigucia jadra pre preklad (posli subor s nastaveniami)?

Ako prekladas ten program init?

[xHire]

Příloha:

• .config (78256 bytů)

Jakým způsobem je citovaný text relevantní? :c) Nepoužívám ani NAND úložiště, ani 3D akceleraci (ono taky na mali…). Make pro jádro volám:

make ARCH="arm" CROSS_COMPILE="armeb-linux-gnueabihf-" INSTALL_MOD_PATH="/usr/armeb-linux-gnueabihf"

Init kompiluji jednoduše:

armeb-linux-gnueabihf-gcc -static -o init init.c

[endian]

Linux support The Allwinner A1X architecture is referred to as 'sunxi' in the Linux kernel source tree. The source code is available at GitHub.

Podpora The Allwinner A1X architecture Linuxom je oznacovana ako 'sunxi' (v zdrojovom strome Linuxoveho kodu jadra.

A naco prekladat, preco nepouzit uz prelozene? Pouzi: linux-sunxi.org/Debian

[endian]

Preklad init je spravny, chybne je potom jadro. ...

Prekladas zle pre A10, vid: linux-sunxi.org/Linux_Kernel.

[xHire]

Anglicky umím – neptal jsem se na překlad, ale na to, jakou to má souvislost s mým problémem. V čem mi pomůže, že se ta platforma označuje jako sunxi?

A naco prekladat, preco nepouzit uz prelozene? Pouzi: linux-sunxi.org/Debian

Jsem asi slepý, ale která z těch distribucí tam je přeložena pro ARMEB?

Prekladas zle pre A10, vid: linux-sunxi.org/Linux_Kernel.

V čem přesně špatně?

[k3dAR]

ja bych ho asi ignoroval ;) asi mysli ze prekladas spatne, protoze nepouzijes defconfig s tim ze "bacha na to ze se podpora od sunxi vola sunxi" uz sem to vubec nepochopil :))

[endian]

Jsem asi slepý, ale která z těch distribucí tam je přeložena pro ARMEB?

linux-sunxi.org/Debian → wiki.debian.org/InstallingDebianOn/Allwinner

[endian]

A kukni kapitolu Installing from a USB stick.

[Jendа]

Ty jsi fakt úplně mimo. Oba ARMové porty Debianu jsou little endian!

[endian]

V čem přesně špatně?

Zly zdroj bol tam pouzity, ak si chcel main-line kernel prekladat. Spravny> Mainline_Kernel_Howto Ak kompilujes s main-line Linux kernel, tak mas prekladat

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- sunxi_defconfig

a nie ako si Ty pouzival bez sunxi_defconfig. Resp. najprv si ho nastav, co potrebuje a potom si v moduloch ponastavuj co chces.

[endian]

A potom zmen endianitu.

[k3dAR]

takze uz aspon chapes, ze veskere tve "rady" byli naprosto mimo, kdyz jako reseni pro "jak na big endian" nakonec doporucujes "prejdi na little endian" )

[pavlix]

Každá větší diskuze má svého šaška. :D

[file-system]

Je pripojeny root filesystem alebo ramdisk?

[xHire]

Jsem přímo v rootu, nemám tam ramdisk.

[yeti]

Aky je print screen, ked bootne?

[yeti]

resp. fotka?

[xHire]

Příloha:

• cubieboard-be_boot.txt (9882 bytů)

Přikládám. Jen podotýkám, že varování ext4 souvisí s tím, že používám jeden jaderný ovladač pro ext* a oddíl je ext2 (u-boot měl nějaké problémy s ext4), čili připojené je to v pořádku.

[pc2005]

Co ta hláška:

devtmpfs: error mounting -2

Kód -2 znamená:

#define ENOENT 2 /* No such file or directory */

Nechybí ti tam třeba /dev nebo něco takovýho? (mě se na domácím kompu asi 0.5s po tom devtmpfs spustí normálně udevd). Zhruba v tu dobu chce kernel soubor /dev/console. Pokud neexistuje (soubor nebo cesta), tak by mohl odmítnout boot.

Toolchain (tedy i libc) sis nakompiloval sám? Init je standardně v /sbin/init (kernel myslím zkouší i /linuxrc a pár dalších).

Vždycky můžeš zapnout debug (pokud byl ten kernel s pr_debug() zkompilován).

[xHire]

Nechybí ti tam třeba /dev nebo něco takovýho?

Ano, to je dobrý postřeh, chybí. :c) Nicméně to není ten problém (jádro i tak různě reaguje na validní a nevalidní binárku initu) – po vytvoření adresáře (a přidání rootfstype=ext2 do argumentů jádra):

…
[    1.362144] ata1: SATA link down (SStatus 0 SControl 300)
[    1.371609] VFS: Mounted root (ext2 filesystem) readonly on device 179:1.
[    1.381027] devtmpfs: mounted
[    1.384219] Freeing unused kernel memory: 200K (c0480000 - c04b2000)
[    1.390577] This architecture does not have kernel memory protection.
[    1.420708] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    1.420708] 
[    1.429884] Rebooting in 10 seconds..

Toolchain (tedy i libc) sis nakompiloval sám?

Základ mi nakompiloval crossdev (gcc, glibc, binutils a možná ještě něco), zbytek jsem si tam doinstalovával normálně přes portage (emerge). Když pominu perl, tak tohle byla ta naprosto bezproblémová část – v Gentoo má člověk všechny tyhle věci bez práce.

Jako init tam mám normálně openrc, ale to je přecijen docela velká věc, takže pro neúspěch testuji na mnohem jednodušších a staticky linkovaných programech (i bash jsem zkoušel).

Ono jádro při svém spouštění jako první instrukci zavolá setend be (v arch/arm/kernel/head.S), což procesor přepne do BE módu. Dokumentace říká:

Data accesses can be either little-endian or big-endian as controlled by the E bit in the Program Status Register.

Což mě vede k tomu, že endianita je rozhodována per proces. Jinými slovy mám za to, že ty binárky mám zkompilované dobře (resp. jsem nezaznamenal nic, co by napovídalo opaku, ani známky, že by se to mohlo dát dělat nějak jinak) a že problém mám na straně jádra, které ten E bit nenastaví. To mi přijde divné, protože jistě nejsem první, kdo spouští Linux v big endianovém módu na bi-endianovém armu. Vyvozuji si z toho, že něco nedělám nebo dělám špatně.

Koukal jsem několik dnů do jádra, ale neidentifikoval jsem bod, kdy jádro přestane držet procesor a začne běžet uživatelský proces (že bych si to zkusil hacknout a třeba zavolat setend nebo nahodit ten bit v PSR). A neumím programovat v assembleru, že bych si splácal jednoduchou binárku, která by si jako první zavolala setend be, a teprve pak začala něco dělat (ale stačilo by i skončit s nějakým identifikovatelným návratovým kódem). :c) (Což by bylo užitečné jako proof-of-concept, ne jako řešení.)

[init]

Over, ci vobez dochadza k spustaniu initu. Hlasky v kernely vypisujes cez printk(). Spustanie initu sa deje v nasledujucom subore: https://github.com/torvalds/linux/blob/master/init/main.c

[xHire]

Nicméně to není ten problém

Tak aspoň se odstraní chybové hlášení. Já se teda setkal i s tím, že embedded jádra nevytvořily device nod v /dev a pak odmítly bootovat (a ty vyžaduješ pár nodů v kernel parametrech: "console=tty0 console=ttyS0").

Jinými slovy mám za to, že ty binárky mám zkompilované dobře (resp. jsem nezaznamenal nic, co by napovídalo opaku, ani známky, že by se to mohlo dát dělat nějak jinak) a že problém mám na straně jádra, které ten E bit nenastaví.

Podle mě kernel v LE módu ten userspace nepouští, to by snad byl schopnej spustit i LE nakompilovanej init bez format erroru. Nejspíš by šlo udělat nějakej krátkej assert do kernelu, kterej by obsah toho flagu občas vypsal do konzole. Stejně tak pokud byl byl schopnej debugovat třeba přes JTAG, tak se můžeš rovnou kouknout přes GDB na obsah toho flagu. To by šlo udělat i v emulátoru, třeba v qemu.

Přepnutí mezi userspace a kernelspace bývá v assemblerovejch souborech typu entry.S, ale těch zdrojů přechodu je mnoho (syscally, různá přerušení, MMU exception, opcode exception, FPU exception). Kdyžtak můžeš zkusit hledat makro ARM_BE8 (protože pokud existuje něco jako mixed mode, tak by se muselo přepínat).

A neumím programovat v assembleru, že bych si splácal jednoduchou binárku

V assembleru to je triviální, potřebuješ jen zavolat asm z céčkovýho kódu. Pro naučení syntaxe můžeš klidně vykrást kernel (myslím že se tomu říká asm inlining).

Ale jestli to nespustí (klidně jednou s a jednou bez toho setend, abys věděl zda se něco změní) ani něco takovýho jako (init=/helloworld.bin):

asm volatile ("setend be" :::);
while(1) {
  printf("hello world\n");
}

Tak bude problem někde jinde. Jinak já bych tu binárku neukončoval, protože to pak bude znamenat že jí má kernel killnout ... A init nemůže být killnutej .

Nicméně napadájí mě ještě dvě varianty. Tohle může být problém i toho, že je ta binárka zkompilovaná se špatnejma parametrama (jiná verze ARMu = jiný instrukce, chybějící podpora VFP/neonu/emulace v libc a/nebo kernelu = to jsou vlatsně taky jiný instrukce). A protože se při kompilaci toolchainu kompiluje i libc, tak může být problém i tam.

Druhá možnost je problém s kompilátorem. Někde na začátku léta vydali novou major řadu GCC, kde nějak optimalizujou tvorbu kódu a GCC teďka kompiluje občas nevalidní binárky pro staré architektury (ARMv5 - xscale). Projevuje se to podobně, že kernel zpanikaří. Neměl jsem absulutně čas se na to kouknout, ale bude to nejspíš dost komplikovanej bug (protože mě nenapadá ani kde začít, kromě ručního porovnávání instrukce po instrukci). Kdyžtak zkus použít starší kompilátor (6.x) a zkontrolovat zda věci jako VFP/emulace a verze ARMu opravdu sedí s fyzickým hw.

P.S. Ještě můžeš vypsat dump_stack().

[xHire]

GCC mám 5.4.0 (hraju si s tím nepřetržitě už někdy od ledna :c)), takže to je OK.

Nicméně nedalo mi nezkusit zavolat tu setend instrukci. Kompilátor začal prskat

/tmp/cc8hEYFq.s: Assembler messages:
/tmp/cc8hEYFq.s:37: Error: selected processor does not support ARM mode `setend be'

takže jsem trošku pohledal a poexperimentoval. Nakonec mám init jen o nekonečné smyčce (int main(void) { for (;;); return 0; }), který mi běží. :c)

Nicméně důvod, proč jsem nevyzkoušel ten ASM kód dřív, je, že jsem chtěl, aby se tahle instrukce provedla pokud možno jako první/jedna z prvních. To běžný program nesplňuje – než se procesor dostane k první instrukci fce main, tak udělá spoustu věcí. Nicméně v průběhu řešení zmíněné chyby jsem si vzpomněl, že v Makefilu apexu (což je starší zavaděč) jsem viděl kompilaci bez stdlib, takže jsem zkonstruoval následující volání:

armeb-linux-gnueabihf-gcc -march=armv7-a -static -nostdlib cycle.c -o cycle

Přičemž potřeba jsou obě dodatečné volby. Bez -march končím na Interrupted system call. Ale odtud už to půjde snadno – akorát nechám všechno překompilovat, počínaje glibc.

Děkuji ti moc za pomoc, udělal jsi velkou radost. :c)

[pc2005]

Nicméně důvod, proč jsem nevyzkoušel ten ASM kód dřív, je, že jsem chtěl, aby se tahle instrukce provedla pokud možno jako první/jedna z prvních.

Jo to je fakt, ony tam jsou konstruktory a inicializace. I když nejspíš by šlo tu binárku modifikovat a přidat vlastní entry point.

Ale odtud už to půjde snadno – akorát nechám všechno překompilovat, počínaje glibc.

Ony se dají optimalizace na procesor nastavit i v crosstoolu.

Děkuji ti moc za pomoc, udělal jsi velkou radost.

Jo není zač, dej vědět zda to pomohlo.

[Vantomas]

Trochu offtopic a moc tomu nerozumím, ale z gcc jde dostat kód v assembleru, než se z toho udělá binárka. Nedá se takhle ten vlastní init převést do assembleru, tam na začátek přidat setend a pak to zkompilovat do binárky? Případně se takhle alespoň podívat na to, zda je setend hned na začátku nebo je něco předním.

https://stackoverflow.com/questions/137038/how-do-you-get-assembler-output-from-c-c-source-in-gcc

[endian]

Je jedno v com napises, procesor rozumie len binarnemu formatu specialnemu pre kazdy procesor - tj. instruktna sada procesora. (napr. pre x86).

Su dve typy prekladacov.
Priamy a nepriamy.
priamy: Source -> asambler -> BINARY
nepriamy: Source -> BINARY

Mozes i v ASM napisat init. Napriklad NASM (Hello world).

GCC asambler ma ATX syntax. Tj. zamene operandy ako zvyknu standardne asamblery. Lepsie sa ten asambler strojovo spracuva.

no ATX syntax: MOVE KAM, Z_KADIAL
   ATX SYNTAX: MOVE Z_KADIAL, KAM

[endian]

Oprava
nepriamy: Source -> asambler -> BINARY
priamy: Source -> BINARY

[pc2005]

gcc -S file.c

ti sice vygeneruje assembler z toho file.c, ale obsahuje jen main(). V linkeru se k tomu přidávají libc volání a věci jako inicializace polí a tak. Tazatel by musel opravit soubory typu crtbegin.o, crtend.o atd. Ty dodává gcc.

[endian]

Program init prekladas pre little endian. Pre big musi byt prepinac -mbig-endian.

Zrejme aj tak Ti to nepojde, lebo nasledne pri linkovani musia aj byt kniznice big endianove prelozene. Takze tie si prelozit budes musiet. Vid. www.lara.prd.fr/.../mipsellinuxtoolchain, tak tam prekladal pre MIPS z Intel. Uprav si to pre ARM.

[xHire]

$ armeb-linux-gnueabihf-gcc -static trivial.c -o trivial
$ armeb-linux-gnueabihf-gcc -static -mbig-endian trivial.c -o trivial2
$ file trivial{,2}
trivial:  ELF 32-bit MSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped
trivial2: ELF 32-bit MSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped
$ sha256sum trivial{,2}
18952e56d59dc00c0c15a9a384b2cf4febb07432a8e128c1d0ba0cd83867d85e  trivial
18952e56d59dc00c0c15a9a384b2cf4febb07432a8e128c1d0ba0cd83867d85e  trivial2

Bez komentáře. :-P (Prosím už nepiš žádné další rady podobného ražení. Děkuji za snahu, ale zjevně mě nikam nedovedeš…)