Hlavní navigace

Názory k článku Instrukční sada AArch64 (2.část)

Článek je starý, nové názory již nelze přidávat.

  • 20. 6. 2017 21:37

    NIP (neregistrovaný) 193.165.117.---

    Si hovorim, ze by som ARM asm vyskusal ale ako zacat? Aky prekladac? Ake prostredie? Volakedy som assembler robil na Z80 dost intenzivne, prostredie sa volalo MRS (asi...) a bol to integrovany editor a debugger. Dnes asi nejake IDE-cko? Doma sa mi par dosiek s ARM-mom povaluje. Poradi p. Tisnovsky?

  • 21. 6. 2017 9:17

    Pavel Tišnovský

    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)

  • 21. 6. 2017 10:26

    NIP (neregistrovaný) 193.165.117.---

    Ano, pozeral som na konci clanku mate pekny priklad ktory mi funguje. Skusal som sa trosku rozhliadat po webe a kedze mam zopar NXP dosiek (prehrabol som policky a nasiel som dve LPC1768) tak sa mi ako vhodne javi LPCXpresso ktore obsahuje asi vsetko co chcem. AArch64 asi nepodporuje ale do zaciatku bude stacit? Ide mi skor o komfort ladenia, moct vidiet pocas ladenia zmeny v registroch, vypisy pamati a pod. je pre mna osobne velke plus. Holt sila zvyku z toho Z80 assembleru :) Free verzia ktora ma obmedzenie na 256kB kod mi asi nevadi.

  • 21. 6. 2017 13:05

    Pavel Tišnovský

    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 :/

  • 22. 6. 2017 9:13

    Pavel Píša

    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.

    https://github.com/christinaa/rpi-open-firmware

    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

    https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/start/start.S

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

    https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/shared/startup/bsp-start-in-hyp-support.S

    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:

    https://cw.fel.cvut.cz/wiki/courses/b35apo/tutorials/01/start