Vlákno názorů k článku Instrukční sada AArch64 (2.část) od NIP - Si hovorim, ze by som ARM asm vyskusal...

Dobrý den. Je víc možností, například nástroje od Keilu http://www2.keil.com/mdk5 (tj. překladač+IDE+de­bugger), ale přiznám se, že si vystačím s GNU Assemblerem, GDB s nadstavbou cgbd (https://mojefedora.cz/debuggery-a-jejich-nadstavby-v-linuxu/#k07), editorem a make (i když ten vlastně není nutný díky rychlosti překladu). On má sice GNU Assebmler poměrně špatnou pověs, že je to write-only nástroj vhodný jen jako backend pro GCC, ale minimálně pro AArch64 to není pravda a dá se v něm psát dost čitelný kód a chybová hlášení jsou taky relativně rozumná (to je asi důvod, proč se nikomu nechce předělávat NASM pro ARMy - jen IMHO)

No GDB+cgdb se da nastavit i do tohoto rezimu. Abych byl zcela uprimny - kvalit stareho dobreho Turbo Debuggeru to nedosahuje, ale asi je jina doba :/

Na větších procesorech je vlastní start po resetu celkem náročný a tím i psaní kódu, který má běžet na holém "železe". Ve většině případů po zapnutí napájení není možné použít žádnou externí RAM paměť a integrovaná RAM na čipu sice většinou nějaká je, ale slouží buď pouze jako cache nebo je určená především pro periferie. Někdy je k dispozici scratchpad/TCM a pak je psaní malých prográmků trošku jednodušší. Zavedení kódu, který běží úplně od začátku také může vyžadovat buď JTAG nebo dnes spíš specializovaný protokol přes USB i.MX5x, i.MX6. Výhoda je, že novější generace SoC obsahují v ROM zvaděči již vetšinou podporu pro přímé zavedení z SDkarty, většinou z FAT oddílu. Ale i to někdy může být docela divočina. Přitom kód nebo nějaká ROM přehrávaná konfigurační sekvence musí nejdříve nakonfigurovat rozhraní SoC tak, aby vedly cesty k externí SDRAM a pak naposílat konfiguraci do vlastních DDR čipů. Teprve potom je možné paměť využívat.

V případě BCM270x (Raspberry Pi) startuje nejdříve z ROM VideoCore s vlastní specifickou instrukční sadou. ROM firmware podporuje načtení a spuštění kódu z SDkarty. Ovšem stále na VideoCore a teprve tento kód musí načíst kód pro ARM z SDkary a povolit star ARMu. Přitom naráz odstartují všechna jádra (v případě RPi 2/3), ta se musí separovat a jedno pustit do kódu nataženého přes VC4. Podpora, kterou dodává RPi organizace a Broadcom je v této části zcela uzavřená, ale vyvíjejí se i otevřené alternativy.

Jako první projekt v assembleru pro osahání jak CPU (např ARM) na nejnižší úrovni pracuje to opravdu není vhodná volba a veškeré LPC, STM atd jsou mnohem jednodušší.

Na druhou stranu není problém nechat konfiguraci DDR SDRAM a základních pinů na U-Bootu. U-boot umí (pokud je správně nakonfigurovaný) natáhnou libovolný ELF spustitelný kód nebo i jen čistě binární blok paměti (lépe zabalený do uimage) a pak do něj skočit. Přitom v tomto případě již CPU a alespoň jeden sériový port normálně pracuje a kód je celkem standardní. U-boot dokonce nabízí i možnost nahrávat rozšíření, která mohou zpětně využívat/volat funkce z U-bootu pro tisk na konzoli a další. Přitom U-boot neaktivuje žádné iterrupty, vlákna, MMU atd, takže kód stále běží na holém železe. V okamžiku, kdy chcete ale přerušení, tak i v tomto případě může být konfigurace většího CPU (Cortex-A na rozdíl od Cortex-M) celkem zajímavé. V dnešní době například BCM firmware i U-boot alternativa ARM startuje v HYP režimu. Takže obecný kód pro start 32-bit ARM pro ARM920, Cortex-A a Cortex-M vypadá například v systému RTEMS takto

Zbavení se hypervizor režimu pro přechod do normálního, s běžným využitím interruptů pak takto

Ale i tak je start z U-bootu opravdu proti startu z nuly jednoduchý a AArch64 by si takto mělo jít vyzkoušet i na RPi3 a ostatních platformách, kde je U-boot k dispozici.

Další možnost je zkusit třeba ten RTEMS, protože je to RTOS a i z důvodu minimalizace latencí nepodporuje adresní prostory, ale jen vlákna v rámci jedné aplikace a i z "uživatelského" kódu/běžné aplikace je možné přistupovat přímo na HW.

Jinak čistě funkci procesoru/jeho registrů bez přístupu na HW si lze vyzkoušet přímo v programech z GNU/Linuxu a na ladění je to mnohem jednodušší. Ale v té chvíli nemáte kontrolu nad celým HW, běží paralelně mnoho přerušení, vláken, dalších CPU, GPU koprocesorů atd. Takže na pochopení vlastního CPU je to v pořádku, ale na pochopení SoC a testování jeho registrů je to již problematičtější. Ale i do registrů přímo na fyzických adresách si lze "zarýpat" (rdwrmem), s tím, že pokud danou periferii obsluhuje již nějaký ovladač tak třeba OS spadne. Případně jak to předvádíme studentům sice v C-čku ale s rozborem kódu v assembleru na prvním motivačním cvičení v rámci našeho kurzu: